wallet.fail - 35C3 talk on hardware wallet vulnerabilities (Ledger, Trezor)

[HeRetiK]

A couple of security researchers just presented a talk at the 35C3 regarding a couple of security vulnerabilities in common hardware wallets:

https://www.youtube.com/watch?v=Y1OBIGslgGM


Most notably they found the following vulnerabilities:

1) Flashing the Ledger Nano S with custom firmware without the device noticing (starting @ 17:00)

2) A sidechannel attack allowing to remotely read the PIN entered into Ledger Blue devices (@ 28:30)

3) Extracting the menomic seed phrase and PIN from Trezor One devices (@ 35:00)


1) and 3) require direct physical access to the device while 2) require an attacker to be rather close by, so obviously the security level is still way beyond regular software wallets.


Keep in mind that vulnerabilities found in these devices do not imply that other hardware wallets are more secure. As mentioned in the last few minutes of the talk, the researchers found other vulnerabilities in other wallets as well, the ones they presented are merely a collection of the most interesting ones. Still it will be interesting to see if and when these vulnerabilities will be fixed (responsible disclosure appears to have been made, with the Trezor CTO participating in the Q&A towards the end of the video).

[1714953997]

1714953997

[1714953997]

1714953997

[1714953997]

1714953997

[gentlemand]

Still it will be interesting to see if and when these vulnerabilities will be fixed (responsible disclosure appears to have been made, with the Trezor CTO participating in the Q&A towards the end of the video).

Even if the current holes are fixed, others will pop up. This is the nature of anything programmable and accessible. A lot of the angles in these demonstrations are rely on a fairly unlikely set of circumstances but it's still not great.

The main thing I took away from it is using a 25th password saves you from quite a few sad outcomes.

[Lucius]

Interesting video, I have to admit I looked at the part which show Flashing the Ledger Nano S with custom firmware just because I use that HW. In this part of video we can see that is possible to flash Nano S with custom firmware, and in case they presented we see that instead HW you can turn on this device in miniature game console and play game snake.

Yet this is no threat that can affect current users since requires physical access to the device, but it show that Ledger still have no solution to prevent that device is flash with custom firmware. So if hackers find way to trick users with false firmware update, it is possible that this could be one of the vectors of the attack.

The worst possible scenario : Hackers hack official Ledger site, add fake firmware and try to get as many users as possible. Maybe it's not a true comparison, but who could have imagined a few days ago that hackers will use original Electrum wallet to steal hundreds, and probably thousands of BTC?

Hardware wallets are safe, more then any desktop/online wallet, but we should never ignore the potential danger which is lurking from some dark corner. I would not want to play snake on my Nano S in time hackers play with my BTC.

[gentlemand]

The worst possible scenario : Hackers hack official Ledger site, add fake firmware and try to get as many users as possible. Maybe it's not a true comparison, but who could have imagined a few days ago that hackers will use original Electrum wallet to steal hundreds, and probably thousands of BTC?

I'd like to know the security procedures of their hosts because this is going to become an ever more obvious vector. We'll see it happen to more decentralised exchanges as long as they remain website based and something like this is a vast temptation. It does make me wonder whether it's only a matter of time. Every update makes me nervous.

[HeRetiK]

Interesting video, I have to admit I looked at the part which show Flashing the Ledger Nano S with custom firmware just because I use that HW. In this part of video we can see that is possible to flash Nano S with custom firmware, and in case they presented we see that instead HW you can turn on this device in miniature game console and play game snake.

Yet this is no threat that can affect current users since requires physical access to the device, but it show that Ledger still have no solution to prevent that device is flash with custom firmware. So if hackers find way to trick users with false firmware update, it is possible that this could be one of the vectors of the attack.

The worst possible scenario : Hackers hack official Ledger site, add fake firmware and try to get as many users as possible. Maybe it's not a true comparison, but who could have imagined a few days ago that hackers will use original Electrum wallet to steal hundreds, and probably thousands of BTC? [...]

The problem is less with being able to flash the Nano S with custom firmware, but rather with flashing the Nano S with custom firmware without the device noticing and warning the user. In this regard I have to tip my hat to SatoshiLabs that at least their firmware check was solid enough as to force these researchers to resort to a rather sophisticated attack on the hardware level (for what little good it brought, in the end). So at least in SatoshiLabs' case the scenario of hacking the update server and deploying malicious firmware appears to be non-viable.

Still, rather worrying, especially given the fact that for the Ledger Nano S an attack on the software level was sufficient. I think the Ledger vulnerabilities should be fairly straightforward to fix, about the Trezor One I'm not so sure, given the complexity of the issue. Worse still I wouldn't be surprised if one could mount a similar hardware-level attack on Ledger devices.

Regardless of would-be attackers requiring physical access to the device I still wouldn't shrug it off as a practical non-threat. Obviously once an attacker is able to attain physical access to your hardware wallet you'll likely have more acute problems than firmware integrity (ie. getting a "memory dump" from you, as a person, is likely more trivial than getting one from your hardware wallet). However at least to me personally results like these mostly serve as a stark reminder of how hard it is to get security right (ie. if it's possible to break the most popular, trusted and peer-reviewed hardware wallets, I don't even want to think about the rest of the market).

[...]

The main thing I took away from it is using a 25th password saves you from quite a few sad outcomes.

I guess that depends on the attack vector. If the firmware itself is compromised, the 25th password is likely to get compromised as well. It definitely protects against memory dumps as described in the Trezor One attack though -- or at least it should buy enough time to move your coins before the attacker can access them.


---


Come to think of it, I'm now really worried about Ledger's update server getting compromised. I don't think compromising Ledger's update servers would be easy, especially unnoticed, but as long as their wallet's bootloader can be tricked an attack scenario as described by Lucius would allow for remotely compromising Ledger hardware wallets without direct physical access O.o

[trantute2]

With respect to the Trezor attack:

The attack is useless, if one uses a passphrase! This is explicitly stated by one of the guys at 00:50:30.

So if the hardware offers the use of a passphrase, use a passphrase!!!11

[o_e_l_e_o]

Interesting video, I have to admit I looked at the part which show Flashing the Ledger Nano S with custom firmware just because I use that HW. In this part of video we can see that is possible to flash Nano S with custom firmware, and in case they presented we see that instead HW you can turn on this device in miniature game console and play game snake.

Correct me if I'm wrong, but at 17:00 onwards I see them succeeding in installing custom firmware and running it via the Bootloader only? They don't actually run any custom firmware which has access to the secure element, which is where your seed and PIN are stored.

[o_e_l_e_o]

Regarding flashing custom firmware on Ledger Nano S, is hidden account also compromised?

They've not yet proven that any account is compromised.

Just saw this link posted in a thread on Bitcoin Discussion: https://www.ledger.fr/2018/12/28/chaos-communication-congress-in-response-to-wallet-fails-presentation/

It seems to confirm what I was saying. In short, they used a bug to install custom firmware in the bootloader, but did not access the secure element or manage to extract any PINs or seeds, and the bug will be patched in the next firmware version. I'm also pretty impressed by the response time from the Ledger team here.

[HeRetiK]

[...]

It seems to confirm what I was saying. In short, they used a bug to install custom firmware in the bootloader, but did not access the secure element or manage to extract any PINs or seeds, and the bug will be patched in the next firmware version. I'm also pretty impressed by the response time from the Ledger team here.

Indeed. It seems like we can also expect a Trezor fix by the end of January:

https://twitter.com/pavolrusnak/status/1078568510182309889?s=21

Turns out the researchers didn't follow customary responsible disclosure procedures, which is slightly disappointing. I guess both Ledger and SatoshiLabs would have appreciated a bit of a headstart, especially given the fact that both companies have a great track record of cooperating with security researchers and fixing found vulnerabilities in a timely manner (something which unfortunately is not quite as common as one may hope). Nonetheless it's good to know that researchers like them are out there, as findings of this kind help hardening hardware wallets.

[HCP]

There is a really good overview/intro to the "f00dbabe" hack on the Ledger here: https://www.youtube.com/watch?v=nNBktKw9Is4

IMO, he explains it very well in fairly simple terms... as well as reiterating that while they have custom firmware running, private keys are not able to be extracted (yet?). They've managed to trick the device to run a custom firmware, but communication with the Secure Element is another story (which also seems to be what Ledger are claiming).

Certainly a timely reminder that there is no 100% secure setup... there will always be vulnerabilities.

[cellard]

I never liked the idea of devices designed with storing bitcoin as its sole purpose. I've seen some pretty dubious stuff like this:

https://www.reddit.com/r/TREZOR/comments/6yti7p/trezor_bridge_trezordexe_calling_home/

Why would stuff like this be necessary when you can bypass it with a solid linux airgapped laptop? sure it's not as convenient moving a laptop around, but you still a computer with those devices nonetheless.

Also beside the potential exploits, it's just a device that screams "there is money inside, please steal it"

[Lucius]

I'd like to know the security procedures of their hosts because this is going to become an ever more obvious vector. We'll see it happen to more decentralised exchanges as long as they remain website based and something like this is a vast temptation. It does make me wonder whether it's only a matter of time. Every update makes me nervous.

I think Ledger will never discover such information to public, maybe it would only help with possible hacking. What is more important to me is that they work more on the overall security of their service, and to anticipate possible vector attacks, otherwise it is only a matter of time when some clever hackers find a way to hack them.

I guess that depends on the attack vector. If the firmware itself is compromised, the 25th password is likely to get compromised as well. It definitely protects against memory dumps as described in the Trezor One attack though -- or at least it should buy enough time to move your coins before the attacker can access them.
---
Come to think of it, I'm now really worried about Ledger's update server getting compromised. I don't think compromising Ledger's update servers would be easy, especially unnoticed, but as long as their wallet's bootloader can be tricked an attack scenario as described by Lucius would allow for remotely compromising Ledger hardware wallets without direct physical access O.o

Because of that is always smart to wait some time with updates, but some users just click update/upgrade button as soon as they see it. Problem would be if hackers can upgrade firmware without the knowledge of the user, and if that firmware have possibility to get user seed and send it back to hacker. I'm not sure how this is technically feasible in this moment, but we see that smart people always find way to do some things which was thought to be not possible.

It seems to confirm what I was saying. In short, they used a bug to install custom firmware in the bootloader, but did not access the secure element or manage to extract any PINs or seeds, and the bug will be patched in the next firmware version. I'm also pretty impressed by the response time from the Ledger team here.

True, as HCP say private keys are not able to be extracted (yet?). I am not impressed by Ledger response regarding this issue, they shoud fix that long time ago (if they know for this), and not wait that such things are be publicly displayed. As in the case Saleem Rashid and his Breaking the Ledger Security Model Ledger is responds only after others discover potential threats.

We can be grateful that they are a good hackers, and not some bad guys. But it also proves that Ledger as a company is always lagging behind, they should discover such things themselves - can we talk about the lack of real experts in Ledger or just negligence and lack of professionalism in their work?

[gentlemand]

I think Ledger will never discover such information to public, maybe it would only help with possible hacking. What is more important to me is that they work more on the overall security of their service, and to anticipate possible vector attacks, otherwise it is only a matter of time when some clever hackers find a way to hack them.

I have not been inspired by Ledger's faintly derisive attitude to the people who chip away at their security. Trezor seem to have much more humility and openness. Though I prefer the way the Trezor operates anyway, I'd favour them over Ledger primarily because of their approach to this area.

[o_e_l_e_o]

Because of that is always smart to wait some time with updates, but some users just click update/upgrade button as soon as they see it.

The problem with that approach is if a critical vulnerability has been discovered in the current firmware, and you are advised to upgrade ASAP. If you also want to wait a week (or longer) after the latest firmware has been released to ensure that there is nothing wrong or malicious with it, then you are essentially stuck without being able to safely use your device in the meantime.

I am not impressed by Ledger response regarding this issue, they shoud fix that long time ago (if they know for this), and not wait that such things are be publicly displayed.

Ledger have a Bounty Program (http://www.ledger.fr/bounty-program/) for people who find bugs, so they can be responsibly disclosed and patched. Ledger even said in their response that "We regret that the researchers did not follow the standard security principles outlined in Ledger’s Bounty program." I can see where you are coming from, and in an ideal world there would be no issues whatsoever, but this is an unrealistic standard to hold. Bugs will always be discovered, and we can't really expect them to fix a bug they weren't informed about. This video was posted on the 27th and they had addressed it by the 28th. I think that's pretty good.

[HeRetiK]

I never liked the idea of devices designed with storing bitcoin as its sole purpose. I've seen some pretty dubious stuff like this:

https://www.reddit.com/r/TREZOR/comments/6yti7p/trezor_bridge_trezordexe_calling_home/

Why would stuff like this be necessary when you can bypass it with a solid linux airgapped laptop? sure it's not as convenient moving a laptop around, but you still a computer with those devices nonetheless.

Also beside the potential exploits, it's just a device that screams "there is money inside, please steal it"

Using an airgapped linux laptop with an encrypted hard drive is just as fine, IMO. Convenience and ease of use is a big factor though, especially as securing a linux system from attacks involving physical access is not that trivial either.

In my opinion, the easier something can be securely used without messing things up, the better. The harder using something securely becomes, the less hardware / software security starts to matter and the more of a liability the human factor becomes. And the human factor is a huge liability.

I guess in the end it's mostly a matter of personal philosophy and preference though.

I have not been inspired by Ledger's faintly derisive attitude to the people who chip away at their security. Trezor seem to have much more humility and openness. Though I prefer the way the Trezor operates anyway, I'd favour them over Ledger primarily because of their approach to this area.

I feel the same. The exploit used to circumvent Ledger's firmware check is not quite instilling confidence in their software security (contrasted to the 3 months of hardware glitching necessary for the Trezor exploit). That Ledger's security appears to partially depend on security through obscurity is also slightly worrying. In general they nonetheless appear to do good work though, otherwise they wouldn't have gotten off that easily.

[Lucius]

The problem with that approach is if a critical vulnerability has been discovered in the current firmware, and you are advised to upgrade ASAP. If you also want to wait a week (or longer) after the latest firmware has been released to ensure that there is nothing wrong or malicious with it, then you are essentially stuck without being able to safely use your device in the meantime.

Sometimes is better to wait and not use device for few day or week, then to download something potentially dangerous. In this case, users should check whether the upgrade is legitimate and how necessary / critical is it.

I can see where you are coming from, and in an ideal world there would be no issues whatsoever, but this is an unrealistic standard to hold. Bugs will always be discovered, and we can't really expect them to fix a bug they weren't informed about. This video was posted on the 27th and they had addressed it by the 28th. I think that's pretty good.

You're totally wrong, I do not come from such a world where bugs/exploit do not exist. My point here is that Ledger is completely relies on some other people (outside from company) which reveal security vulnerabilities in their products. You say that they should wait and do nothing, completely relying on their Bounty Program?

Video posted on 27 December and Ledger answered next day does not mean anything, it is just comment and not a solution, what is good in that?

[o_e_l_e_o]

My point here is that Ledger is completely relies on some other people (outside from company) which reveal security vulnerabilities in their products. You say that they should wait and do nothing, completely relying on their Bounty Program?

I never said they should wait and do nothing. They also do not solely rely on external sources, and as with Trezor, have a team who are constantly analyzing and improving their device's security. All I said was that there will always be bugs, and there will always be bugs which the developers miss and are found by third parties. There is a Bounty Program and an established method of responsible disclosure of potential bugs, which the security researchers in HeRetiK's video ignored, and as soon as the bug was revealed, they got to work on it.

it is just comment and not a solution, what is good in that?

I think it's worth repeating that while they installed a custom bootloader on the Ledger Nano, they haven't been able to gain access to the secure element and they haven't been able to extract private keys, PINs, seeds or funds. The bug is non-critical and they've stated it will be patched on their next firmware release. I don't think it requires an emergency firmware release to fix.

[elebit]

This video was posted on the 27th and they had addressed it by the 28th. I think that's pretty good.

That's far from the truth.

The presentation mainly focused on the original research, but the serious potential is in the earlier hack by Saleem Rashid which is clearly explained in the video.

Ledger have a Bounty Program (http://www.ledger.fr/bounty-program/) for people who find bugs,

What good is a bug bounty if it's only paid out for less serious issues? Rashid did not receive a cent, and the Ledger CEO called the hack "massive FUD" and has continuted to downplay the implications since.

they haven't been able to gain access to the secure element and they haven't been able to extract private keys, PINs, seeds or funds

The researchers specifically explained this in the presentation. There is no need to access the private keys since all communication (the display output and the key input) takes place through the application processor. A hacked firmware would just send a transcation to the secure element, skip displaying any message and then send the required keypress to the secure element.

[o_e_l_e_o]

There is no need to access the private keys since all communication (the display output and the key input) takes place through the application processor. A hacked firmware would just send a transcation to the secure element, skip displaying any message and then send the required keypress to the secure element.

Please do correct me if I'm wrong here, but my understanding was that they installed a custom bootloader only. When the Nano S is started in bootloader mode, the secure element does not allow access to it, and it doesn't even boot. To push a transaction to the secure element they would have to start the Nano S in standard mode, which would require the MCU check, which they did not demonstrate being able to bypass.

Again, Rashid did not follow Ledger's Bounty Program, which he himself admits, instead choosing to publicly publish his findings. You can't expect them to pay people who don't follow the requirements for payment.

[elebit]

When the Nano S is started in bootloader mode, the secure element does not allow access to it, and it doesn't even boot. To push a transaction to the secure element they would have to start the Nano S in standard mode, which would require the MCU check, which they did not demonstrate being able to bypass.

Why don't you watch the video? They have code running on the MCU. They explain the super secure magic value that the firmware checks against.

They also explain the communication between the main processor and the secure element.

Again, Rashid did not follow Ledger's Bounty Program, which he himself admits, instead choosing to publicly publish his findings. You can't expect them to pay people who don't follow the requirements for payment.

Not out of choice but because that wouldn't have allowed him to go public with the exploit.