We’re about halfway through the Broken, Abandoned series, so this is a good time to pause for a minute and take stock. At this point, things have gotten pretty technical; if you’ve only joined recently, you may be wondering what this series is about. I want to take a moment to summarize where we’ve been and where we can expect to go from here.
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.
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.
We reverse engineered what the body of the
SetFirmwareSOAP request should look like.
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
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 analyzed
httpd, 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
Assuming we can get through
upnpd’s update process, there remains the
problem from part
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!