Hardware Hacking Party Tricks

Toward the end of April, Black Hat ran a webinar Hacking Party Tricks: Techniques for Exploring, Manipulating, and Exploiting Embedded Systems. It was presented by Joe Grand (aka Kingpin) who is founder and hardware hacker at Grand Idea Studio.

The chip design world is intimately involved in many aspects of security, primarily in two areas. The first area is providing fast and efficient hardware implementations of cryptographic algorithms. The second is providing the basis for secure software: hardware roots of trust, support for memory and security domain protection, and all the other features required to build a secure hypervisor. But that assumes that the chips themselves are secure.

I have seen two impressive demos showing their vulnerability. The first was a special security day at EDPS back in 2016 (so long ago it was still in Monterey). There two security hackers, Jasper van Woudenberg and Robert van Spyk of Riscure, demonstrated an attack I'd only ever read about: differential power analysis. This involves closely monitoring the power a chip consumes and using that data to infer what the chip is doing internally. Their demo consisted of reading the AES security keys out of a mainstream chip containing an Arm Cortex-M4 processor. Read about that in my post EDPS Cyber Security Workshop: "Anything Beats Attacking the Crypto Directly".

Then, at the Black Hat security conference in Las Vegas (the last time it was held in-person) showed how glitching chips could be very effective. Security professionals like to call this "fault injection" since it sounds more...err...professional. Anyway, Thomas Roth and Josh Dalko, co-founders of Keylabs, pointed out that glitching chips successfully is "easier than you think". Read more about that in my post Black Hat: Glitching Microcontrollers.

The recent webinar was the third time I saw chips being attacked and not coming out looking good. I think in the chip design world, we don't take to heart the quote that I used in the title for my EDPS blog post: "anything beats attacking the crypto directly". We build secure enclaves, and use strong crypto, and aggressively verify the algorithms. The bad guys do anything except attacking that. The big eye-opener from both the Las Vegas demonstration and this recent webcast is just how effective glitching chips is by delivering incorrect voltages and clock frequencies. You might think it would take millions of attempts to get anything good (aka bad) to happen. But it only seems to take less than a dozen.

The Webinar

Joe gave a warning when he started that his webinar was a bit like a cooking show: he's got one he prepared earlier. In this case, what might take just a couple of minutes to show us on video might have taken hours or days to do before he discovered which were the critical pins, unsoldering a memory, and so on. However, everything he showed was done "live" and not pre-recorded.

Joe started simple, showing people how they can take a board that they know nothing about and find useful signals using just an oscilloscope. Power and ground are easy enough to find, and you need to find ground pretty quickly to give yourself a voltage reference level for everything else you do. The clock is not too hard to find. He also reminded us that looking at the screenprinting on the board can be useful too—there is often a lot of information there intended for use by the developers. Many devices use serial flash when booting, so it is also a good idea to look at signals during the initialization and boot processes, not just when the device is running when often not much is happening.

Next, he moved on to UART (low-speed serial interface):

If boards are not designed properly, you can often compromise them through the UART interface.

He manually measured the width of one bit. It was 8.6us for width, or a little bit less than 8.5us for one bit. That is a 115.2Kbps UART datastream. He connected it up to a terminal emulator and showed the console data as the operating system started up, something anyone will be familiar with who has ever booted Linux. On a TP-Link (wireless control for lights and outlets) he showed how he could interrupt the boot process and login...except he didn't know the root password.

But that doesn’t matter since we’ll probably go to JTAG and modify the memory.

But before doing that, he showed how to extract the memory contents from another board, using a device programmer. He is in favor of hacking in situ rather than taking parts off the board. "BGAs in particular are really hard to deal with". So he had constructed a cable with a DIP CLIP that just connects directly to the device. There was not even any need to power up the board since the programmer supplied enough power. He ran a string search program and showed the SiFive logo from the firmware. But potentially there is more interesting stuff like private keys and login credentials.

Next, he got around to JTAG. JTAG (the name comes from the working group that defined it, the Joint Test Action Group) is a four (or five)-pin interface that was originally designed for board testing without requiring bed-of-nails testers, but was then piggy-backed to be used for hardware and, especially, embedded software debug. This time the hardware being attacked was an old HTC mobile phone. Joe used a tool called JTAGULATOR to identify which pins were the JTAG interface and read out the device IDs (you can then look online and find out which chips these are).

He switched to a new board, and Intel Galileo. He didn't switch because there was any issue with the HTC phone, just that he wanted to show demos on lots of different board so his presentation didn't come across as attacking a single especially weak board. The new board was an Intel Quark (x86) Arduino board.

He showed an example of privilege escalation. First, he started by showing that he could log in as "guest" with no password, but he couldn't access the shadow file. He used gdb (a debugger) to put a breakpoint on the procedure that checks whether access is permitted, putting the breakpoint just before it returns. Then he attempted to access the shadow file again. The system stopped on the breakpoint. He changed the return value in the EAX register and set it to zero. Then he continued, and he could access the secret file. Now he was root, and could do anything on the system.

Of course, an Arduino board is not especially high security, and any JTAG attack requires physical access. But even so, I'll bet many more sensitive SoCs do not have full solid security on their JTAG interface.

Joe's final demo was voltage glitching, as I mentioned earlier. There is code protection on this PPC1014 chip, so you can neither read the code out nor change it. He was running out of time so this was all a bit rushed, but I assume this is some sort of secure boot. He used a tool called ChipWhisperLite that lets a Python program do stuff, and particular to cause misbehavior in different types of devices. He set it up to do a chip reset, then after a certain length of time, glitch the reset line. That is, provide a signal on the reset line that is not long enough nor the correct voltage. The chip should either ignore this, or reset, but not do anything else. His Python program varied the length of delay and it only took a moment to defeat the protection, and then he could read out all the code.

He had a device that I was eager to see, but the hour was up and the moderator took over. This was a contactless way of doing fault injection by blasting the chip with electromagnetic interference. This could cause the same sort of misbehavior. This is known as EMFI for ElectroMagnetic Fault Injection. He didn't get to this part of his demo, but here's the picture of it from his presentation:

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.