Hardware Wallet Hack: Ledger Nano S – f00dbabe

The Ledger Nano S is a Cryptocurrency hardware
wallet based on a secure element for storing cryptocurrencies, embedding a screen to check
and secure digital payments. And also they have these information sheets
where they proudly write: “Did you notice? There is no anti-tampering sticker on this
box. A cryptographic mechanism checks the integrity
of your Ledger device’s internal software each time it is powered on.”… But…
ehm… hey…
stop… what are you doing? The Ledger Nano S is a small portable gaming
system. Currently there is only one game, SNAKE, but
we have also seen some promising tech demos. Just kidding. But just to answer your most pressing question
first I don’t want you to panic, if you use a ledger and you are just a non-technical
person, it’s not an attack where anybody can directly read out your private key. Maybe you shouldn’t plug in your Ledger
into an untrusted computer or leave it laying around, but even then it’s not like a full
critical private key compromise. So don’t worry. But reality is complex and there are situations
where your cryptocurrencies might be not perfectly safe. And what I will show you in this video, which
ledger says is not a vulnerability, might have some impact for you, or not. The real answer is of course a lot more complicated…. please define what a “vulnerability” is. You will see there are different ways to look
at it. But in my personal opinion, I think it is
very much a vulnerability. There is certainly a lot to unpack, and in
this video I just want to explain on a higher level how this “non”-vulnerability works. But I will make a series with more videos
where we discuss threat-models and go deep into the hardware and I show you on a very
technical level how to analyse, research and reverse-engineer the hardware and software
and how to setup a whole testing environment. But before you think highly of me, I didn’t
do anything. Don’t give me any credit. These videos are based on research done by
my friend Thomas Roth who discovered this in the first place. He contacted me if I would be up for making
a video about it and then helped me a lot by answering questions and helping me with
the setup. So if you are interested in his research and
professional work, make sure to look him up. And if you are interested in these upcoming
videos, make sure to follow this channel. So the “non”-vulnerability description
states: “It was found that the Ledger Nano S bootloader can be tricked into flashing
and executing untrusted firmware. The bootloader is used to update the firmware
of the ‘non-secure’ processor in the Ledger Nano S and has full control over the display,
USB and the buttons.” So when you put the device into the bootloader
mode, you can communicate with the ledger from your computer using APDU commands. This is a protocol typically used by smart
cards. So nothing special. But just as a little example, here you see
the Ledger Manager Software on my computer, and with the Chrome developer tools we can
observe APDU commands being logged to the console which is sent to the device and received
from the device. Okay. Writing software into the flash of a chip
typically involves using some special hardware to put the chip into a special mode to write
the code into flash. But that is not great when you want to be
able to update software later when the product is already shipped to customers. So typically software on a microcontroller
is split in two stages. The bootloader and the main program or firmware. And the bootloader is a small piece of code
that can help you with updates. It might also help initializing or configuring
some features of the chip when the device is powered on. But in our case we are just interesting about
the update process. If you just power on the device, the bootloader
will do some stuff and eventually jump to the main firmware code. But if you hold down the button when powering
it on, the bootloader will see the button is pressed and instead stay in the bootloader
code. And now the bootloader is executing a piece
of code where it can communicate with the computer and receive APDU commands via USB. Some of these commands can be used to update
the firmware, which basically means, writing new code into flash memory. And that process is pretty simple. an updater program on your computer like the
ledger manager *cough* or a malware *cough can use APDU commands first select a memory
segment on the chip then to send some data and write that to the flash. And so the bootloader has code to just simply
write new code into flash. And when you are done, you just tell the bootloader
via an APDU command to please now boot that code, which simply means, here please go execute
that. And from here on out, the device runs the
new firmware. Now you see, a person with physical access,
or a malware on your coputer, could write malicious code and push that onto the device,
right? Just put it into bootloader mode and send
the APDU commands to write the evil firmware. BUT, not so fast. Ledger tries to prevent that. The bootloader implements a boot protection. When powered on the bootloader will check
if the constant value 0xf00dbabe is stored at the address 0x08003000. Only if that value is present it will execute
your code. If not, the bootloader simply doesn’t do
anything. So in the bootloader code, where the APDU
commands for writing the new firmware is handled, it will first erase the old 0xf00dbabe value. If you would restart the device, the constant
would be missing and then doesn’t execute it. Now maybe you wonder why you can’t just
write f00dbabe to that address? The bootloader code also has a check to make
sure that YOU don’t just send an APDU command to write f00dbabe at this position. In fact it protects the whole range from 0x08000000
to 0x08003000. Which means you can also not overwrite the
bootloader’s own code which is stored in that area. So far so good. You send the APDU commands to write your malicious
code, the f00dbabe value is removed and when you try to restart the device, the bootloader
will refuse to jump to it. Darn. Now if you are ledger and you have a real
update firmware, then that firmware will come with some kind of signature. And when you are done writing your firmware
the bootloder can verify that your new firmware is genuine firmware from ledger, and then
it will write the f00dbabe value at the magic position, and the firmware is bootable again. But we are not ledger… so what can we do? Now we come to the awesome bug. Have look at the memory map here in the official
STM32 manual. From 0x08000000 0x08008000 the flash memory
is accessible. Or mapped. And in our case from 0x08000000 to 0x08003000
we have the bootloader area and at 0x08003000 we have the f00dbabe value. And with APDU commands you cannot write to
this area. BUT… look down here… depending on the
boot configuration you might have SRAM, System Memory or FLASH mapped from 0x00000000 to
0x00008000. And guess what the ledger has mapped down
here. This means, in code, when you are writing
to address 0x00003456 it is exactly the same as writing to 0x08003456. Both these virtual memory areas map to the
same physical flash memory. This means, we can bypass the check of not
being able to write to the bootloader area and we can write the 0xf00dbabe value to 0x00003000. This is then written to the real flash, and
when the bootloader checks if at address 0x08003000 is the magic 0xf00dbabe value it will find
it, and happily jump to the code. BOOM! You have your own code running. What does this mean now… let’s look at
a generic typical software wallet first. if your computer had a malware it could compromise
your wallet to send bitcoins to an evil address. But with a ledger it has to ask the ledger
to sign that transaction. So even if malware could fake what is displayed
on the screen of your laptop and fool you into thinking you send it to a trusted address,
with the ledger it would show you that you are about to send bitcoins to an different
address. But this display is controlled by the untrusted
chip, and we have just introduced an issue that would allow a malware on your computer
to write malicious code onto the ledger. So theoretically/maybe you might be able to
write code that also fakes the address that is displayed on the ledger and trick you into
accepting it. Oh or wait. The buttons are also connected to the untrusted
chip, so maybe you can just accept that transaction without the user even having to consent to
it. Just do it without the requirement of the
button. The untrusted chip does all that. BUT. I used the word “maybe” because it might
not be that simple. And maybe it might not be possible at all,
at least that is ledger’s position. But I’m sceptical, it feels all like it’s
standing on shaking ground and, maybe it’s not straight forward, but it feels iffy. And I know I know. PoC or GTFO. And I don’t have a proof of concept. Shame on me. But let’s go back to what Saleem Rashid
in March 2018 has criticised about the Dual-Chip Design. There he writes: “The Nano S has a second,
non-secure microcontroller which acts as a proxy for the Secure Element. This processor drives the display, buttons,
and USB interface. It interfaces with the Secure Element, which
stores the actual private keys.”. And he calls that inherently a architectural
vulnerability. The base hardware design of the ledger is
already flawed. So why is Saleem saying that, and why do I
believe he is right, and why do I think this f00dbabe issue is a problem. Let’s start with the secure element. In ledger’s own official development document
they write: “It is incredibly unlikely for the Device private key to become compromised,
because the Secure Element is designed to be a stronghold against such physical attacks. It is theoretically possible to extract the
private key, but only with great expense and time, so only an organization such as the
NSA could do it.” Which is pretty honest. Details about how the secure element protects
against advanced attacks are not known. And hardware attacks can be crazy. Like side channel attacks which we have shown
before on this channel, or using acid to open up the package, probing it with microscopic
tiny wires or using equipment like electronic micoscopes and focused ion beams to extract
single bits, is crazy. That’s why there is a layer of obscurity
and secrecy, not by ledger, but by STMicroelectronics that sells this chip. Without becoming a big customer and signing
non disclosure agreements you wont get any details. But that’s necessary because with enough
research, somebody like the NSA, or some other lab might be able to extract the private key
after all. But I’d say for most people, and count myself
to most people, the private key is really secure in the secure element, *cough* if you
trust ledger to never make a backdoored firmware for it *cough*. But the main design issue that is criticized
here is, that the MCU, the non-secure chip acts as a proxy. This chip is essentially a man in the middle. This chip has access to the Buttons, controls
the screen and communicates with your laptop via USB. And if you have control over USB, you could
make a BadUSB rubber ducky out of the Ledger, for example when somebody plugs it in, it
will send keystrokes to the host computer and do something bad. You know, I’m not super excited about rubber
duckies, I don’t think that’s such a scary attack, but if it’s for you, well the ledger
could be turned into one. The other thing about the non-trusted chip
acting as a proxy is something you know from using the internet. you know how dangerous man in the middle can
be. You have no clue who sits between you and
google. That’s why we use crypto, like SSL, to create
a trusted end to end connection that even if somebody sits in the middle, just eavesdropping
or capable of manipulating traffic, cannot steal your secrets. And this is actually what the Ledger does. In the developer documents you can find a
big section about the Secure Channel, also showing you in detail how the protocol works. And on top of that the secure element apparently
uses various techniques trying to verify that the untrusted chip is running genuine firmware
and otherwise refuses to work. So the fact that we can run our own code on
here, might not mean you can actually do much with it. Like doing wifi man in the middle with everybody
just using a VPN or SSL. And that is why ledger says, this is not a
vulnerability. And I at least can understand why they are
saying that. They clearly tried to design the protocol
in a way, that this chip doesn’t have to be trusted. But the fact is, this is not a secure chip. It proxies messages between the PC and the
secure element. And yeah I’m pretty confident that that
channel is cryptographically secure and malicious code maybe couldn’t really interfere with
it, BUT the chip is still responsible for showing critical information about cryptographic
operations and asking via button presses for consent from the user. Which both malicious code can take over. It’s not the secure element that displays
or responds to button clicks. And even though the secure element tries to
verify the firmware running on the non-trusted chip, it doesn’t magically make that chip
a secure chip. The secure element still relies on information
provided by the untrusted chip. And they are kind of relying on the fact that
the untrusted chip is limited in memory and speed, so it’s very difficult to write all
that code to spoof responses, basically emulating a genuine firmware to fool the secure element. But I think it’s just very difficult and
not a perfect protection, and thus I am confident that smarter people than me can come up with
a very creative way to pull it off. But I admit, there are many challenges and
it requires a looot of more time reverse engineering and researching. So maybe the bar is high enough, to make this
not economically feasible for a criminal or a researcher. It certainly is high that I don’t think
I can do it. But I’m also just a wannabe hacker. BUT, thomas had a very clever idea and created
a proof of concept. He created a firmware which is different from
the original one, as you can see and thus clearly not trusted. Yet this firmware will run once, and then
replaces itself with the genuine firmware, so future checks if it’s genuine will succeed. So while it’s not a full attack it’s a
first proof of concept into the direction of running some malicious code on there and
still have it succeed when tested the next time for being genuine firmware. I hope that was a good introduction and overview. So… if you want to learn more about hardware
security and how to do research on the ledger, or any kind of embedded hardware, then stay
tuned for more videos.

100 thoughts on “Hardware Wallet Hack: Ledger Nano S – f00dbabe”

  1. So why can't you just create a piece of malware that will update the firmware on the device to sign anything without confirmation and create a fraudulent transaction? Yes, you can't extract the keys, but why does it matter if you can just still all the coins?

  2. This Nano Ledgers are being sold as security model, and I never felt safe about this configuration. Is also sold as open source hardware but the secret chip is not, just the board designs and software.

  3. The video gives a great insight on how one of the most popular hardware wallets works and what are its weak points. This will make up for a great series! For the next one, would you consider talking about using Python scripts on Android and iOS (through Pythonista for example) to build basic tools that help pentest networks? (or serve other hacking purposes)

  4. But you said that the SecureChip checks the “proxy” memory and refuses to work when the firmware is not valid… so that means the “screen” and “button” are just unusable to make a automatic decision or show invalid data on the screen since there is no communication with the secure chip.

  5. How can you implement so much protection to write to a specific area of flash memory but then when someone finds a way to do it anyway claim it isen't a security vulnerability. It is like building a 5 meter high fence but not finding it a problem when someone climbs over it, it does not make any sense.

  6. Having written a few supposedly-secure bootloaders, the check at 5:35 should always be a whitelisting. Most microcontrollers have mirrors of the flash area, especially when they sell them fused-off to a smaller size for cheaper. You can also write evil bootloaders.
    Yes, this is slightly iffy. Once the evil code is loaded (by bootloader or swd), nothing prevents it from responding with the good hash, and since key load/generation-and-backup is visible to the mcu and not just the SE, see yesterday's CCC talk about leaking the private key through signatures:-)

  7. Well couldn't you just send the requests by the secure chip to the pc to handle them and then send the calculated results back to the untrusted chip to use as a response for the secure chip? That way you could avoid the firmware checks of the secure chip

  8. I should never take a break from watching your videos. They inspire me to take the initiative to stop playing video games and get hacking again. You're awesome!

  9. 7:10 By the way, the fact that the two locations are maped to the same physical memory on STM32 chips is basic knowledge. I hope the company took actions against those who made such a mistake

  10. As a fairly ok hardware engineer, I feel like I could just unsolder the STM32 and solder one in with my custom bootloader/flash content, or? Maybe even one with a bigger flash size/same package , so I could be able to handle all the communication on the untrusted side, bypassing the crypto element completely? (The latter sounds way too optimistic to work)

  11. Bs, how someone could have even overlooked it? I mean using off shelf microcontroller is bad enough but leaving just a huge holes to exploit is also bad
    This thing should have had a custom chip all sealed woth epoxy or some nasty shit that makes physical attacks even harder and software attacks next to impossible due to the hardware beeing unknown

  12. so one of the oldest tricks in the digital book works on it?
    Well that is not good. Ledger just made it harder to pull off that trick.

  13. Good video. As idea for new video – bay a cheap Chinese drone (like Eachine e58). They all make open wifi network and have camera, so interesting here is what can be done with this open wifi networks>

  14. I don't see how reverse engineering the secure chip <-> client protocol, , malware on the PC and malware on the unsecured chip is ever not enough to steal the wallet funds, the secure chip cannot know it does not speak with the real client and the confirmation button can be pressed by the evil firmware. Without the firmware vulnerability there is still the confirmation mechanism to defend the wallet. Therefore the code execution is definitely a major issue.
    Also, if it's not an issue like Ledger says than why go into the trouble of protecting the bootchain? Obviously they are improvising at this point

  15. hey can u tell me how can i download any and every book every written from textbooks to self help to fiction from normal web and deep web??????

  16. It's so clear when you explain it. But the question afterwards is, HOW you found the bug, how you got attention to it and how long Thomas needed to find it..

  17. How does the code for your Firmware look like? Im really interested in that. Especially if you have no 'imaginary structure' of the firmware, how tf you can implement sth. like this?

  18. I still fail to see how this is an issue? Ledger implement attestation checks using public private keys that check the MCU??

  19. Here's a video idea I want to see covered by you, and I have pretty high hopes that you're probably going to do it anyways.

    I want to see a video about GDB and defeating anti-debugging techniques, I have a crackme I've been working on and I get for the most part how it works, but I can't get too far into it because there's a trigger that once hit, force closes the program. And I am not sure what causes that.

  20. My two cents on this are even if it the address was spoofed, it would just be the display, displaying the wrong value. To be able to change data, it would have to access the secure non-volatile storage (or flash) to be able to actually modify the data that was already stored on the device.

    If it was a new "hacked" one to the consumer, then it still wouldn't match as the verification using the ledger app would be incorrect, as it wouldn't match.

    Theoretically, the user would (or moreover should) notice this, and not execute transactions.

    It's like changing the Windows boot animation on Windows, it's not doing anything fancy, it's not bypassing bitlocker or anything, it's just in essence a change of files, no real code changes.

  21. I don't buy the reason to not provide ST31 documentation. It's just a security through obscurity. I bet bad guys will obtain that documentation through some way even if it involves signing NDA.

  22. What the fuck?, im doing here? i didn't even understand what u saying, i only know that is a vault for ur bitcoin etc.

  23. I don't quite understand at 6:55, the sentence: "You might have SRAM, system memory, Flash mapped from 0x000000 to 0x00008000". Why is it being mapped?

  24. The first thing this made me thing of was boot locked samsung galaxy s7's, the ones with the snapdragon chipset.

    I wonder if a similar exploit can be used? But i'm probably just showing how much i don't know about hardware.

  25. That's why in modern consoles the boot process is handled by a bootrom… You can't read it "easily" and certainly you can't modify it…

  26. Great work! I wonder why the secure element does not check if the firmware is signed, like it happens with drivers on operating systems like Windows? Is it because they are not able to update/revoke the key if it ever gets compromised and the devise would be useless?

  27. As you said the new firmware can control the screen (@2:47) it was enough for me to have a scenario to abuse the owner of a borrowed key. So, for the users of this dongle, don't enter boot-loader mode and update the code.

  28. So, give the the idiot's version please: is this rubbish or not? Which hardware wallet would you recommend? Thanks in advance, "The idiot"…

  29. No need for anti-tampering stickers on the box, because the device has secure software? What's preventing an evil tamperer from replacing the entire device with an evil clone that looks ldentical?

  30. By the time someone steal your ledger and try hack it, you have enough time to use seed phrase and move funds with another wallet. To extract data key from chip with advanced micro engineering and using your idea how NSA can break into it if they have access to the company that build chip, it takes a lot of time. Plus, one mistake can erase chip's memory. It is really hard to hack the device itself, but yes you can trick public key to be changed on the computer that you use it with ledger. So, if you are not visually confirm address on the screen of ledger, you might send funds to a wrong spoofed address public key.

  31. If there is a Malware on your computer that is NOT Ledger's fault! If someone physically gets your Ledger, that is NOT Ledger's fault!

  32. I have a doubt. I need a genuine answer .If i buy a ledger nano s not from official website and find out that is used and then I reset the device and use as a new device with new recovery phrase then can anybody access my coin ?

  33. Please don't forget to securely store your recovery seed by engraving it in titanium! Check out the CRYPTOTAG at cryptotag.io

  34. Came back to this video today to ask your thoughts on the cobo ledger: cobo.com
    Biggest drawback for me would be it's size. And the fact that i'm still unsure of the point of having one.

  35. basically buy your Ledger Nano S from the official site, and also verify the address after every transaction. Don't constantly access your Ledger Nano S, instead write down the public keys for your coins and just send them to these addresses without constantly loading Ledger Live to get the address, less exposure to the internet.

Leave a Reply

Your email address will not be published. Required fields are marked *