Whether it’s a vulnerable router, an Internet of Things (IoT) connected device, or some other piece of hardware, JTAG and UART debugging test pins left on the device are going to continue to be one of the most effective physical hardware attack vectors available to a malicious actor. Never assume your secrets on IoT devices, such as encryption keys, are safe.
You may be wondering what JTAG and UART are, and why they’re left on boards.
JTAG
JTAG is a hardware access point that enables one or more devices to connect over externally facing pins for debugging purposes. Below is a diagram of how these devices can be connected together.
JTAG serves 2 main purposes:
- The first is called boundary scan and it’s a simple form of debugging that just makes sure all of your devices are connected correctly. When they’re all wired up like in the diagram above, it’s easy to quickly poll each device to ensure it’s receiving power and connected correctly, without any accidental shorts or problems.
- The second is called debug access. It provides a way to actually talk to intelligent devices and hook into their raw live computation. This allows the debugger access to registers, memory contents, interrupts and the ability to pause and redirect instruction flow.
As you can imagine these are very powerful tools. In the case of an IoT device that has some sort of secret on it, you can use debug access to actually read the contents of memory and pull that secret out of the memory chip. Some CPU’s have JTAG interfaces built into them and some don’t. Many board designers expose these CPU capabilities with easy to access pins for debugging purposes.
UART
UART is actually a microchip that helps bridge the connection between serial and parallel data. Sometimes UART is necessary for the system to function or it’s exposed for debugging reasons. Other times it’s actually put on boards to provide an interface to connect external serial debugging devices to the board. In the wrong hands it can be used to connect a computer directly to the board and begin to communicate with it.
Why are JTAG and UART left on final board designs?
Both of these are very powerful tools, but it still begs the question, why are they left on final boards if they only need to be used for debugging?
The answer to that could be time and money. Recently I took it on myself to design my own hardware PCB. The design can be seen below:
You’ll notice what actually takes up the majority of the space on the board are externally facing pins. In theory these pins do not need to be there. I’ve read the datasheet for the si4710 module many times over, and I’m pretty sure I’ve wired everything up correctly–pretty sure. The problem is this isn’t like writing software. I can’t just run my code and see if it works or not. I need to actually place an order for all the parts and wait two weeks for them to arrive.
When you’re writing software they say every 20-100 lines of code contains an error regardless of the programming language. In my experience it’s the same basic principle when engineering hardware. The module I’m using is engineered by Silicon Labs. Even though their documentation makes perfect sense, I’m almost guaranteed to make an error (partially because I’m new to it, but mostly because I’m only human), which is why I’ve included those pins. When I have to wait 2 weeks for the board to ship, I can’t afford to not have a way to troubleshoot what went wrong when it finally arrives and things don’t work as planned.
Moreover, if the board actually works correctly I don’t want to change the state of the board in any way out of fear I’ll break something. Even if it’s something as simple as removing debug pins.
So I understand it. I get why debug pins are left on a board, I understand why they’re put there in the first place. They’re an easy way to verify everything is working correctly and to troubleshoot what’s not working correctly.
My board has debug pins, this router (our researcher @b1ack0wl got a shell on) has them, and that’s why JTAG and UART will continue to be one of our most effective tools for harvesting secrets from connected devices when pentesting Internet of Things product ecosystems.
