Pentesting IoT devices (Part 1: Static Analysis)

Introduction

Intelligent dishwashers, smart factories, connected sensors and Wi-Fi fridges, these are only a few examples of everyday objects that now are connected to the Internet.
All these "brainless" objects have been upgraded to become Internet of Things devices and now they’re changing our lifestyle communicating with us at anytime and in any place.
As security experts have to face the challenge of testing the security of these devices in order to find their vulnerabilities before bad guys do.
At the same time, it is also important to make manufacturers and organizations aware of the security risks associated with this kind of devices.

This article has been written to do a brief overview of the IoT testing approach that we use during our activities here in Minded Security.
It has to be noted that this article is not to be intended as a strict guide suitable for all situations but as a starting point for developing your own testing methodology and a good arsenal of tools suitable for the majority of IoT security assessments. Now, let's start with the fun.

Preliminary Analysis

The first thing to do in order to better understand an IoT device is to perform some preliminary analysis which consists in conducting the first recon on a new firmware we have never seen before.
The main goal here is to get an idea about the firmware architecture and if it is encrypted or not.

Firmware package will be analyzed and the file system will have to be unpacked and extracted.

This process can be summarized in the following steps:

• Identify the target device: if you don’t know what device runs your firmware, additional analysis needs to be performed for example with an internet search.
• Understand if a firmware is encrypted or compressed: 
• use strings against the firmware, and if there are no strings in the output the file is probably obfuscated. 
• launch hexdump with the “-C” argument which provides some context for the strings. 
• use Radare with “izz” command to search for non-ASCII characters i.e. Unicode-encoded strings.
• Identify firmware architecture and FS: Binwalk is useful to examine and extract binary files so launch it against the firmware without any argument in order to gain useful information about it.
• Extract the Filesystem: once the filesystem type has been identified (i.e. Squashfs, Cramfs, YAFFS2 and so on) the next steps are:
• extract it from the firmware 
• mount it in order to access the data inside. According to the filesystem type of your device, it is possible to use different tools like dd, binwalk or fmk to extract the fylesystem.

Below it is provided an example of a preliminary analysis performed with binwalk and regarding the DLink WiFi Day & Night DCS‑932L camera firmware.

$ binwalk DCS-932L_fw_v108_b2.bin
DECIMAL       HEXADECIMAL     DESCRIPTION
------------------------------------------------------------------------
106352        0x19F70         U-Boot version string, "U-Boot 1.1.3"
106816        0x1A140         CRC32 polynomial table, little endian
124544        0x1E680         HTML document header
124890        0x1E7DA         HTML document footer
124900        0x1E7E4         HTML document header
125092        0x1E8A4         HTML document footer
125260        0x1E94C         HTML document header
125953        0x1EC01         HTML document footer
327680        0x50000         uImage header, header size: 64 bytes, header CRC: 0x1457B432, created: 2014-02-11 05:50:43, image size: 3678347 bytes, Data Address: 0x80000000, Entry Point: 0x803B8000, data CRC: 0x6E80DDBC, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744        0x50040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6433659 bytes

As you can see from the tool output, there's a linux kernel inside a uImage at position 0x50000 and some LZMA compressed data at 0x50040 that could be the filesystem.
Let’s go ahead and unzip the firmware of the IPcamera with

binwalk -eM DCS-932L_fw_v108_b2.bin

command (the “-e” option extract the file and “-M” tells binwalk to perform the extraction recursively).

As a result you will see (inside /_DCS-932L_fw_v108_b2.bin.extracted/_50040.extracted folder) a file named 3DA000 that needs to be investigate further.
Using the command “file” it is possible to see that it is a cpio archive which contains a filesystem.

$ file 3DA000
3DA000: ASCII cpio archive (SVR4 with no CRC)

At this point it is possible to use the “cpio” command to extract the filesystem as shown below:

$ cpio -ivd --no-absolute-filenames -F 3DA000
cpio: Removing leading `/' from member names
bin
bin/chmod
bin/busybox
bin/nvram_set
bin/ls
bin/touch
bin/upgradefw
bin/ntpclient
bin/grep
bin/htmlunpack
bin/nvram_daemon
bin/ash
bin/pcmcmd
bin/sed
bin/mount
[. . .]

Finally we can see and navigate through the firmware directories:

$ ls
bin  dev  etc  etc_ro  home  init  lib  media  mnt  mydlink  proc  sbin  sys  tmp  usr  var

Please note that, you can find the same files and folders if you look inside the /_DCS-932L_fw_v108_b2.bin.extracted/_50040.extracted/_3DA000.extracted/cpio-root folder because binwalk has already extracted them, but, for the sake of completeness, we preferred to show the use of “cpio” command to extract the files.

Now that we managed to correctly extract and access the filesystem, our interest is to find any kind of security-related issues or bad practices such as:

• Hardcoded credentials
• Weak credentials hash contained in files like /etc/passwd
• Custom scripts or configuration files with any kind of sensitive information
• Web pages or binary source files that could be vulnerable to code injection
• Private keys 
• Links and IP addresses that could expand the attack surface of the IoT device

A great list of IoT-related vulnerabilities as well as other examples of the previous mentioned tools usage, could be found under the OWASP IoT project at the following link:

• https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

Static Analysis

In the this section we are going to present three different methods to perform the static analysis of a filesystem:

• the first one is a full “manual” research with a small piece of automation; 
• then we will present a tool called firmwalker that aims to scrape through the files and extract useful information;
• finally we are going to show a fully automated tool (FACT) that automatically extract and analyze a firmware.

Manual

As you can see from the following example, grepping for the keyword “admin” it is possible to notice a file, RT2860_default_novlan, that could be interesting to further analyze. 

$ grep -iR admin

[. . .]

etc_ro/Wireless/RT2860AP/RT2860_default_vlan:#Login=admin
etc_ro/Wireless/RT2860AP/RT2860_default_vlan:#Password=admin
etc_ro/Wireless/RT2860AP/RT2860_default_vlan:AdminID=admin
etc_ro/Wireless/RT2860AP/RT2860_default_vlan:AdminPassword=
etc_ro/Wireless/RT2860AP/RT2860_default_novlan:Login=admin
etc_ro/Wireless/RT2860AP/RT2860_default_novlan:Password=admin

[. . .]

In the snippet below we printed the configuration file with some juicy information:

$ cat RT2860_default_novlan

#The word of "Default" must not be removed
Default
WebInit=1
HostName=ralink
Login=admin
Password=admin
OperationMode=0
Platform=RT3052
wanConnectionMode=STATIC
wan_ipaddr=10.10.10.254
wan_netmask=255.255.255.0
wan_gateway=10.10.10.253
wan_primary_dns=10.10.10.251
wan_secondary_dns=168.95.1.1
wan_pppoe_user=pppoe_user
wan_pppoe_pass=pppoe_passwd
wan_l2tp_server=l2tp_server
wan_l2tp_user=l2tp_user
wan_l2tp_pass=l2tp_passwd

[. . .]

Automated

Firmwalker is a script that uses a list of different interesting files and keywords inside your firmware filesystem directory to help automating the research for point of interests.
The tool bases its search on many keywords divided in category such as: binaries, passfiles and so on (for more details you can find all the keywords listed inside the /data folder, as you can see from its github page).
The tool usage is very simple because you have to specify only the filesystem folder as input:

./firmwalker.sh /cpio-root

***Firmware Directory***
/cpio-root
***Search for password files***
##################################### passwd
[. . .]

***Search for files***
##################################### *.conf
t/etc_ro/lld2d.conf

***Search for shell scripts***
##################################### shell scripts
t/sbin/vpn-passthru.sh
t/sbin/zcip.sh
t/sbin/pppoe.sh
t/sbin/config-igmpproxy.sh
t/sbin/web.sh
t/sbin/wan.sh
t/sbin/cameraname.sh
t/sbin/dhcp.sh
-------------------- password --------------------
[. . .]
t/etc_ro/web/account.htm
t/etc_ro/openssl.cnf
t/etc_ro/Wireless/RT2860AP/RT2860_default_vlan
t/etc_ro/Wireless/RT2860AP/RT2860_default_novlan
[. . .]


***Search for ip addresses***
##################################### ip addresses
0.0.0.0
10.10.10.100
10.10.10.200
10.10.10.251
10.10.10.253
10.10.10.254
1.2.3.4
1.5.6.1
1.6.4.4
[. . .]

As you can see it's easy to find some potentially sensitive files or scripts or other private data. You can also notice that firmwalker has found something interesting in RT2860_default_novlan file so it has listed that under the "password" category. This behavior is due to the fact that, like we made manually, firmwalker has identified the keyword "admin" inside the file and specifically it is listed in firmwalker data/patterns file, as you can see from the tool source code.

Note: dealing with firmwalker, you'll have to install shodan cli or comment out the code lines that handle that part since the tool exits if shodan cli is not installed. More information about this bug.

FACT: firmware extraction and static analysis

“The Firmware Analysis and Comparison Tool (formerly known as Fraunhofer's Firmware Analysis Framework (FAF)) is intended to automate most of the firmware analysis process. It unpacks arbitrary firmware files and processes several analysis. Additionally, it can compare several images or single files.”

If you need a fast and fully automated analysis this tool is what you are looking for. Without knowing anything about binwalk, firmwalker and so on it is possible to get the same results in terms of firmwares extraction and static analysis using FACT. Below we have listed the main features of this tool:

• Easy to use thanks to the graphical web user interface
• Fully automated process of extraction and static analysis
• Expansible with custom plugins

In order to test FACT functionalities, we used the aforementioned Dlink firmware as input and we selected different analysis options, as shown in the below picture:

Different kind of tests that FACT can perform against a firmware

Once the analysis are over, it is possible to review the results through different sub-menus. For example, as you can see in the below images, FACT has provided: general information about the firmware, a binwalk analysis with also an entropy graph useful to show if a firmware is encrypted and the name of some firmware binaries.

General information about the analyzed firmware

Binwalk and entropy analysis results

Binaries found inside the firmware 

As a final consideration about this tool, we can say that: FACT allows a fast firmware analysis because all you have to do is feed it with a zip file containing the binaries and it will perform a complete static analysis through many tools.

Using the outputs to find vulnerabilities

To further investigate the aforementioned issue of the harcoded credentials, let's download from here the known-vulnerable Dlink-412 router firmware and manually analyze it in order to find some credentials left inside configuration files or custom scripts, which is usually a common problem in such kind of devices.

Once the filesystem is extracted through binwalk, it is possible to dig into it and search for possible misconfigured services like ssh or telnet that could allow a remote attacker to access the device. By using grep command with the "telnet" keyword, some interesting data can be quickly noticed.

$ grep -iR telnet
[...]

etc/init0.d/S80telnetd.sh: telnetd -l /usr/sbin/login -u Alphanetworks:$image_sign -i br0 &

etc/init0.d/S80telnetd.sh: telnetd &

etc/init0.d/S80telnetd.sh: killall telnetd

[...]

At this point it is already clear that using grep we have found an interesting script, S80telnetd.sh, that manages the telnet service. Currently, by analyzing the whole etc/init0.d/S80telnetd.sh script you can notice that telnetd process is going to be started with an hardcoded credential set: Alphanetworks as username and the content of image_sign variable as password.

$ cat S80telnetd.sh 
#!/bin/sh
echo [$0]: $1 ... > /dev/console
if [ "$1" = "start" ]; then
if [ -f "/usr/sbin/login" ]; then
image_sign=`cat /etc/config/image_sign`
telnetd -l /usr/sbin/login -u Alphanetworks:$image_sign -i br0 &
else
telnetd &
fi
else
killall telnetd
fi

In order to recover the password of the telnet service, we have to print the content of /etc/config/image_sign file.

$ cat ./config/image_sign
wrgn28_dlob_dir412

Finally we have discovered that the telnet server of the router is going to be executed with a preset of hardcoded credentials (Alphanetworks:wrgn28_dlob_dir412) and this misconfiguration represents a serious security concern because it could allow a malicious user (who knows this information) to easily break into the router.
It is interesting to notice that this kind of vulnerability can be found only by performing an effective manual code review and, tools such as firmwalker or FACT, can only help to identify interesting entry points (like the presence of a telnet service).

Conclusions

In this article on Pentesting IoT via static analysis we have shown a simple step by step guide to manually approach and analyze an unknown firmware. In particular we have discussed three different approaches to static firmware analysis (manual, automated and fully automated) through different practical examples. Lastly, we have highlighted how static analysis can be useful in finding a specific class of vulnerabilities.
The guide will continue in a second article, where we will deep dive into the dynamic analysis of the firmware.

References

• https://reverseengineering.stackexchange.com/questions/15006/approach-to-extract-useful-information-from-binary-file
• https://www.pentestpartners.com/security-blog/using-hexdump-analysis-for-firmware-extraction-a-how-to/
• https://resources.infosecinstitute.com/firmware-analysis-for-iot-devices/
• https://firmwaresecurity.com/
• http://elinux.org/File_Systems
• https://fkie-cad.github.io/FACT_core/