Wednesday, 14 December 2016

TP-Link Debug Protocol Gives Up Keys To Kingdom

If the headline makes today’s hack sound like it was easy, rest assured that it wasn’t. But if you’re interested in embedded device hacking, read on.

[Andres] wanted to install a custom OS firmware on a cheap home router, so he bought a router known to be reflashable only to find that the newer version of the firmware made that difficult. We’ve all been there. But instead of throwing the device in the closet, [Andres] beat it into submission, discovering a bug in the firmware, exploiting it, and writing it up for the manufacturer.  (And just as we’re going to press: posting the code for the downgrade exploit here.)

This is not a weekend hack — this took a professional many hours of serious labor. But it was made a lot easier because TP-Link left a debugging protocol active, listening on the LAN interface, and not requiring authentication. [Andres] found most of the information he needed in patents, and soon had debugging insight into the running device.

After some heavy-duty static reverse engineering based on the firmware that he downloaded from the manufacturer’s website, he found a buffer overflow opportunity in the code, and managed to run his own code over the debugging link.

Because [Andres] is a security professional, he gets paid for finding vulnerabilities like this, but also for making them sound ominous. Still, he notes that you can only reach the debug protocol over the local LAN, and not from the network at large. So it’s much more likely that you’ll use this exploit to flash the firmware of your choice than it is that any baddies would do so. (It’s not a bug, it’s a feature!) But still, this is an awesome hack!

Thanks to [norber] for the tip!


Filed under: misc hacks, security hacks

Read the full article here by Hack a Day

No comments: