Security Highlight: Attack Stepping Stones
Experienced hackers know that successful exploits usually require a series of vulnerabilities, the stepping stones. The combination of these vulnerabilities enables the attack path, and all of them are needed. Some of these stepping stones may seem very insignificant, or seem more like a feature than a weakness. Sometimes the attack path combines vulnerabilities from multiple domains, which can be easily overlooked at design time. A recent publicationfrom KU Leuven shows an example, combining features and weaknesses of a target device. Here’s what happened in 5 stepping stones:
- The researchers used a microcontroller that is part of their target (an automotive key fob) but also easily available in programmable development boards.
- The microcontroller allows serial port access through which the bootloader binary code can be extracted. While the bootloader contains relatively simple code that would not normally contain any application secrets, it does include the configuration of debugging functions and security settings. The researchers found code that disables the JTAG debugging port.
- They profiled the software by recording side-channel traces of the boot process for various situations (using their programmable development board), and they learned about the timing of the aforementioned JTAG disable instruction.
- They used voltage glitching to skip the execution of the JTAG disabling instruction. Finding the right glitch timing can be tedious — for example, stepping through a 10 ms window with 10 ns precision for unknown glitch pulse intensity and duration, followed by impact verification. However, the profiling step above greatly reduces the search space, making this a practical step.
- Applying the glitch attack on the microcontroller used in the automotive key fob led to an open JTAG interface. In this way, the researchers could read the entire key fob firmware, which could open the way to logical vulnerabilities. Even without exhaustive reverse engineering, they were able to find an AES key that could be used for firmware update confidentiality.
The target microcontroller was, like many others, not designed to resist hardware attacks using side-channel or fault injection methods, but over time these attacks have become easier and cheaper. Therefore, it is not surprising to see more reports of successful hardware attacks against microcontrollers.
While each of these steps is relatively straightforward, the combination of all of them creates a clearly bad scenario. It is typically hard for developers to see the attack path, as it requires insights into all the different attack avenues and techniques. The best way to uncover these hidden vulnerabilities is through an independent design review by security experts with multi-domain knowledge.
Although achieving total immunity is hard, it is possible to partially mitigate hardware vulnerabilities in software and make an attack much more difficult. Learn more in our in-depth Fault Mitigation Patterns white paper or view additional technical research demonstrating similar weaknesses in microcontrollers from multiple vendors. If you have any questions, contact us at [email protected].