Faraday CTF 2022 Write-up: Reverse Engineering and Exploiting an IoT bug

At the beginning of November this year, in Buenos Aires, Argentina, Faraday had the privilege to be a sponsor of the EKOParty security conference. As other sponsors, we had to build a couple of challenges for the CTF.

Ours had six challenges, from web vulnerabilities to exploits in embedded devices. The particular thing about those challenges was that they were inside the cheapest router in the market: our lovely TotoLink N100RE.

This is the write-up for the hardest challenge, a bug in a bad implementation of a ping client anticipating the FreeBSD bug one month before. The buggy ping could be triggered from the web panel; the binary was delivered in advance among the libraries needed to run it.

The binary doesn’t have protections against memory corruptions’s bugs.

In every binary challenge we need to make the reversing of the file, for educational purposes we grabbed the entire session of the reverse engineering process. The idea behind this video is to demonstrate some of Ghidra’s features which could be very helpful when we don’t have the challenge’s source code, for example:

• change name and type of variables
• identify common calls to libc in mips binaries
• set the right type to structures

In most of the write-ups of CTF, reverse engineering concepts are taken for granted. This is a problem for newcomers unfamiliar with some basic concepts or If don’t have prior experience in this field. However, this will be different. In this video, we will take you through a step-by-step of our decompiling session using Ghidra. This step-by-step is helpful for any static reversing but is particularly functional for IoT binaries.

The restored code is almost compilable:

This binary also had all the necessary files to run with Qemu as the team said in them twitter hint

In order to run successfully, the executable needs to receive the ip address of the target through the environment variable QUERY_STRING

This will be useful later because we can debug the sample with a debugger as gdb.

The bug is in the recvfrom call which receives 0x200 bytes, the icmp response has a size lower than that, but if we manipulate the response, we could trigger a stack buffer overflow.

To achieve this goal we need to disabled the kernel response to the incoming icmp packets using sysctl

Sending 0x200 bytes in the body of the ICMP packet we could manipulate the return address and hijack the control flow taking advantage of the absence of ASLR.

Exploit

As the binary does not have Data Execution Prevention,, we jump directly to the stack in order to execute our payload directly using the following binary’s gadget

Here is the full version of the exploit building a reverse shell with the pwntools set