In this post, I’m going to discuss a vulnerability I discovered in Ledger hardware wallets. The vulnerability arose due to Ledger’s use of a custom architecture to work around many of the limitations of their Secure Element.
An attacker can exploit this vulnerability to compromise the device before the user receives it, or to steal private keys from the device physically or, in some scenarios, remotely.
- Physical access before setup of the seedAlso known as a “supply chain attack”, this is the focus of this article. It does not require malware on the target computer, nor does it require the user to confirm any transactions. Despite claims otherwise, I have demonstrated this attack on a real Ledger Nano S. Furthermore, I sent the source code to Ledger a few months ago, so they could reproduce it.
Physical access after setup
This is commonly known as an “Evil Maid attack”. This attack would allow you to extract the PIN, recovery seed and any BIP-39 passphrases used, provided the device is used at least once after you attack it.
As before, this does not require malware on the computer, nor does it require the user to confirm any transactions. It simply requires an attacker to install a custom MCU firmware that can exfiltrate the private keys without the user’s knowledge, next time they use it.
Malware (with a hint of social engineering)
This attack would require the user to update the MCU firmware on an infected computer. This could be achieved by displaying an error message that asks the user to reconnect the device with the left button held down (to enter the MCU bootloader). Then the malware can update the MCU with malicious code, allowing the malware to take control of the trusted display and confirmation buttons on the device.
This attack becomes incredibly lucrative if used when a legitimate firmware update is released, as was the case two weeks ago.
Proof of Concept
If you want to miss out on the fun of building an exploit yourself, you can find my proof-of-concept on GitHub.
If you follow the instructions there and install it on a Ledger Nano S running firmware 1.3.1 or below, you will be able to reenact the attack in the video above. However, because this is for educational purposes only, I have deliberately made the attack slightly less reliable.
A Note on Responsible Disclosure
Before I get to the details of the vulnerability, I would like to make it clear that I have not been paid a bounty by Ledger because their responsible disclosure agreement would have prevented me from publishing this technical report.
I chose to publish this report in lieu of receiving a bounty from Ledger, mainly because Eric Larchevêque, Ledger’s CEO, made some comments on Reddit which were fraught with technical inaccuracy. As a result of this I became concerned that this vulnerability would not be properly explained to customers.
I discuss my interactions with Ledger at the end of the article.
Background on Hardware Wallets
Cryptocurrencies, such as Bitcoin, use public key cryptography to protect funds. You can only spend the funds if you have the private key.
This creates an issue for the user as to how they should secure their private key. Humans are notoriously terrible at securing secrets and devices; even security experts are not infallible.
To solve this problem, a class of devices called “hardware wallets” have been invented. As the name suggests, these are hardware devices that store users’ private keys to protect against malware. Many of these devices connect to a PC via a USB port, but do not reveal the private keys to the PC, much like a hardware security module (HSM).
However, acquiring the private keys is not the only way an attacker can steal your beloved Bitcoin. An attacker who compromises such a device could simply change the recipient of the transaction and the amount being spent! If this is done surreptitiously, many users will be unaware of this attack until it’s far too late to recover the funds.
Therefore, any useable hardware wallet really needs the following features, which differentiate it from a dumb HSM
- A trusted display for visual verification of the transaction information
- On-device buttons, in order to confirm or deny signing transactions
Hardware wallets need to protect against a wide variety of attacks, including:
- Remote attacks (when an attacker can steal your private keys through malware on your computer)
- Supply chain attacks (when an attacker can modify the device to do Bad Things™ before you receive it)
- Unauthorized physical access (when an attacker can compromise the device if they obtain physical access)
We can further divide the last attack vector into two types: theft and “Evil Maid attacks”. If an attacker can steal the device, they have a longer duration of time to perform an attack, and possibly access to expensive lab equipment. However, they may be thwarted by you realizing your device is missing, and moving your funds to new private keys.
Security features, such as duress passphrases which aren’t stored on the device, can prevent the attacker from stealing your funds in this scenario because the device simply does not contain the information necessary to recover the private keys.
On the other hand, with an “Evil Maid attack”, the attacker might have a limited time to perform the attack, and won’t have an expensive lab at their disposal. These attacks can be far more dangerous due to the wide variety of scenarios they can be employed in:
- As the name suggests, an “evil maid” could compromise your device while they clean your hotel room
- Your device could be taken from you for a short time as you pass through airport security
- You might entrust your device to a relative or lawyer
In this disclosure, we will focus primarily on the case of supply chain attacks. That is: whether or not you can trust your hardware wallet when you purchase it from a reseller or third party. But, as I explain briefly at the beginning of this article, the methods described here can be applied to the other two attack vectors.
Source/More: Breaking the Ledger Security Model | Saleem Rashid
