Embedded Hardware Hacking 101 – The Belkin WeMo LinkWhy Embedded Hacking?
Devices that are connected to the Internet or run a full operating
system are becoming more and more prevalent in today’s society. From
devices for locomotives to wireless light switches, the Internet of
Things (IoT) trend is on the rise and here to stay. This has the
potential to make our lives much easier; however, the increasing
sentience of once analog devices also enables adversaries to target
them and potentially misuse them.
With the ubiquity of these Internet-connected devices, there is a
surplus of “Things” to exploit. The main intent of this blog post is
to generalize how an individual would reverse engineer an embedded
device and the process for attempting to find vulnerabilities.
For this demonstration, we will be looking at the WeMo Link, which
is a part of the Belkin WeMo LED Lighting Starter Set
(http://www.belkin.com/us/p/P-F5Z0489/). There have been
vulnerabilities identified in previous iterations of this device;
however, these vulnerabilities were more focused on the web services
component and not based on analyzing the built-in security of the
physical components.
Steps to Analyzing Hardware
There are several steps that an analyst should take when examining
their device. These steps, at a high-level, are:
- Research the device
- Identify the components
- Identify debugging ports
- Dump the flash
- Extract/analyze firmware
These steps are crucial to understanding the device being analyzed
and are required to help identify vulnerabilities. In the following
scenario, I will walk through the aforementioned steps and explain
each, the path I took, and what other potential sub-paths one could
take, given their specific scenario.
Research the Device
The scope of this project involved examining IoT embedded hardware
devices that primarily ran embedded Linux as its operating system. I
looked at several IoT devices and decided on the WeMo Link due to its
ability to be controlled by a mobile application and to be used for
home automation, its utilization of wireless components, and its
ability to be controlled over the Internet.
The WeMo product allows a mobile application to dim or turn the
bulbs on and off remotely, or add a bit of intelligence to the bulbs
by having them sync with the sunrise or sunset automatically. There
are two main components that drive the device: the WeMo Link and the
WeMo bulb. The WeMo Link is comprised of a WiFi 2.4GHz radio component
as well as a ZigBee component that communicates on the same band. In
terms of the software, the user downloads a mobile application for
their Android or iOS device to initially setup the WeMo Link, which
then allows them to control the WeMo bulb.
When initially setup, the WeMo Link broadcasts its SSID of
“WeMo.Bridge.XXX”. The user then connects to this AP (Access Point)
with their mobile device, shares the user’s wireless AP credentials,
and the WeMo takes care of the rest. The WeMo then takes any command
sent from the mobile application, sends it to the user’s router, to
the WeMo Link, and then transmits the command over ZigBee to execute
the command to the appropriate bulb(s). Pretty simple.
Identify the Components
In this example, the brains of the operation appear to be the WeMo
Link component. In order to be certain, we need to take the device
apart. The lid easily pops off by applying force with a flathead under
the lip of the plastic. There are several ways of identifying how to
properly disassemble a device – from identifying pull tabs to
uncovering screws that are covered with warranty warning tape. In this
case, the device had a slightly protruding lid held down by four tabs.
Behind the plastic lid were two main components: the mainboard, and
the AC/DC converter consisting of a transformer, rectifier, etc.
As we examine the mainboard, we will need to identify the datasheets
associated with each component in order to get a better idea as to how
the device works. On the mainboard itself, what is immediately visible
(we will remove the shielding in a bit) is a Winbound W9825G6KH-61
(https://www.winbond.com/resource-files/da00-w9825g6khc1.pdf) 32MB
SDRAM and a Winbound 25Q128FVSG
(https://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf)
16MB serial NOR flash memory with the ability to communicate over SPI
(Serial Peripheral Interface) (this will be important later), as seen
in Figure 1. The latter chip is used for storing the more permanent
memory on the board, even while the device is powered off.
Figure 1: Winbound 25Q128FVSG flash memory
After removing the two metal pieces of shielding on the
opposite-side of the board (easily pried-off with a flathead screw
driver), we uncover three more main components.
As seen in Figure 2, the first chip is a SoC (System-on-a-Chip)
Ralink RT5350F
(https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf), which
is a MIPS embedded processor commonly used for networking devices and
supports SPI communication, 360 MHz MIPS24KEc CPU core, 802.11n
wireless communication, and more. This component is used to drive the
device’s main functions, communicate over its debugging interface,
interact with its ZigBee component, and communicate with our router
over its built-in Wi-Fi component.
Figure 2: Ralink RT5350F chip
As shown in Figure 3, the other shielded section contains the SoC
for the ZigBee device labeled as Silicon Labs EM357
(https://www.silabs.com/Support%20Documents/TechnicalDocs/EM35x.pdf),
which handles all of the ZigBee 2.4GHz communication and processing
power (32-bit ARM Cortex M3 processor) used to relay information to
and from the WeMo light bulbs. The other chip residing in the same
section is a SkyWorks SKY65336
(http://www.skyworksinc.com/uploads/documents/200939H.pdf)
transmit/receive front-end module used for the ZigBee transmission,
which appears to be utilized by the aforementioned Silicon Labs EM357
ZigBee SoC to perform the actual transmission of the data to the light bulbs.
Figure 3: Silicon Labs EM357 chip
Identify Debugging Ports
When debugging/interacting with a device, the two most common ways
consist of JTAG (Joint Test Action Group) and UART (Universal
Asynchronous Receiver/Transmitter). JTAG is a dedicated debugging port
implemented as a serial interface used for communicating with the
target device. UART is a means of serial communication that can easily
be bridged over USB via any UART-to-USB bridge. When looking for UART
communication, a lot of times you will see three to four pins that are
grouped together with tracings routed to other parts of the board. To
help us identify these pins, we can use a multimeter. By touching each
of the suspect pins with the positive end on the pad and negative end
to a ground (such as the shielding), we can monitor the voltage and
identify what the pins are. However, in this case, the WeMo’s circuit
board silk screening was friendly enough to label exactly what pads
were utilized for interfacing with the device. They were labeled
conveniently as UART_RX, UART_TX, GND, and VCC, as seen in Figure 4.
Figure 4: Accessible UART pads found on board
To be sure that the labels are accurate, we can still utilize the
multimeter to test each pad’s connection. By powering up the device
and monitoring each pin, the UART_RX oscillated throughout a series of
voltages. This indicates that data is being streamed across this pad,
which is what we will later utilize to view the device’s console.
UART_TX is utilized for transmitting commands to the device and can be
a bit tricky to identify. This pad also displayed as 3.3V, but given
its placement, I did not anticipate this to be VCC. VCC sometimes will
also have a thicker trace than the other pads, indicating it is used
for supply power. The GND pad provided 0 volts on the multimeter,
implying it was the ground pin, and the VCC supplied a steady 3.3
volts, implying it was the power pad. We will utilize these
connections later on after we analyze the extracted firmware from the
flash dump.
Dump the Flash
As mentioned earlier in the WeMo teardown section of this post, we
identified the flash memory that is used to store the bootloader and
firmware for this device. This is the core component of the device
that an attacker would attempt to modify. We have two ways to dump the
memory off of this component, and I will highlight one method. These
methods consist of: connecting a test clip to the chip itself while it
is still soldered to the board and utilizing a tool such as the bus
pirate to dump the flash memory, or desoldering the chip and then
placing the chip in a programmer to read the memory off of the chip.
For the sake of being as hardware-oriented as possible, I went with
the method of dumping of the SPI flash memory via the bus pirate
without desoldering the chip. I wanted to take a non-invasive approach
such that my analysis might not be discovered (no physical
modifications) by the naked eye. For this method, I purchased a bus
pirate from Dangerous Prototypes and an SOIC8/SOP8 test clip (these
stand for different types of chip packages, meaning small outlined
integrated circuit and small outlined package). This particular flash
chip fit perfectly with my 8-pin test clip and was used to make a
connection while not removing the chip from the board. I then
correctly wired the chip with respect to the bus pirate ports, while
following the datasheet and pinout of the chip, as seen in Figure 5.
Figure 5: Chip pin layout
To dump the flash memory from the chip, it must be powered by
something. In this case, we utilize the bus pirate’s 3.3v line to
provide power to the chip, as seen in Figure 6 and Figure 7.
Figure 6: Attaching the test clip to the chip
Figure 7: Full setup for dumping the memory with
the Bus Pirate
The problem with this is that, at times, voltage injection may occur
and wake up other chips on the board. This means that other chips will
communicate with our flash chip, interrupting our flash dumping
process. This is why it is generally recommended to desolder the chip
with a rework station and read the contents of the chip with a
programmer. Thankfully, we were lucky and this was not the case. To
dump the entire 16777232 bytes (exactly 16MB) worth of content from
the flash chip, I utilized a tool called flashrom, which works well
with the bus pirate device to extract the flash memory in full, as
seen in Figure 8.
Figure 8: Dumping the content from the flash chip
Extract/Analyze the Firmware
Now that we have a flash dump from the device, we can use the tool
binwalk to analyze the headers within the flash dump to get a better
understanding of what the dump consists of, as seen in Figure 9.
Figure 9: Binwalk analysis of the flash dump
At first glance, we see that the device utilizes U-Boot as its
bootloader (common for embedded Linux devices), and that there are
several file system types such as SquashFS, JFFS2, and the like.
Luckily, binwalk has a very neat feature that can automatically
extract as much as it can identify from signatures in the flash dump
and provide us with the full filesystem of the device. By running
binwalk with the filesystem extraction flag (binwalk -e), we are
presented with several filesystems, one of which is displayed in
Figure 10.
Figure 10: The extracted filesystem
Within this directory, we can now take off our hardware reverse
engineering hat and put on our software reverse engineering hat and
begin looking for interesting items such as encryption keys used to
sign WeMo device firmware, hashed root passwords, interesting services
that may start on boot, etc.
Further Testing
What I found interesting after dumping the flash memory was that all
of the memory was directly readable from the chip, and that the
bootloader was bundled onto the same flash chip. This implies that,
since there are no read controls on the flash chip as well as the
bootloader existing on the same (potentially unprotected) chip, I
might be able to write my own data to the device. I performed a few
tests where I manipulated the flash dump binary itself, such as
changing the serial of the device (which in turn changed the wireless
broadcasting AP SSID). This initial test was to see if I could
successfully modify part of the flash memory to display these changes
in a real-world environment, this case being renaming the broadcast AP
SSID, “WeMo.Bridge.HAK” as opposed to the original “WeMo.Bridge.CBD”,
as seen in Figure 11.
Figure 11: Modified AP broadcast by the WeMo device
I was encouraged in my efforts because I could write a new binary
file to the device, completely overwriting the original content. To
examine this further, I needed to make modifications to the flash dump
and judge the results by viewing the startup console for the device.
This involved connecting to the device’s UART debugging pads, as
described earlier, and viewing the output of the console. To interact
with the UART_TX pad, I used an alligator clip wrapped with electrical
tape to hold down a wire that touched the pad and connected to my UART
to USB device, attached to the UART_RX pin. It is important to note
that since the device was plugged into an outlet and was already
receiving power, that I only needed to connect to the transmission
pad(s) as well as ground – but not power. This would have fried the
device. As illustrated in Figure 12, I decided to connect the ground
wire to the shielding, which already acts as a ground. This was much
easier than attempting to connect the ground wire to the corresponding
ground pad.
Figure 12: Wiring the board to communicate via UART
On the software side, I used the program baudrate.py to easily
determine the baud rate (transmission rate) of the device via UART.
After powering on the device and cycling through several garbled lines
of text, I was met with a baud rate of 57600, which presented readable
text, displaying the entire boot process of this device, as shown in
Figure 13.
Figure 13: WeMo device booting process displayed
via UART
I now had the ability to compare the strings found in the flash dump
to what was displayed during the boot process of the device. To
confirm my theory of potentially modifying the bootloader, I matched
strings found in the binary to what was displayed in the console and
attempted to modify those strings and rewrite this section of the
bootloader, U-Boot. While using a hex editor to modify the binary file
and flashrom to erase/write my file to the flash chip, I successfully
modified the strings found in the bootloader process. I changed the
bootloader header from “U-Boot 20140225_MFG (Feb 13 2015 - 16:58:37)”
to “Mandiant Bootloader (May 18, 2016 – 15:38:25)”, as seen in Figure 14.
Figure 14: Modified bootloader to display
“Mandiant Bootloader” instead of “U-Boot 20140225_MFG”
I was also able to modify various field names regarding the image
verification process, most likely around the time where the bootloader
checks the validity of the firmware, as seen in Figure 15.
Figure 15: A modified field name to display “MandiantHak”
The checks present in the image verification process are irrelevant
if portions of the bootloader can be modified. In theory, if the above
assertions are correct, an adversary could non-invasively rewrite a
new, malicious bootloader and firmware to the device, with the ability
to perform malicious acts on the user’s network as a trusted device.
Such a scenario could consist of a reseller of this product placing a
custom bootloader and firmware onto this device, and then selling the
product to an unsuspecting customer, having a control point in the
user’s network. This could theoretically enable an attacker to
intercept traffic on the network, acquire data on the network, modify
data, and more.
Remediation
The following recommendations do not take into consideration all of
the variables that are involved when making significant changes to a
device in order to implement security improvements. These
recommendations are things to consider when attempting to remediate
the aforementioned scenario.
There are a few hardware-based actions that could be taken that
would make it significantly more difficult for an adversary to
read/write to the flash chip, among other areas. One such action is to
implement hardware authentication chips. This involves storing a
cryptographic mechanism on the board along with the required key for
decryption, hindering an adversary’s ability to clone or tamper the
data on the device. This is a cost-effective method for IoT device manufacturers.
A second action is to protect the bootloader by storing it in
protected storage or a SoC, or to require the SoC to communicate with
an authentication chip during the boot process. The problem with
implementing the bootloader on a flash chip that is unprotected and
can be manipulated by disabling the CRC checks in place when
decompressing the firmware image on boot and overwriting the image
with a malicious one. If the bootloader must be stored on the flash
chip, it could be included in OTP (One-Time Programmable) memory,
disallowing this area to be written by a third party.
Conclusion
It is important to keep in mind the amount of attention paid to
security is generally proportional to the value of the device.
Implementing strict security features for a relatively inexpensive
home automation system may not make sense for all but the most
security-conscious consumer. That said, it is important to understand
how easily an adversary can implement a malicious bootloader/firmware
with a backdoor, allowing for command-and-control on devices we may
rely on in our homes. A device as simple as a wireless light bulb can
still be used as an entry point to our home systems.
By taking the previously outlined steps to analyze an embedded
device, we successfully identified relevant chips, a UART debugging
port, and how to read and write raw data to the accessible flash chip,
affecting the boot process of the device. Following the previously
defined steps will help you further investigate most embedded devices
in order to identify vulnerabilities.
Upon notifying Belkin of our intention to release this research,
they provided the following statement:
“Wemo appreciates the work of FireEye and other white hat
researchers who often play a critical role in identifying potential
security issues and keeping connected devices safe for consumers. As
malicious hackers grow more sophisticated, it is critical that we, and
other smart home manufacturers, work with these groups to mitigate any
serious threats to safety and security.
“Though Wemo is aware of the potential vulnerability published by
FireEye in their recent blogpost, we do not believe it is serious
enough to warrant what would be a major change to our hardware
production. In order to facilitate this attack scenario, a hacker
would have to have physical access to a Wemo Link device, tamper with
its circuitry and then either return the hacked device or resell it,
both of which are extremely unlikely. With this particular
vulnerability, there is no remote or even local network threat to
users, so we believe that the best way to prevent this is to always
purchase new, unopened merchandise from an official Wemo dealer.”
Source:
Embedded Hardware Hacking 101 – The Belkin WeMo Link
