Pentesting IoT devices (Part 2: Dynamic Analysis)

This is the second part of our Pentesting IoT devices guide. In the previous post it was provided an overview on firmware static analysis showing how it can help to find many security issues. In this article it will be discussed the so called dynamic approach for device pentesting. It will be described how it is possible, thanks to firmware emulation, to improve pentesters' skills and test devices without physically have them.

Dynamic Analysis

The dynamic test of a device, from a security perspective, includes different activities and for each of them there is a specific testing methodology. For example, after a preliminary recon phase against a device, it is possible to face different services like a web server, an FTP service and even an unknown open port related to a customized communication protocol. In this case it is important to split test scenarios and apply a different methodology for each class of services. A great approach could be to test the web interface looking for the typical web vulnerabilities, then focusing on the FTP service and, in the end, studying the customized protocol by sniffing the device traffic or by fuzzing it.
The OWASP IoT attack surface areas provides a useful checklist that helps pentesters in focusing and prioritizing their analysis.

Since it is not possible to describe all the dynamic analysis that a tester could perform against a device, this article focuses the attention on showing an effective way to emulate an IoT device.

Firmware Emulation

The possibility to emulate a device starting from its firmware allows researchers to perform any kind of dynamic tests against it without having the physical device and without worrying about a possible brick. Actually, this kind of analysis are very effective in consultancy activities because sometimes it is necessary to work under particular circumstances, for example, when it is not allowed to test the real device because it's a production device or it is impossible to get the physical device because it is installed in an unreachable place but, in any case, a device firmware copy and a suitable emulator are provided. The main limitation of this technique is that not all devices firmwares and architectures can be easily emulated.

Firmadyne

Firmadyne is a tool which allows you to emulate, thanks to QEMU, a Linux-based firmware and perform basic dynamic analysis against it.

As sentenced from its own github page:“FIRMADYNE is an automated and scalable system for performing emulation and dynamic analysis of Linux-based embedded firmware.”

The aim of this software is to provide an automated way of testing a large number of firmwares with some test cases like nmap service discovery, snmpwalk or metasploit.
Currently it supports the emulation of three different CPUs architectures combinations:

• little-endian ARM
• little-endian MIPS 
• big-endian MIPS

Below a step-by-step usage example of Firmadyne with the NetGear WN604 Router Firmware as test case is shown.

The first step consists in the firmware extraction that Firmadyne accomplishes with the extractor.py script. This operation creates a zipped version of the firmware filesystem inside the images folder.

$ ./sources/extractor/extractor.py -b netgear -sql 127.0.0.1 -np -nk "WN604 Firmware Version 2.0.1.zip" images

>> Database Image ID: 20

>> MD5: f961fcc6d198940c2aaebb18b836f795

>> Tag: 20

>> Temp: /tmp/tmpZDScTD

>> Status: Kernel: True, Rootfs: False, Do_Kernel: False,                 Do_Rootfs: True

>>>> Zip archive data, at least v2.0 to extract, compressed size: 710, uncompressed size: 1351, name: ReleaseNotes_WN604_fw_2.0.1.html

>> Recursing into archive ...

[. . .]

/tmp/tmpSVfpkn/_WN604_V2.0.1_firmware.tar.extracted/rootfs.squashfs

>> MD5: fb9c11e075a37a8a5c989743897e8735

>> Tag: 20

>> Temp: /tmp/tmpWfQ7yl

>> Status: Kernel: True, Rootfs: False, Do_Kernel: False,                 Do_Rootfs: True

>> Recursing into archive ...

>>>> Squashfs filesystem, big endian, lzma signature, version 3.1, size: 2333384 bytes, 650 inodes, blocksize: 131072 bytes, created: 2010-03-26 11:55:15

>>>> Found Linux filesystem in /tmp/tmpWfQ7yl/_rootfs.squashfs.extracted/squashfs-root!

The second step is identifying the device architecture and store the result into the database (note that the number 20 is the image ID given by Firmadyne to this firmware).

$ ./scripts/getArch.sh ./images/20.tar.gz 

./bin/busybox: mipseb

The third step is loading the content of the filesystem into the database and then create a QEMU disk image with the makeImage.sh script.

$ ./scripts/tar2db.py -i 20 -f ./images/20.tar.gz 

$ sudo ./scripts/makeImage.sh 20

Querying database for architecture... Password for user firmadyne: 

mipseb

----Running----

----Copying Filesystem Tarball----

----Creating QEMU Image----

Formatting '/home/lcomi/work/clients/minded/firmadyne//scratch//20//image.raw', fmt=raw size=1073741824

----Creating Partition Table----

Welcome to fdisk (util-linux 2.31.1).

Changes will remain in memory only, until you decide to write them.

[. . .]

Once the image is ready it is time to infer firmware network configuration.

$ sudo ./scripts/inferNetwork.sh 20

Querying database for architecture... Password for user firmadyne: 

mipseb

Running firmware 20: terminating after 120 secs...

qemu-system-mips: -net nic,vlan=0: 'vlan' is deprecated. Please use 'netdev' instead.

Bad SWSTYLE=0x04

qemu-system-mips: terminating on signal 2 from pid 19371 (timeout)

Inferring network...

Interfaces: [('brtrunk', '192.168.0.100')]

Done!

Note: if infernetwork.sh cannot identify any interfaces for the aforementioned firmware, it may be necessary to fix Firmadyne script as described by this issue.

In the end it is possible to launch the firmware emulation with the run.sh script.

$ sudo ./scratch/20/run.sh

Creating TAP device tap20_0...

Set 'tap20_0' persistent and owned by uid 0

Bringing up TAP device...

Adding route to 192.168.0.100...

Starting firmware emulation... use Ctrl-a + x to exit

qemu-system-mips: -net nic,vlan=0: 'vlan' is deprecated. Please use 'netdev' instead.

[    0.000000] Linux version 2.6.32.70 (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:39:21 UTC 2016

[    0.000000] 

[    0.000000] LINUX started...

[    0.000000] bootconsole [early0] enabled

[    0.000000] CPU revision is: 00019300 (MIPS 24Kc)

[    0.000000] FPU revision is: 00739300

[    0.000000] Determined physical RAM map:

[    0.000000]  memory: 00001000 @ 00000000 (reserved)

[    0.000000]  memory: 000ef000 @ 00001000 (ROM data)

[    0.000000]  memory: 0061e000 @ 000f0000 (reserved)

[    0.000000]  memory: 0f8f1000 @ 0070e000 (usable)

[    0.000000] debug: ignoring loglevel setting.

[. . .]

As can be seen from the nmap output and from the following picture, all the device services are available over the network at IP address 192.168.0.100 and they can be analyzed by using the scripts included in Firmadyne analysis folder.

$ nmap -p- -sV -T4 192.168.0.100

Starting Nmap 7.70 ( https://nmap.org ) at 2018-09-19 17:12 CEST
Nmap scan report for 192.168.0.100
Host is up (0.00070s latency).
Not shown: 65532 closed ports
PORT    STATE SERVICE VERSION
22/tcp  open  ssh     Dropbear sshd 0.51 (protocol 2.0)
80/tcp  open  http    lighttpd 1.4.18
443/tcp open  ssl     OpenSSL (SSLv3)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Device web interface is listening on port 80. 

Being a pentester who wants to manually conduct his own dynamic analysis and without being interested in the "statistic" capabilities of Firmadyne, it would be useful to employ this tool only to extract and emulate a device firmware. Considering this approach, it was created a simple but effective script called firmadyne-launcher to easily automate the emulation of a firmware.

After having installed and configured Firmadyne, it is possible to clone firmadyne-launcher repository on your local machine and move firmadyne_laucher.sh inside Firmadyne application folder. Now, providing a firmware file as argument, the script can be started.

lcomi@aquarius:~/firmadyne$ ./firmadyne_launcher.sh firmware.zip
Extracting the firmware...
Getting the architecture...
Creating the image...
Creating TAP device tap7_0...
Set 'tap7_0' persistent and owned by uid 0
Bringing up TAP device...
Adding route to 192.168.0.100...
Starting firmware emulation... use Ctrl-a + x to exit
qemu-system-mips: -net nic,vlan=0: 'vlan' is deprecated. Please use 'netdev' instead.
[    0.000000] Linux version 2.6.32.70 (vagrant@vagrant-ubuntu-trusty-64) (gcc version 5.3.0 (GCC) ) #1 Thu Feb 18 01:39:21 UTC 2016
[    0.000000] 
[    0.000000] LINUX started...
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019300 (MIPS 24Kc)
[    0.000000] FPU revision is: 00739300
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 00001000 @ 00000000 (reserved)
[    0.000000]  memory: 000ef000 @ 00001000 (ROM data)
[ . . . ]
Welcome to SDK.
Have a lot of fun...
netgear123456 login: 

Looking for web vulnerabilities

To prove that it is possible to dynamically test an emulated device like a physical one, some interesting web vulnerabilities could be hunted. Below it is given an example about the findings of a new reflected XSS inside the web interface of the Dlink 850L router. The vulnerable firmware can be found here.

Router login page, the default password is empty.

After the login page, that can be simply bypassed using the default credentials, it is possible to see different menu and configuration options which a user can modify. After mapping some of them with the help of a proxy like Burp, it was noticed that a particular handler had a vulnerable parameter that led us to trigger an XSS through the following tampered GET request:

http://192.168.0.1/[HANDLER]?[PARAM]=</script><script>alert(document.cookie)</script>

Execution of the arbitrary JS code inside the victim's browser. 

The details of this vulnerability, addressed as CVE-2018-17779, are actually redacted to allow Dlink to patch any vulnerable firmwares.

It is suggested to download the aforementioned D-Link firmware and try to find out many other vulnerabilities. Another great exercise is to manually extract the device filesystem (following the first part of this guide) and localize any dynamic analysis findings (like the xss-vulnerable web page) inside the source code and then find a solution to fix them.

Conclusions

In this article it was shown how it is possible to emulate a firmware device and what are its main advantages and limitations. Thanks to this technique, a new vulnerability inside Dlink DIR-850L web interface was found, even without having the physical device.

This post closes our IoT pentesting serie, where both static and dynamic approach in firmwares security review have been discussed. It is important to underline that IoT manufacturers have to consider the security of their products as a top priority and researchers should have the possibility to freely test devices to find out new vulnerabilities and responsibly disclose them.

References

• https://github.com/firmadyne/firmadyne/blob/master/paper/paper.pdf
• https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0days-vulnerabilities.html