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/