Firmware 1.4: deep dive into three vulnerabilities which have been fixed

We would like to take the time to detail the security improvements made to our firmware, initially detailed on the blog post New firmware update 1.4.1 available for the Nano S published on the 6th of March. Following a transparent and responsible disclosure process, we are giving a full detailed assessment of the fixed attack vectors that the Firmware 1.4 patches, which were initially reported by three security researchers.

As the publication of these technical details might elevate the threat level of non-patched devices, we strongly encourage our users to update their firmware by following our step by step guide.

Summary

1. 1. Bounty Program & Responsible Disclosure
   2. Recommendations

1. Detailed Security Updates

Take away: the firmware update patches three security issues. The update process verifies the integrity of your device and a successful 1.4.1 update is the guarantee that your device has not been the target of any of the patched attack. There is no need to take any other action, your seed / private keys are safe.

For more details, and an in-depth explanation of all the attack vectors, please read this article. We also invite you to consult the FAQ at the end.
Update: Thimotee Isnard and Sergei Volokitin followed the responsible disclosure agreement process and were awarded with a Bounty, while Saleem Rashid refused to sign the Ledger Bounty Program Reward Agreement.

Bounty Program & Responsible disclosure

We would like to congratulate the three security researchers who found these bounties. We have been working closely with them to understand their findings and assess how serious it could be.

With their permissions, these three security researchers are (in alphabetic order by last name):

• Timothée Isnard – Padding oracle attack on SCP
• Saleem Rashid – MCU fooling
• Sergei Volokitin – Isolation Exploit

We want to stress out the professionalism and skills of these three white hats who worked together with our security team and strictly respected our Bounty Program process. We fully appreciate their contribution, and they certainly deserve their rewards. We have asked each security researcher to sign our Ledger Bounty Program Reward Agreement, that you can review as part of our transparency process (this document doesn’t prevent the researcher to publish their own reports).

In the security world, responsible disclosure is very important to prevent hackers from using the vulnerability. This is what distinguishes a white hat from a black hat, an irresponsible security researcher from a responsible security researcher.

You will find after our recommendations a description of the issues reported by these three researchers. Buckle your security belt, it’s gonna be a bit technical 🙂

2. Recommendations

Upgrading the Nano S with the firmware 1.4.1 entirely secures it, as it immediately solves all potential security threats. The firmware update process verifies the integrity of your device and a successful 1.4.1 update is the guarantee that your device has not been tampered with.
Important note: if your firmware update fails, it doesn’t mean that your device is compromised! Please see our FAQ at the end of the article for more information.

As you may want to understand more precisely the impact of the mitigated security issues, you will find below an overview of each attack’s impact.

Padding oracle attack on SCP

No impact regarding the security of your device.

MCU fooling

By having physical access to the device before generation of the seed, an attacker could fool the device by injecting his seed instead of generating a new one. The most likely scenario would be a scam operation from a shady reseller.

• 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. However, as no demonstration of the attack in the real has been shown, it is very unlikely;

In both cases, a successful firmware update is the proof that your device has never been compromised.

Isolation exploit

This attack can be achieved only by having physical access to the device, knowing your PIN code and installing a rogue unsigned application. This rogue app could break isolation between apps and access sensitive data managed by specific apps such as GPG, U2F or Neo.
If you have never installed an unsigned application yourself (requiring the use of command line tools and ignoring a security warning on the device), then you are perfectly safe.

Detailed Security Updates

Padding oracle attack on SCP – Timothée Isnard

Loading and upgrading BOLOS

The load and upgrade of BOLOS is performed using a Secure Channel. It’s inspired from the Global Platform SCP-02 standard, modified by replacing T-DES with AES. This protocol guarantees authenticity and confidentiality. It’s based on an “Encrypt then MAC” scheme.

When BOLOS needs to be upgraded, a secure channel is established between the Secure Element of the device and Ledger’s HSM. This channel allows to send our firmware in an encrypted way. Furthermore, it also allows the HSM to attest the Ledger device to which it’s connected is genuine. Finally, the firmware authenticity is proven using a standard signature. The modified version of our SCP-02 we implemented did not embed the MAC part allowing a padding oracle attack.

Padding oracle attack

The padding oracle attack is a famous cryptographic attack discovered in 2002 by Serge Vaudenay. It allows an attacker to know  whether the padding of an encrypted message is correct or not. This mechanism allows to decrypt the datastream without actually knowing the key being used. Mounting this attack can be a bit tricky, especially considering that the throughput of the leakage is very low.

In our case, the researcher demonstrated that it was possible to mount the attack but was only able to retrieve a few bytes of the datastream.

He worked a lot on understanding our protocol and how the secure channel is mounted. It consists first on an ECDH to share a common secret which is used afterwards as the key for the AES-CBC. The IV is initially 0x0. The padding check is performed by the device, if it’s not found, a status error is raised 0x6802, otherwise, the message is handled normally.

To implement it, it’s necessary to brute force all possible value of a byte paddings so that the guessed plaintext byte turns into a 0x80, mounting another Secure Channel each time in order to retrieve which one gives the correct message. The throughput is thus very low since our HSM is shared with all our users and mostly because there are a lot of different padding values to test.

From a user perspective, it’s not a problem. We don’t base the security of our devices on the confidentiality of our firmware. The security of your device is based on the value of your seed which is protected by our OS and the Secure Element. Decrypting our firmware wouldn’t give to the attacker more information on your seed/secret data.

On the contrary, what is important from a user perspective is to able to prove the genuineness of your device and the authenticity of the firmware you load. Those two security claims remain intact.

Countermeasure

Our SCP has been updated to add the MAC part which prevents this kind of attack. Furthermore, additional countermeasures have been implemented server side mitigating the issue until the 1.4.1 upgrade is available.

What should you do

Upgrading the firmware will fully mitigate the attack. No need to change your seed as this attack vector could not have compromise anything.

All the security team would like to congratulate Timothée for this good work, his help and his professionalism through the disclosure process. 

MCU fooling – Saleem Rashid

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 SE is requesting the STM32 firmware, hashing it and checking a signature to guarantee the device integrity.

This is that mechanism which has been dodged in this attack scenario.

 

The overall idea

The generic attack scenario is to modify the STM32 firmware while faking its genuiness 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 involving changing the display or faking user confirmation.

To avoid these attacks scenarios, the secure element authenticates the MCU. 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 some code caving was possible still respecting the signature of the MCU firmware.

Code caving is pretty tricky. 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 secure element. 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 field every time a device connects back to our server using Ledger Manager to load an application or update the firmware. Our genuineness check have been upgraded to counter this.

Countermeasures

Our upgrade is quite simple while completely 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

What should you do

Upgrading the firmware will fully mitigate the attack. Moreover, a successfull firmware upgrade is the proof that your device was never the target of such attack.

All the security team would like to congratulate Saleem for this good work, his help and his professionalism through the disclosure process. 

Isolation exploit – Sergei Volokitin

BOLOS Architecture

In order to understand all the work performed by Sergei, it’s important to have an overview of BOLOS architecture.

BOLOS (Ledger’s OS) is a native and versatile OS which can be implemented on several Hardware architectures. It uses most of the security features brought by the Secure Element (Nano-S case).

The OS lies on the Secure Hardware and use the certified security functions implemented in the Hardware.

It offers cryptographic primitives which allows applications to compute electronic signatures for instance. To compute an electronic signature the app performs a syscall to BOLOS which takes advantage of the secure hardware to compute securely the digital signature. Furthermore the OS contains certificate allowing to update itself securely. This certificate allows to authenticate your device preventing Ledger devices to be cloned.

It also contains a service which authenticates the applications loaded on top of it. It’s possible to load signed app and unsigned app as well. In this last case a warning is displayed on the screen when launched.

Finally, the OS provides memory isolation. It means for instance that BTC app can not access to the data of the ETH app. This mechanism is enforced using the MPU of the Secure Element.

However, when an app is installed it can derive any key path. So even if the memory isolation is implemented, It’s possible to load an app which can access the private keys of any cryptocurrency. The derived paths during the install can be checked looking at the loading files.
As it’s a bit technical, Ledger strongly recommend to load only signed (by Ledger) app which only derives their own path.

Bypassing the isolation

The security researcher found a bug in our isolation implementation. In several syscalls offered by BOLOS, the pointers the parameters were not correctly checked allowing to reference NULL pointer, or to give pointers located in other regions of the memories. Additionally, in some conditions, the MPU bounds were incorrectly positioned allowing a malicious app to use these syscalls in order to access data outside of its scope.

NULL Pointer dereferencing

This PoC is particularly smart. The researcher built an oracle allowing to use the Hash primitive to dump part of memory. The idea is to call cx_hash_sha256 with a null pointer varying the length of data to be hashed. The data at offset 0x00 is then hashed by the cx_hash_sha256 service and the result of the hash is returned.

Secure Hash are one-way function but requesting a hash of length 1, allows the attacker to try all possible value for the byte and check which one gives the returned hash. The same process is applied with length 2 knowing the first byte and so on.
Consequences: It allowed the researcher to dump a large amount of data. The seed and private keys remained secure.
Countermeasure: The pointer is now properly checked and the MPU windows correctly positioned.

Pointers length not properly checked

The length of some syscalls (cx_hash_syscall, cx_rsa_sign, cx_ecdsa_sign) was not sufficiently checked.
Using a malicious applet, it’s possible to use these syscalls to retrieve partial information. Indeed, depending on the value of the RSA_key or of the hash structure header, the crypto service returns a different error.

• The attack scenario is the following
• • Load a malicious app which requests one of these crypto service

• • The crypto service is called with an incorrect length parameters

• Depending on the value of the pointed memory, a different exception is raised

Consequences: It allows to distinguish some specific value in the memory.
In the RSA case, it’s possible to know if a specific 32-bit value at a given memory address equals one of these values 0x80000000, 0x00010000, 0x80010000, 0x00020000, or not.

The researcher thought these values were from the RSA key while they belong to the next app.

In the hash case, it’s possible to know if a specific 8-bit value at a given memory address is comprised between 1 and 8.

In the ecdsa_sign, it’s possible to retrieve 64 bytes of the memory of the following application. In this case the implemented mechanism is even trickier and won’t be detailed here.

In these 3 cases, this is partial information dump but leads at least to an entropy reduction and is thus considered as an attack. Again the seed and private keys remained secure.

Again these 3 vectors are very smart oracles.

Countermeasure: The length parameters are now properly checked and the MPU windows correctly positioned.

Device wipe

After 3 PIN resets, the device wipes the OS data memory, erasing the seed and the private keys which are stored in the OS data memory. But the device does not wipe the apps data. The researcher showed it’s possible to retrieve the data in a previously installed app. The scenario is the following:

• Get a device
• Perform 3 wrong PINs to trigger a wipe
• Install a specific (unsigned) app with a large uninitialized data zone and a command allowing to dump this zone

Consequences: This allowed the researcher to dump memory of already installed app breaking thus the isolation. In our signed applications, secret data are not stored in their flash zone. Only the following applications could have been revealed application data information:

• Neo (a third party app)
• PGP (a developer app). It allows the user to import its private key which is clearly not protected by the seed
• Monero Beta: this app is only a beta app since it’s released yet. Monero offers different way to handle the key. At the beginning there was no BIP derivation.
• U2F: on this app, the researcher proved it was possible to retrieve the HMAC Key and the current value of the counter of the U2F app.

Again the seed and all private keys of other apps remained secure.
Countermeasure: The flash user zone is also wiped after 3 wrong PINs. This wipe is checked at startup. The new design is completely tearing proof.

What should you do

Updating the firmware fully mitigate the attacks. Seed and private keys remained secure so no other action necessary.

All the security team would like to congratulate Sergei for this good work, his help and his professionalism through the disclosure process. 
Charles Guillemet,
Chief Security Officer at Ledger

For more information:

• Guide – How to update my Ledger Nano S with the firmware 1.4
• FAQ – Frequently Asked Questions regarding the firmware 1.4

FAQ

What will happen if I do not update the Nano S?

The firmware update is not mandatory and there is no mechanism to force an upgrade. As the main attack vector is the “shady reseller scam”, an already initialized device is less likely to be compromised by the attack. However, we of course recommend to update.

Should I update my device even if I’m not using it?

If you are not using your device, or if you do not have access to it, there is no need to update it now. You can proceed to the update one you get access to it.

Was my seed compromised in any way? Should I use a new one?

The Secure Element containing the secrets has not been breached, and it is not possible in any of the attack to extract the seed (even with physical possession of the device). What has been demonstrated in the “shady reseller scam” is the possibility to fake the seed generation and make you use the one from the attacker. Successfully upgrading the device proves that it wasn’t compromised by this attack.

What is the firmware update fails? Does it mean my seed is compromised?

No. The firmware update is a process requires many steps and manipulations. There are also some issues on Windows 7 and 10. Make sure you follow the step by step guide, and consult our FAQ for troubleshooting. On hundreds of thousands of updates done, there were a lof of difficulties but the update eventually succeeded. If your device was compromised, it wouldn’t pass the first step.

What about the Ledger Blue?

The security issues presented here are also valid or the Blue (as it has the same architecture than the Nano S). A security firmware update is in the works but we do not have any availability date. As the Blue as been distributed almost exclusively through direct sales, the probability to run the “shady reseller scam” is negligible. If you have bought your device outside of Ledger direct distribution channel, please contact us with your invoice so we can confirm it was sold from an authorized reseller.