Glitched On Earth By Humans

The Black Hat conference always brings up interesting and current research within the device security industry.

Lennert Wouters of COSIC studied the security of the Starlink User Terminal. After some PCB-level reverse engineering, he found a serial port and observed various boot loaders, U-boot, and Linux running on the device. However, there was no obvious way to gain further access. The boot images were signed, U-boot did not take serial input, and the development login was disabled.

These are all the standard practices to be expected from an embedded system that has to resist logical attacks. As the title of the talk already hints at, the question is whether it also resists fault injection attacks.

Lennert opts for voltage fault injection (VFI) first, using ChipWhisperer Lite. This device uses the crowbar glitching technique, which momentarily shorts VCC and ground. The downside is that it is only able to target a specific time, not a specific location on the die. However, EMFI, laser fault, or BBI require positioning over the chip, which presents some physical challenges for the XYZ stage, because the PCB is very large.

With VFI, he managed to fault a shell script that determines whether a device is in developer mode or not, giving shell access. The problem is that it had a low success rate, and needed to fully boot (12 seconds) for each fault attempt. To solve this, Lennert aimed the VFI at the Trusted Firmware A (TF-A) bootloader. He found that with two glitches in BL1, he can bypass firmware signature verification, and he could load arbitrary BL2 code.

So far, the story follows a very similar process to what we do at Riscure. Next, Lennert took it one step further by creating Modchip – a fitted custom PCB to inject the fault and load the attacker firmware. The Modchip can be easily soldered to Starlink, and automates the entire FI process, giving the attacker ‘automatic root’ on their Starlink Terminal.

Another interesting note is the use of FI simulation to simulate single and double instruction skips, based on the Unicorn Engine. This is the same approach we utilize in Riscure FiSim. Lennert noted that although he could find double instruction skips that caused the same effect as on the hardware, the actual fault there was likely different. This aligns with (ongoing) Riscure internal research, where instruction-skip simulators are compared to netlist-based simulators.

One corollary from the research is that the TF-A BL1 is vulnerable to fault injection. This means not only that Starlink is vulnerable, but potentially all devices using TF-A without additional FI countermeasures. This aligns with the TF-A documentation, which talks about FI countermeasures in software and states “At the moment TF-A doesn’t implement such mitigations.” Interestingly, for TF-M there is some ongoing work in hardening against FI. You can learn more about this work here.

For more information on how to implement (software) countermeasures yourself, more information can be found in our whitepaper Secure Application Programming in the presence of Side Channel attacks, or contact Riscure at [email protected] for countermeasure validation.