Hardware Hacking for IoT Devices – Offensive IoT Exploitation
Welcome to the 4th post in the Offensive IoT Exploitation series. In the previous posts, we have discussed Firmware based exploitation for IoT devices. In this post, we are going to cover about various aspect of IoT device security, focusing solely on the hardware side of things.
Whenever we look at any embedded device, there are various ways in which we can attack it. One of the most useful ways to attack it is using hardware based exploitation techniques. These techniques are quite effective as most of the devices we encounter on a daily basis don’t usually have security protections build around the hardware aspect.
Getting started with Hardware Reconnaissance
To learn more about the Hardware and Embedded device exploitation techniques, we first need to understand what do we expect to see once we open up a device. For the simplicity of this blog post, we will open up a router, which is a nice example of an embedded device. The device of our choice, in this case, is the TP Link MR-3020. So go ahead, and open up the Mr-3020 router and you will see a hardware board similar to the one shown below.
Once we have the device open, we can see there are various chips on the hardware board. Look closely and try to identify the various chips that are present and compare with the list below:
- H1601CG: Ethernet transformer
- A3S56D40GTP: Synchronous DRAM
The first step as soon as we identify various components on it, is to look online and try to identify the datasheets for those elements.
For example, if we search online for the chip [name], we come across the following URL from the google search – http://www.kean.com.au/oshw/WR703N/teardown/H1601CG%20Ethernet%20Transformer.pdf
Similarly, if we search for A3S56D40GTP, we find out that it’s a DRAM with the datasheet available from a 3rd party website at the URL – http://www.datasheetspdf.com/PDF/A3S56D40GTP/938648/
As we open up the datasheet, we identify that there is a ton of information about our target available in the datasheet, which is useful for our information. For example, in a device where we can identify the SPI flash, we immediately identify that it is an SPI flash chip with the given amount of storage, along with the detailed pinouts which might come useful for us later.
In cases of some of the popular hardware devices, you might be able to find information online. For example, in the case of our router – TPLINK MR3020, we can find information from the OpenWRT wiki ( https://wiki.openwrt.org/toh/tp-link/tl-mr3020 ) which gives the different important components available on the hardware board.
A good exercise would be to look for datasheets for each of the components and have it in memory as in which component performs what. There is also additional analysis which you can perform such as pin tracing and getting a hunch about the chip purpose based on proximity with the other components and the pin traces on the device. Those things are out of scope for this post, but is something which is covered in our hands-on training course – Offensive IoT Exploitation.
In embedded devices, there are always a number of circuits which exchange information with each other. To exchange information, the circuits in the discussion should agree on a common protocol. These protocols can be broadly divided into two groups – Serial and Parallel.
The difference between Parallel and Serial Interfaces is quite straightforward. Parallel interfaces allow multiple bits of data exchange are happening at the same time, thus requiring a large number of pins to facilitate that. Whereas in a Serial interface, the data gets transferred one bit at a time, which even though slower than parallel, but has an advantage of requiring a lesser number of pins. In almost all the cases we will see in this blog post and even most of the real world scenarios, you will encounter serial interfaces because of the demand of the shrinking size of embedded devices.
Some of the popular examples of protocols using serial communication are Universal Serial Bus(USB), Ethernet, UART, SPI, and I2C.
Identifying Serial interfaces
Serial interfaces in any IoT device is quite useful for a penetration tester as it provides an entry point for the attacker to interact with the device, even if the device looks completely locked down from outside. There could be different sorts of interfaces available – varying from device to device, but the most useful ones for us are:
Universal Asynchronous Receiver/Transmitter or UART as it is popularly known is a serial interfacing protocol allowing data to be transferred without the necessity of an external clock; that’s why called Asynchronous.
UART also acts as an intermediary between a parallel and a serial interface. It is particularly useful for a pentester to sniff debug and boot up messages, logs, obtain shell access and so on.
Often during exploitation of real world IoT devices, we will see that connecting to the device over UART directly grants us unauthenticated root access, which is like a goldmine for a pentester.
Serial Peripheral Interface or SPI, unlike UART, is a synchronous serial communication interface, meaning it will require a clock to facilitate communication. Later on, we will see the different pinouts in SPI and how we can use them to do something as useful as dumping the firmware from the device.
SPI works on a master-slave architecture which means there will be one device sending data, and the other device is receiving the data. Thus, the pinouts are named as MISO (Master Out Slave In) and MOSI (Master Out Slave In).
To work with SPI, a USB-TTL won’t be sufficient; rather we will have to go for devices with the FTDI chip on it such as the Attify Badge, FT-232H Breakout (by Adafruit) or C232H.
Inter-Integrated Circuit or I2C (this could be pronounced either as I-two-C or I-squared-C, both of which are correct, I prefer I-two-C). I2C allows multiple slave chips to communicate with one master. The usage of I2C from a pentester perspective is pretty similar to SPI.
Now that we know the basics about various serial interfaces available, we will now go ahead and try to use them to gain more information about our target device and to exploit it further.
Using UART to interact with a device
Identifying UART interfaces in a hardware device is quite straightforward. We simply need to look for pins (or pads) in a combination of 3 or 4. While looking for the pinouts we need to look following four pins:
- Transmit: This is used by the device to transmit data from the device to another element. When put in simplest terms, this means that the data goes out from the device.
- Receive: This pin is used to receive data from the other component to the device. Putting in simple words, with the Receive pin, data comes in to the device.
These different pins in UART are also denoted by Tx, Rx, GND and Vcc.
If you have opened up the MR-3020, you will notice the UART ports are exposed, also shown in the image below as four holes with three of them populated with the header pins within the red highlighted area.
Now that we have identified the pinouts, we simply need to identify which pin corresponds to which pin on the external component, and then connect to them using a USB-TTL serial or FTDI cable. At Attify, we have our own exploitation device called Attify Badge which could be used to perform UART, SPI, I2C and JTAG exploitation on target devices. You can find more info about the Attify badge on the http://attify.com/hardware-hacking-kit/.
To identify the individual pins in the pinouts, we could either use a multimeter or a logic analyzer. Alternatively, we could also use devices like JTAGulator (which we will cover in the next post during JTAG exploitation). For this post and the sake of simplicity, we will use our friendly tool Multimeter to identify the individual pins. A multimeter is a device which helps us analyse both the voltage and current on a target device. You could use a low end $10 digital multimeter for this exercise.
Identifying pinouts using Multimeter
We will start off by identifying Ground. You don’t need to power on your device for this one. First, put your multimeter on the continuity mode. Continuity mode is shown as the volume icon on the multimeter.
To identify GND, simply put the red probe on one of the pins, and the black pin on any of the metallic surfaces which you see on the board. Try this with each of the pins till you hear a “beep” sound. The pin in which you hear the sound will be the GND for that device.
Now that GND has been identified, power on your device. Keep the black probe end on the metallic surface and the red one on each of the pins, till you see the voltage fluctuating significantly and finally coming to almost a standstill on a higher value. This will be our Transmit (Tx).
The remaining two pins are Rx and Vcc. To identify Vcc, simply keep the black probe on the metallic surface and move the red probe to the remaining pins. The pin which holds a constant high value is what will be our Vcc.
Now since only a single pin will be remaining, it is safe to assume that it will be Receive (Rx). In case you want to go for detecting Rx, it will usually be a very less voltage value since there is not a lot of information coming into the device from our system.
Once we have identified all the four pins, it is time for us to communicate with it using the FT232 device (or USB-TTL).
Identifying baud rate
To access the router over serial, connect the USB-TTL to your laptop, and connect the Tx to Rx, Rx to Tx and Gnd to Gnd.
Once we have connected the device’s UART ports to our USB-TTL cable, we can now move to the next step, which is identifying the correct baud rate.
But before identifying baud rate, we first need to find out our device identifier and the location that is assigned to it. This can be done using lsusb and checking if we have a Future Devices device connected to it.
Getting shell access on the target device
If it is connected, we can move to the next step of identifying the serial port interface name. This could be done by looking for available interfaces listed at /dev/tty*. In case of Mac, it will be a device with the name /dev/tty.usbserial-* whereas in case of Linux, it will be /dev/ttyUSB*. Just ensure that you have the correct serial port interface already identified before moving to the next step.
Baudrate is simply the rate at which information gets transferred as symbols per second. Baudrate.py is a script written by Craig Heffner which can help us identify the baud rate for a given device which we can then use to communicate. The standard values of baud rate are 1200, 2400, 4800, 19200, 38400, 57600, and 115200. The script can be downloaded from https://github.com/devttys0/baudrate/blob/master/baudrate.py.
After downloading, simply give it executable permissions and launch it up as shown below. Here we can use the top and down arrow keys to move between different baud rates. The value of which we see, readable data is the correct baud rate for the target device.
Once the correct baud rate is identified (in this case 115200), the next step is open up a serial terminal program such as minicom or screen with which we will be able to access the device over the serial interface – in this case, UART. Once accessed, below is what you will see.
As we can see from the screenshot above, here we are granted with the root shell access with the target device running OpenWRT. From here, we can now explore the filesystem, modify the files and even identify sensitive information.
That is all for this post. For a hands-on version of this training class, check out offensiveiotexploitation.com. In the next post, we will look at other hardware hacking techniques which could be used for IoT Exploitation.