Today I have for you a review of the article “Blackbox-Fuzzing of IoT Devices Using the R…

Today I have an article review for you "Blackbox-Fuzzing of IoT Devices Using the Router TL-WR902AC as Example" , which was written by Tobias Müller and which I read with very great interest 😅

This is just the diary of a novice researcher who decided to find a vulnerability in a TP-Link router, without having either the source code or the API ( in fact, nothing at all ). Just a black box, QEMU, AFL++ and a little stubbornness

The author of the article tried to find a memory bug in the TP-Link TL-WR902AC firmware through blackbox fuzzing, without knowing the admin logs and without access to the source code. He chose the path of pain: reverse firmware, search for suspicious binaries, hook on functions inside and create a harness to bypass architectural restrictions and simulate network calls. The most striking example is wscd, a UPnP daemon, in which he found a parser_append function that showed promise for buffer overflow

Sounds simple, right? But no 😳

Tobias found out that “finding a vulnerability” is only half the task. The other half is to force the program to actually call it. Almost every function requires a cleverly prepared state: the required init, a certain order of calls, specific byte values, and so on. Therefore, you won’t be able to go far without a good harness. And the harness, if anything, is assembled manually, with cross-compilation under mipsel, using LD_PRELOAD and even replacing libc functions

I especially liked the moment with httpd_parser_main: the author found a vulnerability in the parsing of HTTP headers, where strcpy does its dirty work in the absence of the expected ; . This is straight textbook buffer overflow. The problem is how to get there and make the code work. Through Ghidra, gdb-multiarch, and replacing rsa_tmp_decrypt_bypart with a simple base64 decoder - all this just to get to the point where everything crashes. At one point, the author even fixed a bug caused by missing \r after \n in headers, which resulted in a 408 instead of a normal response.

To summarize, IoT security testing is not about quick wins at all. This is about fiddling with binaries without debugging information, about crutches, rakes and figs, figure out how long it takes to launch QEMU in the hope that libc won’t fall off this time. Here it doesn’t even matter what you’re doing - fuzzing, reverse or environment simulation - everything comes down to one thing: the devices are closed, the firmware is unclear, and sometimes there is no documentation at all. But that’s exactly the thrill. Being able to open the black box and understand how everything works under the hood. And if you do find a bug, it’s not just a line in a report, it’s a victory over chaos 🧐

If you ever thought you wanted to get into hardware fuzzing ( do you have a personal life? ), this article is excellent th sample, which you can familiarize yourself with

Wow, today there was an abstruse post about an abstruse article. I promise next time there will be something simpler ❤️

#information_security
#internet_things