Introduction to Firmware Analysis
Last updated
Was this helpful?
Last updated
Was this helpful?
The purpose of this document is to provide a guide to firmware analysis, this will include both dynamic and static analysis. This will utilize an intentionally vulnerable firmware sample, for this “IoTGoat” from the OWASP Foundation suits this purpose. this is due to the inherent security and legal implications of publicly exploiting a production sample, however keep in mind all techniques and exploitation methods shown are realistic and applicable to samples found within the wild.
In order to perform firmware analysis, a environment must first be configured. For the purposes of this document, AttifyOS a linux distribution designed for embedded device exploitation perfectly suits this need. Additionally, configuring IoTGoat for both static and dynamic analysis requires several dependencies, these consisting of the static image file and the virtual machine provided. Below is a table of all required downloads. NOTE: Make sure the IoTGoat image file is downloaded within your AttifyOS machine whereas the IoTGoat virtual machine is downloaded on the host computer.
Required Downloads
Within your AttifyOS virtual machine (root password “attify”), open a terminal and run the following commands.
Often times firmware samples are incredibly tricky to properly emulate, because of that this document will focus on static analysis with dynamic analysis to prove findings.
To begin with analysis, the tool binwalk will be used. Binwalk is a powerful suite used for firmware extraction any analysis. Firstly run the command “binwalk -e imagefile.img” to extract the filesystem from the image file.
Upon running this command, binwalk will attempt to extract the file system while also displaying important information. Such as the following:
Within this output, it becomes apparent this is a Linux based firmware sample. The vast majority of firmware samples are linux based, however this uses the squashfs compression filesystem. Upon extraction of the filesystem, the first point of interest would be discovery of hardcoded user credentials, this is due to both the commonality and ease of finding these. To begin, browse to the “etc” directory, here both the “passwd” and “shadow” files are present.
By combining the shadow and passwd files, the earlier tool installed johntheripper can attempt to brute force password hashes. For this, run the following command:
Upon completion of downloading the text file, run the following command to begin the brute-force process.
The result of the prior command will be the output below:
Within this output, the “iotgoatuser” has a password of “7ujMko0vizxv”. At this point, base user credentials have been discovered, however before continuing by abusing these credentials, there are several more discoveries to be made within the filesystem. For this, the “firmwalker” tool previously installed will be used. Go to the directory of the downloaded tool, and run the script providing the path to the extracted filesystem.
Upon completion of this script, several discoveries will be made. However the first focus will be on the database related files.
Within your terminal, proceed to the path of the database above. This is a sqlite3 database, simply run the following commands:
This sequence of commands will provide the following output:
Within the senors table, sensitive pseudo user data and credentials are exposed. While this may not directly be related to exploitation in this case, within a real product this would be a massive security flaw. Within this same directory, a file named “iotgoat.lua” is present. The contents of this file are below:
These appear to be entries for a web server running. However the entry “cmdinject” look particularly interesting. By browsing to the “/lua/luci/view/iotgoat/” path the cmd.htm file is present. The contents for this file are below.
Upon analysis of the contents for the cmd.htm file, it is discovered this is a “diagnostic console” which allows a user to run any command on the device as root. These hidden developer consoles are common within firmware production samples and essentially gives access to any malicious threat actor.
To recap the findings from the static analysis performed:
Weak unsalted user credentials which can be brute-forced giving an attacker access to the device via SSH.
Improper database management exposing personal information and credentials of consumers.
Insecure developer console which allows for command injection.
Opposed to searching through a file system, the IoTGoat virtual machine allows for dynamic analysis with the device running. In a real situation, this could be compared to either emulating firmware or having the psychical device to test. Simply start the IoTGoat virtual machine and return to the AttifyOS machine, open a terminal and execute the following command:
Locate the IP address from the IoTGoat virtual machine.
Upon discovery of the ip address, there are several routes to take, the first being discovery of all services and service version. This can be accomplished with the nmap tool, run the following command:
The flags used with nmap correlate to the following:
-sC = Scan with default scripts
-sV = Service version
-vv = Verbose output
-p- = Scan all ports
Upon completion of this scan, a sizeable amount of output will be displayed, however the following is the key information from the scan:
While the first notable thing would be the SSH service running, the user credentials found previously can be used to SSH into the device, while doing this will result in a shell it is still best practice to be through within analysis. For this, checking if service versions are outdated with publicly available CVE’s can provide to be fruitful. For example, while a device may not be inherently vulnerable, if a service has not been maintained, it can lead to vulnerabilities within the device. For example, the dnsmasq service version running suffers from several memory corruption vulnerabilities.
Due to this being an introductionary guide, the intricacies of these memory corruption vulnerabilities will not be covered, this will be saved for a later document focused on memory corruption exploitation.
One key finding from the NMAP scan which was also previously discovered within the static analysis is the presence of a web server. However now due to the firmware running, the web application can be dynamically tested. Simply open a browser and enter the IP address of the device, this will lead you to a login prompt with the password of “iotgoathardcodedpassword”.
Next browse to the “https:///cgi-bin/luci/admin/iotgoat/cmdinject” page to confirm the previous findings. Here you will see the developer console which allows for the input of commands.
At this point commands may be given as input. Further analysis must be performed on the web server, one common vulnerability is Cross Site Scripting (XSS) for this browse to the “https:///cgi-bin/luci/admin/network/firewall/rules” page. Creating a new rule allows for the input of a name, this parameter is vulnerable to cross site scripting. For a proof of concept, enter the following JavaScript within the name parameter:
alert("Introduction to Fimrware Analysis");
Then click the “Add and Edit” button to see the XSS payload in effect.
Several other cross site scripting vulnerabilities reside within the web application, I encourage you to individually find these. In conclusion, the following was covered:
Service discovery using NMAP.
Outdated and vulnerable service discovery.
Cross Site Scripting vulnerabilities.
Once this file has been prepared, the only missing component for brute forcing is a dictionary, this is a text file of words which will be compared to the user hashes. In this case, the wordlist from the Mirai botnet will suffice, you may download this text file .
This document serves the purpose of being an introduction, however further documents will be released which covers each topic in much greater detail. If you have any questions, comments, or concerns you may contact me on .
