Yes, you read that right. Whereas software attacks typically rely on the presence of rare vulnerabilities (often less than one per thousand lines of code), Fault Injection opportunities arise typically all over the place. This stems from the fact that the underlying and inherent weakness is in hardware. Because of that weakness, any instruction code or operand may be manipulated and changed into a different code. In theory, the complete binary code can be on the fly rewritten into something completely different.
In practice, complex modifications are not that easy. The Fault Injection process builds on a huge parameter space, including time offset, spatial location, and intensity. Without accurate and exhaustive effect observations, it is often a tedious job to find the right parameters and inject an exploitable fault. This is why attackers prefer to use Fault Injection to make just one single change to the execution and bypass authentication to gain unauthorized control.
But, what if the software is hardened against Fault Injection? The most basic countermeasure dictates a double check to ensure that elevated privileges are only given after a second verification. An additional fault would be required to defeat such countermeasure, while the unknown fault timing offset largely increases attack complexity by adding another parameter to space.
Researchers from Ledger did a deep analysis of a product from their competitor Coldcard and discovered the product was FI-hardened. Through testing, smart analysis, and perseverance, they managed to break the product, injecting multiple faults undoing the hardening effect.
So, how did they overcome the complexity of the huge parameter space? In other words: How did they find the needle in the haystack? Apart from having the right equipment, in this case, a sophisticated high precision IR laser, two key factors were instrumental in their success.
First, they had the experience of an attack on an earlier version of the product. This is what I call the hacker legacy. In this earlier attack, they broke a now-discontinued product with a single fault. During that episode, they selected and tuned the attack tools finding the right parameters for introducing one successful fault. While the code in the new product had changed, they could reuse the prior tooling and settings and hit the ground running.
Secondly, they used side-channel analysis to observe the effect of their actions. By recording power traces, they could see (with clock cycle precision) where the software started to deviate from its intended behavior. Even though it is impossible, or at least very hard, to recover the exact instructions executed, it is possible to see where code execution starts to change. This way, they could exclude unsuccessful paths, which never resembled the desired one. With lots of patience, they built a model of the software implementation, systematically validating assumptions on the consecutive behavior until they discovered the redundant double-check (that could then be disabled).
This attack is not for everyone: high-end equipment is used, and strong analysis capabilities along with probably several weeks of time were needed for the identification of this attack. If scripted, the attack may be repeated inside a lab in a few hours, but it is not very scalable since it still requires physical access to the target. The immediate threat for wallet owners is therefore limited.
While this example of a multi-fault attack is still rare, it marks the start of a new phase where most high-security products apply some FI countermeasures, forcing attackers to step up their game. The combination of historic information (hacker legacy) with side-channel visibility of the executed software has shown to be sufficient to continue the battle. For product developers, it is important to now catch-up, and start applying a stronger mix of countermeasures.
Contributed by Marc Witteman, CEO, Riscure. If you have any questions, contact us at inforequest@riscure.com.