Hardware Implant Attacks (Part 1) — Console Access Attacks on Vulnerable IoT Devices
[Disclaimer: The goal of this article is to bring academic insights to the functionalities of MCU chips and to shed light on how IoT devices can be susceptible to hardware implant attacks by malicious attackers. The insights shared are purely for learning purposes. The author and CSG do not condone, encourage, nor intend for the lessons described below to be used for any purposes other than cybersecurity research.
The entity and its product mentioned in this article, Pogo Plug, are known to be defunct as of the time of publication. The author has undergone all reasonable attempts to contact the company and to disclose to it the findings described in this article.]
In this two-part series, I will be sharing about how malicious actors can perform hardware implant attacks on vulnerable Internet-of-Things (IoT) devices. Hardware implants are malicious modules attached to existing hardware devices that can potentially alter the program behaviour or execute malicious commands on the vulnerable IoT device.
In this Part 1 article, I will cover the techniques to exploit IoT devices through console access attacks due to inadequate protection or inattention to hardware security. Part 2 of the series will then touch on how you can create a backdoor in vulnerable IoT devices using an ATTiny85 Microcontroller Unit (MCU) chip.
Proof-of-Concept (POC) Objective
This series aims to demonstrate how a hardware implant attack can be conducted using an ATTiny85 MCU. The MCU sends Operating System (OS) commands that instruct the vulnerable IoT device to set up a static IP address and run the Telnet daemon service, creating backdoor access for remote attackers.
What makes Hardware Implant Attacks so notorious?
A highlight in my career as a hardware security professional was being given the opportunity by GovTech to participate in Joe’s (@securelyfitz) training on IoT hardware testing at the Black Hat USA 2019, an international information security event.
Through the course and Joe’s sharing at BH arsenal, I learnt about the mechanism behind hardware implant attacks and why these attacks contribute to some of the most high-profile cyberattacks today. Hardware implant attacks are difficult to execute and detect due to the complexity of the integrated circuits and microelectronics.
In addition, physical modifications to a single integrated circuit can be well-hidden among the sheer number of valid components. Hardware implant attacks are hence able to remain undiscovered for prolonged periods. Referencing another POC elucidated below, we can imagine just how difficult it is to spot an anomaly with the naked eye!
While it is difficult to carry out hardware implant attacks, it is not impossible. Hence, I will be sharing the basic mechanism behind these attacks so that developers can take the necessary steps to protect the IoT devices they have developed from such threats.
Hardware Tools Required
In this demonstration, we will need the following:
- A hardware device with Universal Asynchronous Receiver/Transmitter (UART) pinouts. You can attempt to open your older routers or purchase a deprecated pogo plug (used in this series)
- Jumper wires
- Soldering iron station
- USB to Transistor-Transistor Logic (TTL) Serial adapter
- Multimeter
- ATTiny85 chip
- Breadboard
- Arduino Uno
Background to Console Access Attacks
Developers and Quality Assurance (QA) technicians often require a way to diagnose anomalies in the hardware or software. For ease of access, they often introduce consoles on to devices and diagnose via TTL serial communication. If the serial is not disabled, a malicious actor could potentially gain root shell access to the device or obtain sensitive debugging information which could be used for further attacks.
Before diving into how IoT devices can be exploited for console access attacks, I would like to highlight some key fundamentals. These include how serial communication works, and how to identify and communicate via UART.
What is serial communication?
Serial communication is the process of sending data one bit at a time, sequentially, over a communication channel. It involves a transmitter and receiver as seen in this image:
If the serial communication uses a clock, the transmitter and receiver rely on the clock’s rising/falling edge to synchronise data. When it does not use a clock, it is termed as asynchronous serial communication. For asynchronous serial communication to work, both the transmitter and receiver must use the same baud rate (speed of transferring data) when communicating or the data ends up gibberish.
In most MCUs today, you will often notice that UART, which consists of a Transmitter (TX) and Receiver (RX) pin/leg, is available. Developers and QA often make use of this asynchronous serial communication to diagnose anomalies in their programs.
How to identify UART on a hardware board?
A UART usually consists of three or four pins/pads as seen in the following images:
If you do not see the pin and pad indicators marked out by the red boxes in Image 3 above, the product may be using another protocol (e.g. JTAG, SPI, I2C) for communication or there are just no pinouts available for that product. In such situations, you may need to refer to the MCU’s datasheet and use a logic analyser to analyse the signals. It gets complicated as you will require dexterity to solder onto the MCU’s tiny legs without touching other components.
After identifying potential UART points on the hardware board, the next step is to validate the functionalities of each pin or pad. This process is important as it allows us to communicate with the device later.
In a typical UART communication, you will often come across the following pins/pads:
- TX (Transmit) — The pin where serial data is transmitted out from the MCU
- RX (Receive) — The pin which accepts serial inputs to the MCU
- GND (Ground) — The reference point in an electrical circuit from which voltages are measured, a common return path for electrical circuits
- VCC (Voltage Common Collector) — The power input of a device (typically 3.3V or 5V)
The first test to perform is to identify the ground pin. Power off the device and set the multimeter to the continuity beeper as indicated by the red arrow in Image 4. Place the black probe on any metal or ground interface, and the red probe on any of the four pins. The grounded pin or pad will trigger a beep on the multimeter.
For the subsequent tests, set the multimeter to digital voltage 20 as shown in Image 5. Turn on the device, place the black probe on the ground pin identified earlier, and the red probe on either of the remaining three pins. The VCC, TX and RX pins will usually display the following characteristics:
- VCC — Constant 3.3V reading
- TX — Fluctuates around 3.3V
- RX — The lowest voltage compared to the rest
Do note that the readings for this test will be most accurate during the boot-up process.
At this point, if you are not observing similar characteristics as mentioned above, it is likely not a UART pinout.
Once you have identified the TX, RX, VCC and GND on your hardware, you can start soldering your jumper wires or your pin headers on the hardware board. If you are lucky, the pin headers could still be intact and attached on the UART, saving you the time and effort required to solder.
How to communicate with the device using the UART pinout?
With the USB to serial adapter and our soldered on UART pins/wires, all we have to do is connect the TX and RX as shown in Image 6. The TX on one of the UART devices must be linked to the RX on the other device and vice versa. Finally, connect the grounds from the two devices together.
The final step before communicating with the IoT device is to identify the baud rate used for communication. As mentioned, failure to identify the baud rate may result in gibberish data. A few methods to identify device baud rate are:
1. Check the datasheet or search for online resources about the baud rate
2. Use a logic analyser to derive the baud rate
3. Manually attempt all the common and standard baud rate (e.g. 9600, 14400, 19200, 38400, 57600, 115200)
4. Use an open source python script titled baudrate.py to automatically determine the baud rate
I would suggest employing the quick and easy approach 4 — especially if you are new to hardware. Simply run the script and power up the device (which is connected to the TTL serial adapter). You should be able to see the output as shown in Image 8.
# python baudrate.py
Once the device baud rate has been identified (115200 in this case), we use PuTTY to start the communication and observe messages coming from the IoT device. To identify your serial line port number, open the device manager in windows and change the settings accordingly.
You should begin to see the IoT device’s boot up information. Once the boot up messages have appeared, press ‘enter’ to obtain root shell access! Different IoT devices require you to trigger specific keys during the boot up sequence to obtain a root shell. This information may also be found in the IoT device boot up message.
With root access to the device, an attacker could extract confidential information such as encryption keys, extract binaries for further analysis, identify service backdoors or even create backdoors on the device.
Conclusion
In this article, we have seen how hardware security can easily be overlooked. Enabling console access to users on commercial devices could potentially allow a malicious actor to identify flaws in the system. Furthermore, there could be implications for the entire IoT ecosystem. Thus, IoT developers should always ensure that the production units do not have console access or debug messages that are made available on the hardware device.
Click here for the second part of the series, which will touch on programming the ATTiny85 chip and using it to inject commands via the serial communication channels discussed earlier. This allows hardware implant attacks to be performed without the need to solder parts, making it easier and faster for such attacks to occur.
