Sunday, November 30, 2014

9447 2014 CTF Write Up: coor coor

The Australian 9447 Security Society CTF took place on November 29-30 and it was yet another fun and really professionally organized CTF. I played with my friends from TheGoonies once again (The Goonies 'R' Good Enough, right?).

I found the task "coor coor" particularly interesting: it was a good way to practice some concepts from the new book I recently bought: The Art of Memory Forensics (authored by @attrc and @gleeda).

Task: coor coor (misc - 400)

A 9447 CTF organizer is giving away flags to friends that he trusts. This memory dump was taken off a competitor's computer after a raid by the pwnpolice.

Download provided:

Let's start by identifying the Operating System profile:
python -f challenge.vmem imageinfo

Let's take screenshot to see what the user was doing:
python -f challenge.vmem screenshot -D screenshot/

The user was running something inside VirtualBox, let's keep digging:
python -f challenge.vmem psxview

python -f challenge.vmem filescan | grep -e "\.tc\|TrueCrypt"

The user was basically running a VirtualBox machine (business2.vdi) from an Encrypted TrueCrypt container ( That's why we used psxview to list the system processes before. Note that the lower offsets are used by the Host and the higher ones (after 0x7b760da0) are used by the guest OS. So what was he doing?

python -f challenge.vmem connscan

The host ( happened to be an IRC server with only one active channel: #9447ctf. We can carve some pidgin logs using foremost:

python -f challenge.vmem mftparser | grep 9447ctf

foremost challenge.vmem

Private conversations are not logged by default on Pidgin with the OTR extension. We can see a couple of OTR encrypted  messages on the memory dump:

Because of Perfect Forward Secrecy, if you lose control of your private keys, no previous conversation is compromised. I just had the long term signature keys (otr.private_key) and these aren't actually used to encrypt conversations, just to sign the session encryption key. I still needed to retrieve the short term encryption keys from the memory. I got stuck on this phase and spent the whole night trying to figure how to do that.

After some time I decided to get some sleep and keep trying it on the following day. The first thing I did the next day was to re-read the challenge description and I quickly figured it out:
"A 9447 CTF organizer is giving away flags to friends that he trusts."
Because of the way IRC works, I could easily impersonate testicool69 (the trusted frind), connect to the IRC server ( and message acidburn88 (the CTF Admin) asking for the key. So how do I do that?

Pidgin-OTR creates three files during an encrypted communication: otr.private_key, otr.instance_tags and otr.fingerprints. I searched for the term "prpl-irc" on the memory dump, extracted and replaced those files on my own Pidgin installation (%APPDATA%\.purple). There's a Metasploit post-module to retrieve these keys from a live (hacked) system, by the way...

I managed to forge his fingerprint using the stolen private key and got the secret Flag:


Friday, October 24, 2014 2014 CTF Write Up: At Gunpoint's 2014 CTF took place on October 21-23. The event was organized by fluxfingers, and this year's challenges were really enjoyable, huge props to them. I played with my friends from TheGoonies - after winning the Brazilian CTF Pwn2Win we are now getting better organized to become more competitive. There are quite a few write ups around and I decided to post about a few tasks which we had a different solution from other teams.

Task: At Gunpoint (Reversing - 200)

You're the sheriff of a small town, investigating news about a gangster squad passing by. Rumor has it they're easy to outsmart, so you have just followed one to their encampment by the river. You know you can easily take them out one by one, if you would just know their secret handshake.

Download provided: gunpoint_2daf5fe3fb236b398ff9e5705a058a7f.dat

File utility showed us that it was a GameBoy ROM. Having former Console Hackers on the team came handy during this challenge as we already knew in advance which tools to use and what to look for.

We used TLayer TileMolester from the legendary SnowBro to gather information about the graphics and the font data. Firstly, we switched the Codec to 1bpp and found the font used by the game.

We were about to create a character table when, after switching the Codec to 2bpp planar (GameBoy's native Codec), we found something interesting:

After some offset adjustment (using +, -, Shift + left and Shift + right) we got this image:

We submitted the key "tkCXDtheQDNRN", but it wasn't accepted. I wanted to confirm that those tiles were disposed in a linear way, so I kept analyzing the ROM.

The GameBoy's screen has a resolution of 20x18 tiles. In order to check if the order of the tiles (and the flag) was correct, I performed a relative search using Darkl0rd's Monkey-Moore:

Let's imagine a grid containing the tiles for the key "tkCXDtheQDNRN" sequentially. Considering the first tile as an A, the second one would be B, the third one C and so on. After 20 bytes (the screen width) there should be something like a line break: that's why I performed a relative search for ABCDEFGHIJKLMNOPQRST*UVWXYZ.

If we go to the ROM's offset 0x0965 using an Hex Editor, we find out that this is indeed the section responsible for displaying the tiles:

Let's compare it with the emulator's BGMAP when displaying the key:

I'm not sure if this was intentional, but there's something strange on this key display screen. The first tile for the char "t" (0x15) is followed by the first tile from "k" (0x16), which is followed by the first tile from "C" (0x17) until we reach the "N" (0x28). There's a break at offset 0x0979 (0x00) and the second half for these tiles (0x29 0x30 0x31 ... 0x3C) ends with a 0x3D instead of the usual 0x00. We can see this clearly on the screenshot above, as the tile highlighted by the mouse pointer (0x3D) is off the limits.

Anyway, we apparently had the correct flag but we took some time to figure out that the 6th letter was a "J" and not a "t". One member from our team figured that out and submitted the correct key "tkCXDJheQDNRN".

There are other solutions to this challenge, like this one from Tastless. I'm still waiting for a write up from someone who actually reversed and inputted the secret combination. Anyway, none of them are going to be as elegant as the one from @angealbertini:

Sunday, August 17, 2014

Scan the Internet & Screenshot All the Things

During Defcon 22, @ErrataRob, @paulm and @Viss (mass)scanned the Internet and presented some Tips, Tricks and Results. Lots of people confronted @Viss after he posted some VNC screenshots on his Twitter timeline. He posted a follow-up article on his blog and Kashmir Hill, from Forbes, wrote an article about the exposed VNC services.

Internet scanning isn't new anymore and people are still surprised with these results. For this post, I'll share some techniques I commonly use to map and screenshot several Internet services during pentest engagements. All this could easily be adapted for other protocols and services, so let's start to Screenshot All the Things.


The easiest way to snapshot these services is to use preexisting tools and script/mod them according to your needs. In order to take screenshots from VNC, I generally use noVNC (an HTML5 VNC client) and a command line utility to capture the WebKit's rendering of a web page.

The process is pretty straightforward:

1 - Clone the noVNC project from github:

git clone git://

2 - Start the mini-webserver and specify the location of the VNC server you want to screenshot:

./noVNC/utils/ --vnc

3 - Take a webpage screenshot from command line using CutyCapt, for example:

cutycapt --url="" --javascript=on --out=vnc.png --delay=3000

4 - Profit!!!

Now all you have to do is masscan the target for ports 5900-5910 (used by VNC), save the results on a text file and create a simple script to take the screenshots. You can also try vncsnapshot, used by @paulm during his Toorcon 2013 talk.


My tool of choice for taking snapshots of RDP services is Spark View. There's an HTML5 version for the tool available here and the process is quite similar to the VNC one:

1 - Download and install Spark View for Windows or Linux. Follow the procedure from the Admin Manual, install J2SE JDK, set the JAVA_HOME environment variable, extract, configure and compile the utils from commons-daemon-native.tar.gz. On Debian derivatives, you may need to edit and change the source function library to "/lib/lsb/init-functions".

2 - Start the service (./ start) and test it by accessing your local IP on port 80. Remote Spark provides a live demo for their solution here.

3 - Specify the RDP server settings on the querystring and take a webpage screenshot using a command line tool. I'm going to use phantomjs + url-to-image.js for this example:

phantomjs url-to-image.js "" rdp.png 800 600

4 - Profit!!!

Some commercial tools like Nessus also connects to RDP services and captures screenshots. Taking screenshots from RDP services is very useful to fingerprint operating systems and to map/identify domains and users on the network. I always output these images to OCR tools like tesseract and gocr in order to generate wordlists and compile other useful data:

RDP screenshot
gocr output
tesseract output


There's nothing much to be said about Web Services screenshots. There are lots of posts covering this topic and lots of different tools, including an Nmap plugin. Some references:

- Using Nmap to Screenshot Web Service (http-screenshot.nse)
PaulDotCom Security Weekly 295 - Tech Segment

EyeWitness - A Web Application Triage and Info-Gathering Tool


I find these tips very useful to get a better view of network services. Now that reporters are getting a pretty good idea from the attackers perspective, you have no excuse to leave your curtains exposed to the Internet without a VNC password. It's also important to practice safe computing, changing default passwords and enabling Network Level Authentication for RDP services.

Thursday, July 17, 2014

Hacking Asus RT-AC66U and Preparing for SOHOpelesslyBroken CTF

So it's finally July, time to pack for DEFCON, follow @defconparties on Twitter and decide which villages to visit and which talks to attend.

There's 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, that's my workstation =P
I'm particularly interested on the EFF Open Wireless Router, but they didn't disclose details about the device yet. According to the event rules, the ASUS RT-AC66U (HW Ver. A2) [Version] 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.


The first thing to do is to find the firmware and its source code. Hopefully, Asus RT-AC66U is GPL'ed 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. and v3. (the most recent one as of this writing).

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

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 (I'm not going to start discussing terminologies here).

Now that we have the source code, it's 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 you're more of a Linux user.

Let's 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:

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 Cutlip's 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:


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) won't 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. due to a vuln disclosed by Jacob Holcomb:

The binaries are MIPS and Little Edian:

It's 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.


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 URL's ending with ".ico".

Let's find out why: start gdbserver on the remote target (gdbserver --multi localhost:12345 &) and connect to your debugger of choice. If you're 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 gdbserver's host and port under "Debugger / Process Options" and attach to the corresponding PID.

Resume the process (F9) and make an HTTP request to 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 app's initial HTTP request:


You see that strange ddns_hostname? That's a crypto task =)


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

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. Let's generate a list of all the possible MAC addresses and brute force the hostnames using this cool trick from mubix.

If you're too lazy to run these commands, you can simply search for 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 (don't forget to include a chiptune from

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]

There are so many things to test on the Web application that I'll focus on a few different approaches. The router's 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 hackerfantastic's idea and test for potential bypasses (there's an extensive list of LFI tests at Seclists):

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

get_webdavInfo.asp is accessible without authentication and displays lots of sensitive information from the device and the network:

We can modify the nvram variables used to display this page and backdoor the router with a XSS payload, for example.

Some sensitive operations use the nvram_get and nvram_safe_get function. Some settings are stored using the nvram_set function. If the router does not sanitize the data being stored and retrieved from the NVRAM you may perform some kind of NVRAM Injection (remember, 00, %0A, %0D and `reboot` are always there for you).

AiCloud is a *very* vulnerable service that can be easily exploited too. When you activate the service, the router starts a lighttpd daemon on port 8082 (or 443 on newer firmwares) and offers the option to share your files online. The only caveat is that the username and password screen can be bypassed by visiting the /smb/ URL (read the source, Luke):

I wrote a simple AiCloud crawler that exploits this bug on RT-AC66U v3. It lists all the files/paths from the router (including the attached USB devices).

Last, but not least, don't forget to compare the differences between the files in the www directory. This path stores all the web components and scripts used by the web application.


Why not trying to open the hardware case without voiding the warranty seal? You may need some tips from the guys at the DEFCON Tamber Evident Village.

misc (a.k.a. Conclusion)

Hacking the Asus RT-AC66U is a very good exercise for the newcomers on router hacking. Most of its source code is available online and we can easily find lots of exploits and advisories for it. You may not have noticed but we tested every single aspect of the OWASP Internet of Things Top 10. Recent rumors indicate that this router is going to be used as the base for the OWASP IoT Webgoat and the Damn Vulnerable Embedded Linux.

Some additional approaches you should be taking and that should be awarded extra points during the contest:

  • Rewrite the bootloader to create a backdoored dual-boot partition
  • Backdoor the device in a way that firmware upgrades won't affect it
  • Brick the device remotely
  • Reprogram the LED to create a PONG game

There are many things that I still want to write about, but I'm saving that for future posts. If you are going to participate in the SOHOpelesslyBroken CTF and find this guide useful, feel free to ping me and let's get a coffee together during DEFCON/BsidesLV/Blackhat =)