A security researcher just released a report detailing a set of attacks that exploit a vulnerability in Ledger hardware wallets.
He details multiple modes of attack -- including remote attacks, or ones that require physical access either before or after setup of the recovery seed. For example, supply chain attacks, where a dishonest vendor can modify the device before you physically receive it.
Personally, I've been skeptical of some of the bold assurances made by Ledger regarding key security. The author notes:
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.
Physical access before setup of the seed
Also 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.
As you can tell from the video above, it is trivial to perform a supply chain attack that modifies the generated recovery seed. Since all private keys are derived from the recovery seed, the attacker could steal any funds loaded onto the device.
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.
He proceeds in some detail and outlines very simple versions of the attacks. I highly recommend reading the full article. But here are some more background tidbits:
While the software on the SE can be attested to, the MCU is a non-secure chip and (as we show below) its firmware can be replaced by an attacker.
And herein lies the problem: to achieve Ledger’s security guarantees, the chain of trust must be anchored in the SE. This means that the SE needs to verify the firmware on the MCU.
While I will focus on software tampering in this article, it’s important to note that, in the absence of a software vulnerability, you could still compromise the device by tampering with hardware.
It is incredibly important to note that, for these devices to be secure at all, you must completely verify the physical hardware.
Since neither the packaging nor the actual device are tamper-evident, it is trivial for an attacker to modify the device. I cannot repeat this enough: if you do not verify the physical hardware, it is game over.
You should also verify the hardware whenever someone could have had unauthorized access to it, otherwise you are vulnerable to Evil Maid attacks.
Ledger provides instructions to do this, but I will note two issues with them.
1) The pictures are of varying quality. Ledger needs to provide high resolution images that display every component clearly.
2) The reverse of the device is not displayed at all! It is essential that you verify the back of the device, especially since this is where the JTAG header (a debugging interface) for the MCU resides.
Even if these two issues are resolved, I would question how expensive it is to have one of the MCUs with additional flash memory, but identical pinout, to be re-labelled as an STM32F042K6.
Nevertheless, while it is important to touch on this topic, hardware tampering is not required for the attack I will describe in this article.
If we can modify the user interface, we can change the recovery seed that is generated during the onboarding process. This is quite easy since the user interface is open source and Ledger allows you (by design!) to install a modified UX application.
Under normal circumstances, the device would display a warning that the “User interface is not genuine”, which would be a red flag for any attentive user.
But recall that I promised that I would explain how controlling the display can backdoor the key generation? The reason this attack works is that we can simply hide the non-genuine UX warning.
For this demonstration, we’re not going to do anything sophisticated that a real attacker would do, such as generating a random-looking, yet entirely predictable, recovery seed.
We’re going to do something much more obvious.
If you’re well-versed in C, you’ll note that I’m replacing a syscall to the random number generator with a function call that sets all the entropy to zero. As you can see in the video at the start, it generates a recovery seed where the first 23 words are abandon (the last word is different because it is a checksum).
Since the private keys are derived from the recovery seed, if you control the recovery seed, you control all the Bitcoin addresses generated by the device.
If we put it all together, we get the following attack which I think is really neat.
Of course, since the SE believes the MCU is running genuine firmware, attestation still succeeds. And, as I mentioned earlier, no hardware tampering was required, which defeats Ledger’s security integrity verification.
Since the attacker controls the trusted display and hardware buttons, it is astonishingly difficult to detect and remove a well-written exploit from the device.
The problem with an architectural vulnerability like this is that it is challenging to fix without changing the architecture.
Ledger has employed multiple mitigations to try and prevent an attacker from exploiting this vulnerability.
First of all, the MCU firmware has been optimized and rearranged. Specifically, the firmware calls into functions in the bootloader instead of duplicating the functions. While this prevents this particular mode of attack, it’s important to be aware that there are other, more “creative” methods of attack that I know of, and probably some that I don’t know of.
Secondly, the SE now times the MCU when it asks it to send the flash contents. This is designed to prevent the use of compression algorithms. It is also supposed to prevent code being supplied by the computer over USB. I’m not sure how well it succeeds in doing the latter, due to the fact that the code can be kept in RAM.
However, it’s of note that the SE runs at up to 28 MHz yet the “adversary” (the MCU) runs at up to 80 MHz! This throws into question whether a slower chip can accurately time a faster chip to prevent it from doing extra things, especially given the slow UART communication.
Ledger refused to send me a release candidate, so I haven’t had an opportunity to verify how well these mitigations resolve the issue. But these raise an important question.
Is it truly possible to use a combination of timing and “difficult to compress” firmware to achieve security in this model?
Building secure systems using this model seems like an incredibly exciting research proposition and I think it’s interesting to see companies like Ledger pushing the envelope on this.
Read the full article here:
https://saleemrashid.com/2018/03/20/breaking-ledger-security-model/
