Date: Tue, 27 Nov 2012 10:39:22 -0800
From: Gary <gdriggs@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Remote Command Execution on Cisco WAG120N

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.


 On Tue, Nov 27, 2012 at 9:33 AM, andfarm wrote:
> Through cross-site request forgery. ... (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 so, where's the HTML and CGI source from a WAG120N admin UI that
supports this theory? Here's the original post with new comments.

> 1º Authenticate and browse to /setup.cgi?next_file=Setup_DDNS.htm

Yes, by its name it looks like it could be a dynamic DNS setup page.
The author has access to this device to confirm or deny that along
with my other statements below. But it doesn't seem to matter what
this page's intended functionality is per the "exploit" outlined below
since it's just one of possibly many unvalidated submission forms.

> 2º All the fields you see are vulnerables to command execution as root, so inject
> "qwe.com;cat /etc/passwd> /www/Routercfg.cfg;" into the Hostname field

So we've abused a submission form that doesn't practice proper form
validation. "The goal of web form validation is to ensure that the
user provided necessary and properly formatted information needed to
successfully complete an operation."[1] Apparently, the form is also
not checking the hostname field for anything that complies with ASCII
standard or Unicode internationalized domain names. In addition, the
web server process apparently has privileges enough to write to the
OS. So it is probably running as root or the file perms are borked in
relation to what privileges the service's user /ought/ to have.

> 3º Everything is done, just download the file /Routercfg.cfg (Authenticated is requiered)
> root::0:0:root:/:/bin/sh
> nobody::99:99:Nobody:/:/sbin/sh

In order to download the file that's been modified, we still have to
authenticate to the device. And then what do we get in return? An
empty password file that I can't really do anything with. For one, we
presumably already know the root or otherwise privileged user's
password that's not even exposed in this file. Also, passwords have
been stored in shadow files since about System V Release 3.2 in 1998
and BSD 4.3 in 1990 so we might want to look for something more
lucrative. Can we use the same commands to copy a shadow file in to
Routercfg.cfg? If so, what do we gain? A password that we already
know? How is that a danger to the end user? They might be able to
issue a "reboot" command. Again, where's the danger of exploit by
remote unauthenticated users or scripts in the wild? Yes, it's stupid.
Yes, it's not best practice.

We still have an authentication wall and no HTML or CGI source code
supporting the veracity of the author's claims. We don't really need
those things, however, because even then we're still looking at an
"exploit" that requires the end user knowing the the admin's user name
and password. So it may be worth reporting to the vendor as bad
engineering for not using best OS and application security practices.
But we don't see bypass or escalation of privileges and the author
didn't list what user names were used to authenticate. Again, where's
the security risk?

Throughout my day I authenticate to at least a dozen or more devices
that I have read/write access to. Should I report those
vulnerabilities to Cisco, Oracle, Canonical, Apple, Microsoft, et al?
Or should I just post them to a security discussion list as some great
revelation? There are probably several dozen of these SOHO grade
devices with similarly poor architecture  -- hence the intention of my
original reply. Report it to the vendor? Yes. Post it on a public list
or open a CVE? Probably not. At the very least it's sloppy science and
too sparse on relevant details. Alternately, report it to the list for
what it is -- improper form validation instead of "remote command
execution" which suggests that anyone scanning for public IPs can find
one of these devices and issue commands to it without authenticating
whether it's by web form, SSH, etc.

-Gary

1. http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-and-tutorials
q.v. http://en.wikipedia.org/wiki/Arbitrary_code_execution

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

Powered by blists - more mailing lists