[prev in list] [next in list] [prev in thread] [next in thread]
List: full-disclosure
Subject: Re: [Full-disclosure] Remote Command Execution on Cisco WAG120N
From: Ulisses Montenegro <ulisses.montenegro () gmail ! com>
Date: 2012-11-28 13:17:27
Message-ID: CAA24+d7-NAmipnUZupg2dQybF69Pvj_u4f9-tk3pNcy+4OXcNQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Nov 27, 2012 at 4:39 PM, Gary <gdriggs@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 6:11 AM, Benji wrote:
> > Command execution through Dynamic DNS setup is quite clearly not
> expected functionality.
>
> Agreed but that's still not "remote command execution" per my explanation
> below.
Assuming it works as the original poster described (I don't have the
hardware to check, but similar issues have been found on the firmware of
various other home routers), then why not? Yes, it does require
authentication, so you might want to call it "authenticated remote command
execution", but you still get arbitrary commands executed through CSRF.
There are some rather aggravating details about this happening on a device
such as this:
1. Most home routers (again, I don't have the hardware so I must assume
here) use HTTP basic authentication, which can be embedded in request URLs
using the 'http://user:password@host/path?param' syntax, so forging an
authenticated request does not require a login -> obtain a valid session ->
submit with session, it can be done single-shot if the user and password
are known, which brings us to...
2. Most home routers use default, known username/password combos which are
available in public documentation. Since a large percentage of home users
do not change these, and also use the default IP ranges, the chances of
hitting a vulnerable router by using the '
http://user:password@192.168.0.1/action?params' URL (replacing relevant
elements as required, of course) is rather good.
3. Finally, on many of those devices the HTTPd process is running as root.
So, you can do pretty much anything you could do with a root shell.
Yes, there are restrictions, and yes, I am assuming things work as
described by the original poster, but I don't see the need to be
authenticated as being the major issue here, but rather the possibility of
arbitrary command execution through CSRF.
Ulisses
--
"If debugging is the process of removing software bugs, then programming
must be the process of putting them in." - Edsger Dijkstra
[Attachment #5 (text/html)]
<div class="gmail_extra">On Tue, Nov 27, 2012 at 4:39 PM, Gary <span dir="ltr"><<a \
href="mailto:gdriggs@gmail.com" target="_blank">gdriggs@gmail.com</a>></span> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <div class="im">On Mon, Nov 26, 2012 at 6:11 AM, Benji wrote:<br>
> Command execution through Dynamic DNS setup is quite clearly not expected \
functionality.<br> <br>
</div>Agreed but that's still not "remote command execution" per my explanation \
below.</blockquote><div><br></div><div>Assuming it works as the original poster described (I \
don't have the hardware to check, but similar issues have been found on the firmware of \
various other home routers), then why not? Yes, it does require authentication, so you might \
want to call it "authenticated remote command execution", but you still get arbitrary \
commands executed through CSRF. There are some rather aggravating details about this happening \
on a device such as this:</div> <div><br></div><div>1. Most home routers (again, I don't \
have the hardware so I must assume here) use HTTP basic authentication, which can be embedded \
in request URLs using the 'http://user:password@host/path?param' syntax, so forging an \
authenticated request does not require a login -> obtain a valid session -> submit with \
session, it can be done single-shot if the user and password are known, which brings us \
to...</div> <div><br></div><div>2. Most home routers use default, known username/password \
combos which are available in public documentation. Since a large percentage of home users do \
not change these, and also use the default IP ranges, the chances of hitting a vulnerable \
router by using the '<a \
href="http://user:password@192.168.0.1/action?params">http://user:password@192.168.0.1/action?params</a>' \
URL (replacing relevant elements as required, of course) is rather good.</div> \
<div><br></div><div>3. Finally, on many of those devices the HTTPd process is running as root. \
So, you can do pretty much anything you could do with a root \
shell.</div><div><br></div><div>Yes, there are restrictions, and yes, I am assuming things work \
as described by the original poster, but I don't see the need to be authenticated as being \
the major issue here, but rather the possibility of arbitrary command execution through \
CSRF.</div> <div><br></div><div>Ulisses</div></div><div><br></div>-- <br>"If debugging is the \
process of removing software bugs, then programming must be the process of putting them in." - \
Edsger Dijkstra<br> </div>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic