๐จโ๐ปExploiting Embedded Devices
Exploiting Embedded Devices
Static Analysis of Vulnerabilities
Static analysis of vulnerabilities involves looking for vulnerabilities by inspecting the update packages, file systems, and binaries of the system without having to power up the device being evaluated.
Analyzing the Update Package
Tools
unzip
binwalk
Firmware Mod Kit
D-Link DAP-1320
Download Firmware
https://files.dlink.com.au/products/DAP-1320/REV_A/Firmware/Firmware_v1.10b14/
Install Firmware Mod Kit
Clone Firmware Mod Kit
Extract Firmware
Browse Extracted Directory
NOTE
Performing Vulnerability Analysis
Common Vulnerabilities
Command-Injection
Format-String
Buffer-Overflow
Use-After-Free
Misconfiguration
and more
Look for format strings (%s)
Reverse Engineering SSI Binary
Grep download_fw_lp
At this point, we will move on to attempting to exploit the device through the firmware update.
Dynamic Analysis with Hardware
The static analysis portion of the assessment is complete. From this point forward, we will be looking at the system as it runs. We need to set up an environment for intercepting requests from the device to the WAN, connect the DAP-1320 to our test network, and begin exercising the firmware update process. The end goal is to execute something on the wireless extender through command injection.
The Test Environment Setup
The test setup weโve chosen uses 64-bit Kali Linux 2017, Ettercap, the DAP- 1320 wireless range extender with firmware version 1.11, and a stock wireless network. The idea is to ARP-spoof the DAP-1320 so that all traffic to and from the device goes through our Kali Linux system. Although we could have simply put a device inline between the extender and the router that can forward traffic after inspection and modification, ARP spoofing would be the likely attack mechanism used in the field.
Ettercap
As a quick refresher, Address Resolution Protocol (ARP) is the mechanism for resolving an IP address to its Media Access Control (MAC) address. The MAC address is a unique address assigned by the manufacturer of the network device. Simply put, when a station needs to communicate with another station, it uses ARP to determine the MAC address associated with the IP to use. ARP spoofing effectively poisons the ARP tables of the stations, causing them to use the attackerโs MAC address instead of the actual MAC address of the target station. Therefore, all traffic to a destination traverses through the attackerโs station. This effectively puts a device inline without having to physically modify the network.
Ettercap is a tool that allows us to ARP-spoof for the purposes of man-in- the-middle (MITM) attacks, parse the packets, modify them, and forward them to the recipient. To begin with, we use Ettercap to see the traffic between the device and the Internet by issuing the following command (where the device is 192.168.1.173 and the gateway is 192.168.1.1 in this example):
Wireshark
Click on the New Firmware button and then follow the TCP Stream within Wireshark.
By going to the URL we captured, we can see that the XML contains the FW versionโs major and minor numbers, the download site, and release notes.
Ettercap Filter
change the minor number to 12 and the firmware link to a shell command
In order to determine if our command is getting executed, we need to ping the box and monitor the ping messages as we issue an upgrade. But first, notice that after clicking the Check for New Firmware button, we now see that there is a 1.12 version available to download.
Prior to clicking the Upgrade Firmware button, we need to set up our ping to monitor the device. When we click the Upgrade Firmware button, we should see the download progress box.
You will notice that the host becomes nonresponsive and later comes back online . This indicates that the box was rebooted. At this point, weโve proven that we can inject a command into the upgrade URL and the device will execute it. Without uploading an executable to the device, you are limited by what is on the device. For example, as previously explained, if telnetd is compiled into the Busybox (it is not on this system), you can just start it to access the shell without a password, as follows:
Dynamic Analysis with Emulation
It turns out, in some cases, not to be necessary to have hardware in hand to perform vulnerability analysis and exploit firmware.
FIRMADYNE
The FIRMADYNE3 tool allows for the emulation of firmware by using the QEMU hypervisor. The beauty of this approach is that you do not have to buy the hardware to test the firmware. This powerful approach allows for scaled testing in parallel. Dominic Chen downloaded and tested more than 23,000 specimens of firmware and was able to successfully run about 9,400 of them (approximately 40 percent),4 which is not bad at all.
Setting Up FIRMADYNE
First, we need to set up the FIRMADYNE tool by using the instructions found on the FIRMADYNE GitHub
Setup
First, clone this repository recursively and install its dependencies.
Extractor
The extractor depends on the binwalk tool, so we need to install that and its dependencies.
Database
Next, install the PostgreSQL database:
Then, set up user firmadyne with the password โfirmadyneโ (when prompted):
Now, create the database and initialize it. Notice firmware is appended to the end of the next command:
Download the pre-built binaries for FIRMADYNE (or build binaries using instructions on the FIRMADYNE GitHub):
QEMU
Finally, set the FIRMWARE_DIR variable in the firmadyne.config file to the location of the firmadyne files:
Emulating Firmware
Now that you have set up the environment, you may emulate a sample firmware (again, as described on the FIRMADYNE GitHub).
First, using the extractor script, extract the firmware:
Now, you may use the getArch script to get the architecture and store it in the database (enter the firmadyne DB password when prompted, which is โfirmadyneโ):
Now, store the location of the extracted file system into the database:
Next, make a virtual image to launch with QEMU, using the make Image script:
Then, infer the network (this command will run for up to 60 seconds, so be patient):
Now that you know what the IP is, run the emulator:
If at any time you mess up the preceding commands and want to reset the database and environment, simply run the following commands:
At this point, the firmware should be running on the preceding IP as a tap device. You should also be able to connect to this virtual interface from the machine on which you are running QEMU. This is fine if you are working from that machine with a desktop environment (GUI) running. However, in our case, because we are running the QEMU in a virtual machine with no desktop environment running, we will need to get creative if we want to play with the interface from another host.
Tunneling
To do this, we can use the Python sshuttle5 program to tunnel all network traffic through SSH to the virtual host. In this manner, we can access the remote tap device, as if we were local to the virtual machine. Because sshuttle runs in Python, it works on Linux, macOS, and Windows.
Now launch it:
Now, from the system that is running sshuttle, open a web browser and try to connect to that IP.
Exploiting Firmware
From the previous output, you should note that we have injected a command to start the telnet server. The โtelnet โl /bin/shโ argument starts the telnet server on the default port and binds it to the โ/bin/shโ shell. The nmap scan shows that port 23 is now open. After connecting to telnet, you will note that the user is root. Although this has been done on emulated firmware, the same can be accomplished on the actual firmware. At this point, the attacker has root access on the device and can potentially use the device as a launching point for other attacks on the network.
REFERENCES
D-Link Vulnerability: www.kb.cert.org/vuls/id/184100
Firmadyne: www.github.com/firmadyne/firmadyne
Firmware Mod Kit: https://github.com/rampageX/firmware-mod-kit
Last updated