Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Have you ever wanted to participate in Pwn2Own!? The author of this post took the jump into competing at this hacking event. They were part of a team with 2 other players trying in the routers, printers and phones event. They picked a consumer NETGEAR router since they thought it was the path of least resistance.

First, they started by opening up the box and getting a shell on the target. This was done by soldering some pins onto the device and interacting with a UART console. Luckily for them, it outputs a root shell with no further troubles.

Next, they started looking for juicy attack surfaces. In particular, they wanted to look into something that had never been popped before; this was to ensure their wouldn't be duplicates. Initially, they looked into uhttpd, which was able to invoke and run Lua extensions. The router had scrambled the opcodes, causing decompilation issues.

While looking at the netstat output, two open sockets on 0.0.0.0 were not associated with any process. It turned out that this was a network USB stack that was running in the kernel. Although this had been popped in the past, they found an integer overflow vulnerability they could be made into a smaller write than the size of the overflow! A user controlled value, without bounds checks, was passed into a call to malloc with additional values being added and multiplied. Pretty neat!

The exploit code to trigger this is less than a hundred lines of Python code. The buddy alloactor is used for allocating this chunk. This means that it's allocated in groups of 2**N pages, limiting the allocation sizes that can be used for the exploit.

The kernel driver was missing ASLR, NX and sent addresses (for debugging) over the network on a different port. Although they had a bug, they wanted to emulate NetUSB using QEMU to develop their exploit. After spending hours compiling and using other kernel, they learned about some compilation flags that must have been set on the build of this driver that weren't set on their builds. Eventually, they got everything to build!

They looked at the Linux source code and played around with different objects. Eventually, they learned that a small pause after the allocation of the buffer but before overflowing it, an interesting structure would be magically allocated fairly close to the buffer. Inside the wait_queue_entry object is a function pointer, which they choose to overwrite.

Getting code execution was as simple as overwriting the function pointer and jumping to existing code. Since ASLR and others things were turned off, they could even hardcode addresses! Porting this to the real router was pretty easy and had a success rate of about 3 out of 5 times.

Entering the contest was rough though... Netgear put a patch out the day before the event and they were unable to get their exploit to drop live. Overall, an awesome post on an end-to-end Pwn2Own experience with a good amount of diversity on the content.