Hacking Asus RT AC66U and Preparing for SOHOpelesslyBroken CTF

Hacking Asus RT AC66U and Preparing for SOHOpelesslyBroken CTF

So its finally July, time to pack for DEFCON, follow @defconparties on Twitter and decide whichvillages to visit and which talks to attend.

Theres a new hacking competition this year called SOHOpelesslyBroken, presented by ISE and EFF. The objective on Track 0 is to demonstrate previously unidentified vulnerabilities in off-the-shelf consumer wireless routers. Track 1 will hold a live CTF for the duration of DEFCON. CTFs are always fun and this contest involves hacking real embedded devices, what makes it even more fun.

Yes, thats my workstation =P

Im particularly interested on the EFF Open Wireless Router, but they didnt disclose details about the device yet. According to the event rules, the ASUS RT-AC66U (HW Ver. A2) [Version 3.0.0.4.266] is one of the possible targets. As I had a spare RT-AC66U at home, I decided to write a quick guide for everyone interested in participating in this competition CTF.

recon

The first thing to do is to find the firmware and its source code. Hopefully, Asus RT-AC66U is GPLed and we can easily find its source online. The version used for the contest is an old one, from 2012. In order to perform a better analysis, we are going to grab the sources and the firmware from v3.0.0.4.266 and v3.0.0.4.376.1123 (the most recent one as of this writing).

• Asus RT-AC66u v3.0.0.4.266 - Firmware
• Asus RT-AC66u v3.0.0.4.266 - Source Code
• Asus RT-AC66u v3.0.0.4.376.1123 - Firmware
• Asus RT-AC66u v3.0.0.4.376.1123 - Source Code

Many firmware versions were published between these two releases, we can review the changelogs to find security issues:

• http://www.asus.com/Networking/RTAC66U/HelpDesk_Download

According to the rules, we have to identify and exploit a 0-day vulnerability. We can combine different flaws with known issues in order to score points. If the vendor had silently patched an issue and you create an exploit for it, that should be scored as a valid 0-day (Im not going to start discussing terminologies here).

Now that we have the source code, its time to extract and audit it: The CTF Field Guide from Trail of Bits has some good resources on Auditing Source Code. You can use tools like Beyond Compare,Araxis Merge and WinMerge on Windows platforms or Meld if youre more of a Linux user.

Lets focus on the "/asuswrt/release/src/router/" directory, comparing these two folders using Meld:

There are many security advisories for this router: if you want to find 0-days you should look for disclosed vulnerabilities and exploits to avoid duplicates (believe me, this is the hardest part). Some references:

• ASUS RT-AC66U Remote Root (Broadcom ACSD)
• ASUS RT-N66U Router - HTTPS Directory traversal and full file access and credential disclosure vuln
• Asus RT56U Remote Command Injection
• Taking over the ASUS RT-N56U and RT-AC66U
• Dear Asus router user: You’ve been pwned, thanks to easily exploited flaw (Asusgate)
• OSVDB

Points are deducted from your score if your exploits requires special system configurations and specific information. If you want to score lots of points, you should be targeting default services and processes.

The USB application tab on the RT-AC66U allows the user to set up a series of services like FTP, DLNA, NFS and Samba:

MiniDLNA is also a nice a target. It should be pretty easy to find vulns for the service using Zachary Cutlips research, as he broke it multiple times.



Another potentially vulnerable service is AiCloud: it links your home network to an online Web storage service and lets you access it through a mobile application:

forensic

While part of the team audits the source code, the forensics guys should be unpacking the firmware using binwalk + fmk:

You may remember binwally, the tool I developed to perform binary tree diff using fuzzy hashing. Binwalk has its own option to perform fuzzy hashing against files and directories:

Most vendors (like Asus) wont open source their entire code base. You may need to reverse proprietary drivers and binary blobs in order to find some good vulns. ACSD is a particularly interesting binary because it was removed from newer firmwares (v3.0.0.4.374.130+) due to a vuln disclosed byJacob Holcomb:

The binaries are MIPS and Little Edian:

Its also important to learn more about the filesystem. The OpenWRT Wiki has a nice article on Flash Layouts. The MTD subsystem for Linux provides access to flash devices, creating fully functional filesystems. SSH to the device and map the mount points and partitions:

The NVRAM partition is very valuable for us because it stores all the configuration parameters. We can view its content by dumping the corresponding partition (mtd1) or by issuing the "nvram show" command:

Another interesting partition is the bootloader (pmon). It has some LZMA compressed data and the boot process provides a failsafe mechanism to recover from a bad flash.

reverse

Time to start the reversing tasks. We need some basic tools like gdb, gdbserver and strace to start debugging the binaries: we could either cross compile them or set up Optware/Entware to install prebuilt packages.

Wanduck (GPL_RT_AC66U_VER3004266/asuswrt/release/src/router/rc/wanduck.c) is an interesting process to analyze. It starts by default and binds a pseudo HTTP server on port 18017. The HTTP server redirects every request to the main administrative interface and, for some reason, it drops requests to URLs ending with ".ico".

Lets find out why: start gdbserver on the remote target (gdbserver --multi localhost:12345 &) and connect to your debugger of choice. If youre using Ida Pro, open the binary "/sbin/wanduck" and set the processor type to "mipsrl".

Navigate to the handle_http_req function and set a breakpoint on the dst_url comparison:

Enter the gdbservers host and port under "Debugger / Process Options" and attach to the corresponding PID.

Resume the process (F9) and make an HTTP request to http://192.168.1.1/x.ico. The debugger will stop at the defined breakpoint and you can now inspect the registers and the memory.

If you want to find reverse engineering targets, search for folders named "prebuilt" under "GPL_RT_AC66U_VER3004266/asuswrt/release/src/router/". Some interesting binaries:

- /acsd/prebuilt/acsd
- /webdav_client/prebuilt/webdav_client
- /asuswebstorage/prebuilt/asuswebstorage
- /eapd/linux/prebuilt/eapd
- /nas/nas/prebuilt/nas
- /flash/prebuilt/flash
- /et/prebuilt/et
- /wps/prebuilt/wps_monitor
- /ated/prebuilt/ated
- /wlconf/prebuilt/wlconf

The mobile AiCloud app might reveal some interesting information about how the device works. If you reverse the APK or use an intercepting proxy you can identify the apps initial HTTP request:

 

You see that strange ddns_hostname? Thats a crypto task =)

crypto

The POST request tries to register a new Dynamic DNS using the asuscomm.com service.  If we search for the term asuscomm.com on the RT-AC66U source code, we can easily find the function that generates this DDNS:

1234	var isMD5DDNSName = function(){ var macAddr = <% nvram_get("lan_hwaddr"); %>.toUpperCase().replace(/:/g, ""); return "A"+hexMD5(macAddr).toUpperCase()+".asuscomm.com"; }

view rawindex.asp hosted with ? by GitHub

According to WikiDevi, the following OUIs are currently being used by the RT-AC66U:

- 08:60:6E (1 E, 1 W, 2011)
- 10:BF:48 (1 E, 2 W, 2011)
- 30:85:A9 (3 E, 3 W, 2011)
- 50:46:5D (1 E, 2 W, 2012)

Using this information we can map the IP address for every single router using AiCloud. Lets generate a list of all the possible MAC addresses and brute force the hostnames using this cool trick from mubix.

If youre too lazy to run these commands, you can simply search for asuscomm.com on Shodan:

AiCloud runs on ports 8082 and 443 by default. The fact that anyone can easily map the routers running this service could be very worrisome, right?

Another interesting crypto exercise is to reverse the algorithm used to generate the WPS device PIN. You can view the currently PIN and secret_code by issuing the following command: nvram show | grep -E "secret_code|wps_device_pin". Search for these variables in the source code and use this information to create you own WPS Keygen (dont forget to include a chiptune from pouet.net).

You can also test the entropy from the crypto keys generated by the device. Check the slides from the "Fast Internet-wide Scanning and its Security Applications" to gather some ideas:

Slides from Fast Internet-wide Scanning and its Security Applications [30c3]

web

There are so many things to test on the Web application that Ill focus on a few different approaches. The routers administrative interface has no CSRF protection. It has the traditional ping command injection and lots of XSS vectors.

The HTTP daemon is based on microhttpd. It has some basic Directory Traversal Protection on httpd.c:

We can shamelessly steal hackerfantastics idea and test for potential bypasses (theres an extensive list of LFI tests at Seclists):

123456789101112131415161718

#include <stdio.h> #include <string.h>   int main(int argc, char *argv[]){ char *file; int len; file = argv[1]; len = strlen(file); if ( file[0] == / || strcmp( file, ".." ) == 0 || strncmp( file, "../", 3 ) == 0 || strstr( file, "/../" ) != (char*) 0 || strcmp( &(file[len-3]), "/.." ) == 0 ) { printf ("Illegal filename: %s ", file); } else { printf ("Accepted filename: %s ", file); } return 0; }

view rawtest_traversal.c hosted with ? by GitHub

The web server has some mime handler exceptions that were "supposed to be removed":

download now

download