Overview
This series, entitled Broken, Abandoned, and Forgotten Code, is about an unauthenticated firmware update mechanism in the Netgear R6200 wireless router's UPnP service. Bypassing authentication and updating the firmware would be moderately interesting by itself. What makes this particularly interesting, however, is this capability appears only partially implemented. It's not quite dead code; more like zombie code. It's wired up just enough to kind of work. There are many artifacts of incomplete implementation that stand in the way of straightforward exploitation.The goal: build an exploit that accounts for the many implementation bugs, which then updates the target with a custom firmware, giving us persistent control over the target device. This, of course, requires not just building the exploit, but specially crafting a firmware image.
Where We've Been
Here's a summary of what we've covered in the series up to now.
- Part 1, part 2: Introduced the hidden
SetFirmwareSOAP action as well as the weird timing games needed to exploit it. We reverse engineered what HTTP headers are required to exercise this code path. - Part 3: We reverse engineered what the body of the
SetFirmwareSOAP request should look like. - Part 4: We discovered a crash when attempting to update to a stock firmware downloaded from Netgear's support website. The crash is due to an undersized memory allocation. We will have to shrink the firmware from nearly 9MB to 4MB in order to exploit the
SetFirmwarevulnerability. - Part 5, part 6, & part 7: It will be necessary to specially craft a firmware image if we are to take control of the target, so we reverse engineered the mystery 58-byte header at the beginning of the stock image. Because
upnpdis so broken, we instead analyzedhttpd, knowing that it can update a well-formed firmware image without crashing.
Where We're Going
From here there are still a number of challenges. We'll need to spend more time analyzing
upnpd; it may not even be able to update the firmware without crashing (spoiler alert: it is). Even if it can, there may be differences in the firmware format as expected by upnpd vs the standard format parsed by httpd.
Assuming we can get through
upnpd's update process, there remains the problem from part 4: a firmware image greater than 4MB crashes upnpd. We'll need to spend some time shrinking the firmware from nearly 9MB to 4MB or less.
Any project involving reverse engineering and customizing firmware will, at some point, result in bricked hardware. We'll devote an installment to discovering the hidden UART connection inside the R6200 that will enable recovery in the likely case of a bad firmware update.
One installment will cover a
upnpd crash after the firmware update process but before reboot. I'll discuss how to customize the firmware header to avoid the crash.
The stage 1 firmware has a few things it must do autonomously if it is to reboot into a trojan stage 2. I'll discuss those things and how to accomplish them.
We'll close out with an installment on post-exploitation. Once you're as far as customizing your own firmware and getting it onto your target, the world is your oyster. We'll discuss a simple technique that will yield remote, post-exploitation access, even from behind a firewall.
While you're waiting here's a video of the exploit in action I shared in the prologue. In the left terminal you see what's going on under the hood via the serial console. In the right terminal, you see the actual exploitation taking place. Also, there's cool music.
R6200 Firmware Upload from Zach on Vimeo.
More to Come, so Stay Tuned
Take a moment to go out to the lobby, stretch your legs, and use the facilities. We've covered a lot, but we're only halfway through. There's a lot more fun on the way, starting with Part 8!
