Ledger Security Bulletin 002

20 March 2018: Supply chain attack.

Summary

The signature verification of the MCU can be bypassed, allowing an attacker to perform supply chain attacks. It requires a physical access to the device before the generation of the seed.

Technical details

A blogpost is already written and explains the technical details of this vulnerability. The security resarcher wrote a blogpost as well.

Architecture

In order to understand correctly the vulnerability reported, one has first to understand the Nano S architecture. The Nano S architecture delegates the display and input validation to a non secure chip (STM32).

At each bootup both chips are paired – the Secure Element (SE) is requesting the STM32 firmware, hashing it and checking a signature to guarantee the device integrity.

architecture

It is this mechanism which has been bypassed in this attack scenario.

The overall idea

The generic attack scenario is to modify the STM32 firmware while faking its genuineness to the SE. The STM32 firmware can be modified:

  • When launching in bootloader mode (boot with left button pressed)
  • When physically obtaining the device, over the exposed STM32 debugging interface (JTAG)

From this, several attacks scenario can be designed such as changing the display or faking user confirmation. The Secure Element authenticates the MCU to protect the device against these attacks. It sends a command which requests to the MCU entire content of its memory and the signature.

This verification was not robust enough and it’s been demonstrated that code caving was possible without affecting the signature of the MCU firmware. The idea is to hide code inside unused part of the memory. But in order to get a correct signature verification, the firmware dump command must be modified.

When the SE verifies the signature, it sends a command to the MCU requesting the MCU to dump its memory and to send it to the SE. The idea is then to modify this function in order to send the same stream to the SE without actually dumping the memory.

However, these scenario are difficult to put in place because of a very simple reason: the memory size of the STM32 is very small (32 Kb) – the attacker has to include both code modifications and the existing code in order to pass the validation.

Two different kinds of scenarios have been imagined by the security researcher:

  • The first one consists in getting a physical access to the device under attack. Then load a modified firmware on the MCU which would try to trick the user or the SE. For instance it could simulate button pushes. In this scenario, a malware on the desktop PC would try to ask for transactions to the Nano S. As soon as the user enters its PIN, the malware would present a transaction to be signed and the modified firmware would simulate the buttons press bypassing the explicit user consent. One should note this scenario has not been demonstrated while theoretically possible.
  • In the second scenario presented by the researcher, the attack would allow to mount a scam. A malicious seller would load a modified firmware on a preseeded wallet which would trick the user. On this modified firmware, the seed generation phase is replaced. And instead of generating a new seed it would just display the 24 words pre-configured by the attacker. This scenario has been demonstrated by the researcher.

Thanks to our versatile architecture using a Secure Element, we can update our firmware and connect back to our root of trust the Secure Element.

This attack cannot extract the private keys or the seed. The Secure Element (containing the secrets) is not at all concerned by the MCU fooling. We can also detect if this attack has been deployed in the wild every time a device connects back to our server using the Ledger Manager to load an application or update the firmware. Our genuineness check has been upgraded to thwart this.

Countermeasure

Our upgrade is quite simple while efficient:

  • The MCU code has been refactored preventing simple code caving
  • The signature verification is now enforced using two different mechanism
  • Address fetch randomization
  • Timing constraints preventing the MCU to “uncompress” data to send to the SE
  • Several CRC code and checks are added filling up the MCU memory and preventing the modification of the memory without detection

Impact on Ledger devices

If you bought your device from Ledger or an authorized reseller, it is extremely unlikely that your device could have been compromised using the above scenario.

If you bought your device from a different channel, if this is a second hand device, or if you are unsure, then you could be victim of an elaborate scam.

In both cases, a successful firmware update is the proof that the device has never been compromised. Moreover, a successful firmware upgrade is the proof that the device was never the target of such attack. Firmware from version 1.4 fully mitigates the attack.

Credits

We would like to thank the security researcher Saleem Rashid who discovered the vulnerability and reported it through our bug bounty program. We also thank him for his good work, his help and his professionalism through the disclosure process.

References

  1. Firmware 1.4: deep dive into three vulnerabilities which have been fixed - Ledger
  2. Breaking the Ledger Security Model - Saleem Rashid