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 Comments

Add a Comment

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