full-disclosure - Re: Remote Command Execution on Cisco WAG120N

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 27 Nov 2012 09:33:31 -0800
From: andfarm <andfarm@...il.com>
To: Gary Driggs <gdriggs@....edu>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Remote Command Execution on Cisco WAG120N

On 2012-11-22, at 07:08, Gary Driggs <gdriggs@....edu> wrote:
> How is this a vulnerability if it's behind an authentication wall?
> I've seen several SOHO routers and APs that include some kind of
> "hidden" web page that allows one to tweak settings. How does this
> differ & how is it remotely exploitable without authentication?

Through cross-site request forgery. Consider the following on a publicly accessible web site:

<form action="http://192.168.0.1/admin.cgi" method="post">
...
</form>
<script>document.forms[0].submit();</script>

(If the form is accessible via GET, the attack becomes even easier, as an attacker can cause the form to be "submitted" without the involvement of a script -- by using an <img> tag, for example.)

If the user already has a valid session on the router, the request will typically go through, unless the router firmware supports some form of XSRF protection. (Most do not.)

If no session is active, but the router uses HTTP authentication, the browser will simply pop up an HTTP authentication dialog, and many users will simply submit the authentication form without realizing what it is that they're authorizing. (It doesn't help that some browsers may even autofill the username and/or password on this dialog!)

For routers that make use of non-HTTP login sessions, but which do not use XSRF protection, and which have default passwords, it may additionally be possible to "prime" the main attack with an XSRF submission to the login form. There are ways to ensure that you get the timing of the two submissions right, but I'll leave them to the reader's imagination. :)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/