Hacking The Linksys WRT120N Part 2


[Craig Heffner] has been busy with his Linksys WRT120N router. When we last checked in on [Craig] he had reverse engineered the obfuscation techniques used in the router’s firmware. Since then, he’s re-enabled JTAG, cracked the “encryption” used for saving configuration backups, and now he’s devised a simple attack to change the admin password.  With the firmware unlocked, [Craig] went after the hardware JTAG. His first hurdle was a missing jumper connecting the TDI pin to the processor. With a solder blob making the connection, he then found the router would connect to his JTAG debugger, and immediately reset. TDI had been re-used as a GPIO in software, and assigned to the reset button on the back of the router. [Craig’s] JTAG pod was pulling the pin low and causing the reset. To make matters worse, the bootloader also redefined and checked for the reset button. If the button were pressed it would boot into a recovery mode. [Craig] patched the bootloader with a little help from IDA pro. He then desoldered the router’s flash and programmed it outside the system. The firmware required a similar patch. Rather than desolder the flash chip again, [Craig] created a firmware update the router would accept and flashed it via the router’s web interface.

Since he already was deep into the Linksys Firmware, [Craig] looked for any obvious attack vectors. He found a big one in the /cgi/tmUnBlock.cgi. Inside the firmware, the URL sent to the CGI would be sent through sprintf().  In plain english, it means that no input length checking was happening – so a URL longer than the firmware engineers expected (in this case 256 bytes) would overflow into areas of memory it wasn’t supposed to – in this case, the stack. For an astute attacker, that’s a wide open door.  [Craig] was able to use find some Return Oriented Programming (ROP) gadgets and created an input value that would cause the router to reset its own administrator password. After running the exploit, a quick trip to the router’s webpage proved his attack was successful.

If that wasn’t enough, [Craig] also spent some time looking at the patches to the router’s firmware. The release notes of one of the patches mentioned encrypting configuration files. The WRT120N, like many routers, allows the owner to download and save the configuration as a file. It turned out that the “encryption” scheme was nothing more than an exclusive OR with 0xFF. A pretty weak encryption scheme by any standards. To [Craig] we send our congratulations. To the WRT120N software engineers, we’d suggest taking one of [Craig’s] embedded device exploitation classes.

12 thoughts on “Hacking The Linksys WRT120N Part 2

  1. Wait, so if I understand this correctly, anyone on your LAN can overwrite the admin password with a simple URL? *sigh* (is this the same exploit that “TheMoon” uses?)

    What’s absurd is the number of router exploits I’ve been hearing about in the past month. This is making me glad that I built a PFSense machine recently.

  2. Awesome work..
    Now if Craig could take a crack at the Toshiba Flashair, that would be awesome..
    I have been messing around with getting into the firmware to write my own code for a little now..
    I have my documentation here:
    I recently ran their update file through IDA and it seems to be Armv6 litttle endian, but I cant find the boot entry point.. Of course I am still new to cracking embedded devices so I have much to learn.

    1. It would be easier if the firmware image is the entire ROM, so the known vector table points to code where the disassemble can get to work on. It would follow the branches and call graph etc to figure out where the code is. Even then, the disassembler can get loss if there is a branch table and that’s when the human part comes in. That’s why IDA is *interactive*.

      Now if the update image is only part of the ROM and you don’t have access to the bootloader that gets to optionally unpack/decrypt it or jump to some offset etc., you have to make guess as to where is the code and data. Make some assumptions and see the results. If code turns out to be moon runes, then it might be data. Find out where it makes sense. JTAG/SWD for in circuit debugger if there is such an option would make life a bit easier.

      I combined a disassembler with a simulator and let it ran on my machine that ran BASIC back in the old days before Windows and the internet. It was fun seeing what the code was doing on stack of fan fold paper out of the poor dot matrix printer.

      1. Thanks for the info.
        I am not sure if the boot loader is included in the file, I do know that that from what I have researched they do add and update major features on the card with these files, but that does not necessarily mean it includes the boot loader.
        I am sure if I were to cut the card open, there would be some kind of serial interface, not sure about jtag though.
        Either way it would be nice to add some features to the card. Of course, I could always go out and buy one of the transcends or flucards as they already run Linux, but I already have the Flashair,
        I figured I might as well see what could be done, and maybe learn something new along the way.

  3. Ads now for grossly over priced classes, which teach nothing more than what is available from countless sources online for free.

    And no, the people who designed this device would not benefit at all one from one of his classes. They teach nothing about securing code, and Adam would have realized this if he actually bothered to read the course topics list.

    1. You are assuming that they are paid to make a secured product instead of just managing to deliver something that passes for “working” and jump to the next product somewhere between schedules, fire fights, burn outs and insanity.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.