Find Hidden Network Backdoor in WiFi Firmware
In this tutorial, you will learn how to use static analysis to check for backdoors in the OpenWRT firmware binary.
Hello World! Imagine you work on a security team in the forensics division. You have been given WiFi network's firmware to determine whether a suspicious binary is dangerous or not. We appreciate the network administrator's assistance in pointing out the target file. Today I'll go through how to examine WiFi firmware and detect dangerous programmes in it.
In case you want to practice this lab on the AttackDefense platform, here is the lab link – https://attackdefense.com/challengedetails?cid=102
There is only one file with the name firmware.bin in the current user's home directory (/root
). Binwalk can discover available files that are stacked on top of each other and automatically extract (through the -e
flag) them based on known types and deflators.
The firmware.bin binary, as you can see, contains two types of files: First, you'll notice some LZMA compressed data. Let's ignore it for the time being because the next file in the binary is SquashFS, which is our actual firmware filesystem containing files as well as the malicious binary.
Binwalk will extract the binary into the _firmware.bin.extracted directory. You will find another directory named squash-root, which will be the firmware's root file system.
To facilitate setup, the OpenWRT team included a /etc/rc.local file in the firmware that will execute as a bash script when system init is completed; by default, the file is empty with a comment in it.
You can see in file that it contains reference to script or binary with the absolute name /usr/bin/start_essentials and then exist 0
is executed. By the name alone, it appears to be a legitimate file, but let's dive deeper to learn more about it.
Using the file
command, you can determine the file type based on its magic number or content.
So the file type is bash script, and as you know, ASCII encoded files are used (human-readable). The $PIDFILE
variable, which is deduced from the $INPUT
and $PID
variables from the script, is run last in the start service function. It is obvious that the file is referring to another file located at /opt/5676.
The file /opt/5676 is again a bash script and execute another script / binary with absolute path /usr/bin/webhelper.
When the file type of squashfs-root/usr/bin/webhelper is examined, it is discovered that it is ELF executable and dynamically linked.
To learn more about the binary, run a static analysis using the strings
command and list all the human-readable data from the binary that is longer than or equal to 10 characters.
From the output of the strings
command, it is evident that the file is reading the contents of /etc/shadow file and sending attacker machine hosted at witrap.com domain name using POST request.
If this isn't enough to classify it as a malicious binary, let's take it a step further and read all the dynamic symbols from the import table while filtering only FUNC (function) with the readelf
command.
As you can see there are a lot of networking and file operation related functions are imported and referenced in the malicious binary:
fopen()
,fread()
andfclose()
functions could be used to open the /etc/shadow file, read its contents into a variable and then close the filegethostbyname()
is used to translate witrap.com host into IP addresss to establish connection usingconnect()
function.
Resources
- https://en.wikipedia.org/wiki/SquashFS
- https://superuser.com/questions/161722/how-to-list-imported-symbols-in-elf-executable
- https://forum.openwrt.org/t/executing-scripts-at-boot-time/91992
- https://github.com/frizb/FirmwareReverseEngineering/blob/master/IdentifyingCompressionAlgorithms.md#lzma
- https://github.com/frizb/FirmwareReverseEngineering/blob/master/IdentifyingCompressionAlgorithms.md#squashfs
- https://stackoverflow.com/questions/32737355/elf-dynamic-symbol-table