Home Blog Security Highlight Security highlight: Attack Stepping Stones

Security highlight: Attack Stepping Stones

Author: Marc Witteman

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 and would rather be seen as a feature than a weakness. Sometimes the attack path combines vulnerabilities from multiple domains, which can be easily overlooked at design time. A recent publication from KU Leuven shows a nice example, combining features and weaknesses of a target device. Here’s what happened in 5 stepping stones:

  1. The researchers used a microcontroller that is part of their target (an automotive key fob) but also easily available in programmable development boards. Such availability is a great opportunity to experiment and learn.
  2. 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 contain any application secrets, it will include the configuration of debugging functions and security settings. The researchers found code that disables the JTAG debugging port.
  3. 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.
  4. They used voltage glitching to skip the execution of the JTAG disabling instruction. Finding the right glitch timing can be tedious, i.e., 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.
  5. Applying the glitch attack on the microcontroller used in the automotive key fob led to an open JTAG interface. In this way, they could read the entire key fob firmware, which may open the way to logical vulnerabilities. Even without exhaustive reverse engineering, they already found an AES key that may 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.

However, the point here is that while each of those steps is relatively easy and non-surprising, the combination of all of them opens 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 would be through an independent design review by security experts with multi-domain knowledge.

While immunity is hard, it is possible to partially mitigate hardware vulnerabilities in software and make an attack much more difficult. We wrote an in-depth article on mitigation strategies, which you can study here.

The full research from KU Leuven detailing the attack can be found here.

Additional technical research from Riscure demonstrating similar weaknesses in microcontrollers from multiple vendors can be found here.

If you have any questions, contact us at inforequest@riscure.com.

Share This