*35C3 preroll music*
Herald angel: Welcome everybody to our next Talk. It's the talk “Wallet.fail”.
As you all know, when you have something valuable you put it somewhere safe. But as
we as hackers also know there is no place that is really safe and our three speakers
Thomas, Dmitry and Josh are now going to demonstrate in the next hour the art of
completely breaking something apart. So please give a big round of applause for
Thomas, Dmitry and Josh and have a lot of fun.
*Applause*
Dmitry: So just just to start, I'm curious how many people here actually own
cryptocurrency. Raise your hand. And how many of you store it on a hardware wallet?
So we're very sorry to everyone who has their hand up. OK. So it's not just me.
It's me, Josh and Thomas. So we're all hardware people. We do low level hardware
stuff in varying degrees and we got into cryptocurrency and so I can recommend to
everyone sitting in this room if you're a security person. There's not a lot of
people doing security and cryptocurrency as much as that's painful to hear. So yeah
I mean a lot of this is based on reverse engineering. We love cryptocurrency.
I mean for us crypto also stands for cryptography not just crypto currency, but
no offense to anyone with this talk. It's just something that it's a category that
we looked at. And so the results kind of speak for themselves. And again this
wouldn't be possible alone. So we have a lot of people to thank. I'm not going to
go through all of them individually. Just be knowing that we're thankful to everyone
on this, on the slide. So yes, so we started this about six months ago. So we
wanted to take a look at cryptocurrency because we own some cryptocurrency
ourselves and we saw that everyone's using cryptocurrency wallets. It's more and more
the thing that you do. So we started a group chat as you do nowadays. And we have
50000 messages now and 1100 images. And I had my first, I had my son in the meantime
as well. So it's a really long time that we been looking at this, etc.
*Applause*
OK, so what do we want to achieve though? Because people don't give
the kinds of attacks so you can actually perform against
cryptocurrency wallets enough credit. So first attack is supply chain attacks
where you are able to manipulate the devices before they get
to the end customer. Firmware vulnerabilities, where you find a
vulnerability in the firmware and can somehow either infect or do something else
with the device. Side-channel attacks of course. I think that's one of the more
obvious ones that people are familiar with. And also chip-level vulnerabilities.
So we were able to find one of each of these. And so that's the talk that we're
going to talk about each one of these individually. But first, what's a wallet?
Just in case you are not 100 percent familiar with them. So a wallet, and in
general cryptocurrency how do you do this, it's just asymmetric cryptography. So you
have a private key and a public key. The public key, basically, it gives you the
address. You can derive the address from this. The address is nothing other than
the public key of the wallet and you have the private key and you need this to send
transactions, so to actually operate with the cryptocurrency. So this, the private
key, is what needs to be kept secret. The public key is something that everyone can
know so that they can send cryptocurrency to you. But it kind of sucks to have a
separate for each cryptocurrency-pair or for each wallet maybe even multiple
wallets. It sucks to generate a new cryptographic pair for each one of them.
So the people, the wonderful people, behind bitcoin have thought of something
for this and it's called BIP32/BIP44. And, so, what it is is you have a cryptographic
seed and you can actually derive the accounts from a single seed. So you
basically store one seed and you're able to implement and do unlimited amount of
wallets. Okay. So basically you do key derivation, you add some data, do key
derivation and you can have an unlimited amount of wallets while storing a single
seed. And this is what you're using when you're using a hardware wallet. So and of
course for each key derivation there will be a new private key and a public key, but
it will be generated in a predictable manner and you only need a store one
secret seed. So you only have to store the seed. You can write it down, and that's
the advantage. But it's difficult to write down because it's binary data. So come
BIP39, which is what you're most used to, which is a format in which you can take
that cryptographic seed, that binary data, and actually convert it to a set of
dictionary words that you can then easily write down on a piece of paper and store
it at your mother's house, or store half of it at your mother's house and half of
it at your grandmother's house. And that way somebody would have to go into both
houses simultaneously to get your words. So yeah. So what's a hardware wallet?
So we just talked about what's a wallet. So why do you even need a hardware wallet?
Well, the problem is, of course, computers can get backdoored, have malware running
on them and this is what you want to pre- vent against. How do you do this? You have
a secure device, you store your seeds externally. Usually, this is a USB-
connected device that you store your crypto on and so you can trust this even
if you can't trust your computer. This is the idea. So what happens is the computer
sends the transaction to the device. The device gets the transaction, it can
actually confirm or deny the transaction. It also displays the transaction. So
before you do any cryptographic signing, you can see is that actually what I was
doing or was my computer owned and is it initiating the transaction for me? So you
sign the transaction and also, yeah, the seed never leaves the transaction, but the
hardware signs a transaction for you. You send it back to the computer and the
computer can actually take that and send it to the Internet. OK? So that's a quick
rundown of how crypto or, sorry, how hardware wallets work. So the first thing
that we looked at was supply chain attacks which is where Josh gonna pick up. You
have a mic. Oh sorry. Josh: Ok, so the three big things I want
to leave you with as we go through the supply chain attacks are, stickers for
laptops, they are not for security. So we're going to be talking about stickers
today. They're there for laptop decorations, they are not for security.
Supply chain attacks are easy to perform, but they're quite hard to perform at
scale. And the last takeaway that I will leave you with is that, the vendor's
threat model may not actually be your threat model. So security stickers, some
of the wallet vendors are using them. I have seen them on other products, they
seem to be quite popular. I have a friend and colleague named Joe Fitzpatrick, he
also likes stickers. So the stickers that he makes are the same as we find on his
security product. They have holograms. They have unique serial numbers. And they
leave you with that nice warm fuzzy security feeling. Joe makes some funny
ones. You can get a Fitz 140-2 approved stickers. You don't have to pay the money
for the FIPS one, just get the Fitz one. So the first device I looked at was the
Trezor One. The Trezor One actually has two levels of protection on the packaging.
There's the hologram sticker than the actual box is enclosed with an adhesive.
So it's supposed to be that you actually have to rip open the box to get into it.
But if you use a hot air gun or a hairdryer it's actually quite easy to
remove. And so if you see on the left there that's the original package and on
the right this is a box that I opened and put everything back into. And if you look
closely there is a little bit of gap there. The sticker has a little bit of
break but this was the first try. And it's pretty close. So trust me taking a sticker
off is not very hard. Now if you remember this picture of the sticker cause we're
going to come back to it. So but for the vendor this is actually a real problem so
Trezor did put a blog post out that one of the challenges they face is that they're
facing counterfeiting of their devices. So this is from their blog post. They say hey
you know we've noticed that there's counterfeit devices. You have to look at
the stickers to see that they are legit. So I said remember look at that sticker.
So I bought that case about a year and a half ago for my previous DevCon talk and
it's the same sticker that they're saying is fake here. So then on their wiki it's
very confusing because there's three sets of stickers so basically, yeah, stickers
are very confusing. They cause problems for end users. And I was not even sure if
I bought a real Trezor or a cloned one. So this morning I got out a new case. And
just to make sure I took off the sticker using very sophisticated equipment
including a very expensive Dyson hairdryer that was included in the AirBnB and I was
able to remove the sticker. So it comes off
with zero residue. So yes stickers do not provide any security. On the Trezor T
they switched it from the box and now the box can be opened easily. But now there's
a sticker on the USB-C port. Again as you would expect use hot air and you can
easily remove it. Pro tip: don't set the hot air rework that high I had it set for
lead free reworking and I actually melted the enclosure. So if you're going to do
this kind of supply chain attack, maybe, no, set the heat a little lower but if you
just google how to remove stickers the same attack methods work. So this causes
a bit of confusion because the ledger device has a very, I will say, in your
face a piece of paper when you open the box it says there are no stickers in this
box. However I combed through about 250 1-star Amazon reviews and a lot of them
have to do with confusion about the stickers. So some of them are actually
quite funny. So this this one started out "Note to wallet hackers", so I was really
into this. So I was like, OK, pro tip what's this guy have to say? And basically
he was complaining that there's fingerprints on the device. That's how he
knew it was hacked. Another one complained that the fingerprints were on the wallet
and there was a hair underneath. So if you're doing supply chain attacks be sure
to remove any evidence of your fingerprints or hair. So anyway stickers
don't work. That's all I want to say about that. Once you get through this enclosure
though you then have to have the challenge of actually opening the enclosure. These
are three different wallet devices: Ledger Nano on the left, the Trezor One and the
Trezor T on the bottom all of which actually open pretty easily. So the Trezor
One, even, so, I'm still not sure if that's the counterfeit or the real one,
but I get on the on the real one today. I was able to pop open enclosure. So it is
ultra sonically welded but you can pry it in there and open it. The Ledger Nano
opens very easily, like, without any equipment. But once you do this, you know
what do you do once it's opened? So the attack basically is you take the
microcontroller and you rework it. So you remove the microcontroller from the
printed circuit board and you put on a new one that you bought from a distributor.
Once you've done that on the Trezor devices you can put your compromised
bootloader on there. So this is, I did not go as far to make the compromised
bootloader, but I did confirm that once I switched the microcontroller, I could
connect with a debugger over SWD and I have free access to the chip. So some of
the parts got blown off when I was reworking but the SDM works fine. So yeah.
So you just rework, reflash and then you put everything back together. So next I
want to talk about hardware implants. So you may remember the story that came out
there was this big hack by Bloomberg about hardware implants. I wanted to make a
hardware implant. I also wanted to have a little bit of fun with this. So, we, in
honor of the Bloomberg story which has some, you may have some issues with it.
We're about to talk about the BloomBurglar which is a super micro fun implant. So the
goals for this implant is I wanted this implant to happen after receipt. So it is
both a supply chain attack and a physical one like a red team can perform this. A
malicious insider could also perform this attack. Zero firmware, because more fun.
It has to fit inside of a hardware wallet, so it has to be small it has to also
bypass the core security function, otherwise it's not an implant. Very few
components. I have a thousand of them with me. So I wanted to be able to offer Makers
and DIYers to participate in the hardware implant fun. So what kind of implant did I
end up with. Well, I decided to do a basically, an RF-triggered switch and so
the idea is on these devices there's a button and the button is the last line of
defense. So all the vendors assume that the host is going to be compromised. They
just assume that's going to be easy because that's software. And so once you
have a compromised host you have to send it to the device and then the human -- so
humans are still needed -- humans have to look at it and say "Is this the right
transaction or not?" They have to say yes or no. So now with this implant I can,
through RF, I can trigger the yes button. So a human is not required to send
transactions, I can remotely trigger it. Basically the RF comes in through the
antenna it goes through a single transistor which is the main component and
it pulls the button low. And I'm sorry to say that the bill of materials is quite
expensive at three dollars and 16 cents. Two dollars and 61 cents of that is this
potentiometer I had to use. So it is a little bit expensive. I'm sorry. Also, why
is this so big. I mean this is an American Dime I can fit two on them. What's the
deal. Why is it so big. Well I optimized it for hand assembly. So it would be, you
know, more fun to use, but basically you put the antenna in and then there's an out
button and, like I said, I have a thousand with me. So just for scale. This is how it
fits on the Ledger Nano. This is how it fits on the Trezor. It is also because
breadboard-friendly is a thing. So we made it breadboard-friendly. So you can also
play along very easily at home. So then the last challenge with an RF implant is
how do you design antenna to fit in there. And so the big thing there with an
SMA connector is the first prototype I did. Experimented with a few antenna
designs but that remember it, it all has to fit inside the Ledger. So that's
actually quite easy because a Ledger Nano has a plenty of room to insert extra
circuitry and so it quite fits easily in the Ledger Nano. And then I did the
implant and then I started to go through the wallet process. I got to a
check that said is might, you know, is the Ledger device genuine. And here I actually
got a little bit nervous because it wasn't working, and so it wasn't working. I was
like, maybe they were checking this, you know how did they detect it. Don't worry,
it's only Linux. So it just doesn't work on Linux. So that was no problem. I did it
on windows and no problems. The device was genuine, I was able to move on. So the
thing is, this is a very crude receiver, but the attacker can always use more
power. So here I have this is my antenna setup in the basement, and with a 50W
transmitter I can remotely trigger the button at 11 meters, and at this point I'm
just limited by my basement size. I'm pretty very confident that I'd be able to
remotely trigger this thing further. Yeah. So here we're going to see a demo of what
it looks like and for the other problem you have with hardware implants is how do
you know you have the implanted device. So you have to label it some way. Ledger has
this kind of Latin phrase that scrolls " I wanted my own Latin phrase" And so this is
how I know this is my implanted device. So what we're going to see is that the
transaction screens is gonna show up. This is, and I'm basically going to trigger
this remotely, so I'm going to show that radio come in and then it's going to
approve the transaction without any hands. So this is the transaction. There is the
screen going. This is the way it supposed to verify. There's the radio coming in at
433 MHz and then it's going to proceed to the next screen without me touching the
button. There you go. So this is remotely triggered, and that would have sent
transactions. So if you think about the context that you have a malicious software
implant that sent it to a wrong address, the attacker now can remotely accept that
and bypass the security module. *Applause*
So, yeah, on the recaps, stickers are for laptops, not for security. Supply chain
attacks are very easy to do at a hardware level, but they're quite hard to do at
scale. And when the vendor says the device is genuine, that may mean different
things. Thomas: to segue to the next part, so six
months ago, Josh Datko said something that I found kind of funny and it's almost
correct: "If you put funny constants in your code, they will end up on DEFCON
slides, and they won't be laughing with you." Small mistake, they won't end up at
DEF CON, they will be at CCC. and so introducing the fOOdbabe vulnerability,
it's a bootloader vulnerability in a Ledger Nano S. We did not come up with
this constant. It's literally in the code as we'll see later. So the name was not
ours, but we like it. So we also bought the domain foodba.be.
*Laughter* Ledger Nano S is a very simple wallet. It
simply has a small display, it has a USB port and two buttons. That's really all
there is. And you should take it apart. You see it's just some pieces of plastic,
the display and the PCB. And looking at the PCB, it kind of has an interesting
architecture where you have a STM32, which is just a general purpose microcontroller,
and a ST31, which is a secret element that is for example used in pay-TV and so on.
And is regarded as a very high security chip, basically. And if you turn the PCB
around, you'll see that they were nice enough to leave the programming port for
the STM32 open to us, ENABLED. *Laughter*
And this has been suspected by other people that we verified it. But you know,
you have to go through it. And obviously Ledger is aware of this. And so let's look
at the security model that the Ledger Nano S has. The basic idea is that if we look
at this device, we kind of have this schematic of the STM32 being on the left
and the ST31 on the right. And as you can see, all peripherals are connected to the
STM32. That is because the ST31 does not have enough pins to connect peripherals.
It literally only has a one pin interface, which is for the smartcard protocols
basically. And so all the heavy lifting is done by the STM32. And Ledger splits it up
into the unsecure part and the secure part. And the idea is that the STM32 acts
as a proxy. So it's basically the hardware driver for the button, for the display,
for the USB, similar to a northbridge in your standard computer. And when you take
a computer and want to make a transaction, you create your transaction on the
computer, it goes through USB to the STM32, and the STM32 then forwards it to
the ST31. THe ST31 then says, Oh, a new transaction, I want trust the user to
confirm it. So it sends a display command to the STM32 which in turn displays that
on the screen. And then you press the "yes" button again it goes the same route
to the ST31, which then internally signs the transaction. So the seed never leaves
the device and our assigned transaction goes back through the STM, through USB to
the computer. To us, this means if this chip is compromised, we can send malicious
transactions to the ST31 and confirm them ourselves. Or we can even go and show a
different transaction on the screen than we are actually sending to the ST31. And
Ledger is aware of this and we'll talk about how they try to mitigate this later.
But first we have to find an exploit, because while we do have debugging access
to the chip, hardware access is sometimes kind of buggy. No offence. So we wanted to
have a software bug. And so we started reverse engineering the firmware upgrade
process. And when you look at the bootloader, the bootloader for the Ledger
used to be open-source, and back then they didn't have any verification of the
firmware. So you could basically boot the device into bootloader mode, flash
whatever from where you want, and then it would run it. After someone, Saleem in
this case, wrote about this, they changed it, and they changed it to do some
cryptographic measure. And we were too lazy to reverse engineer the cryptographic
measure because it's very time consuming, very hard. So we looked more at the parts
surrounding it and how we can maybe find a bug in the bootloader to break it. And it
turns out that when you try to upgrade your Ledger, you accept four different
commands. One is select segment, which allows you to select the address base at
which you're firmware will be flashed. One is the load command, which allows you to
write data to flash. Then you have the flush command, which is basically like
f-sync on Linux and writes your changes to the non-volatile memory. And you have the
boot command, which verifies the flash code and starts booting it. So to us the
boot command is the most interesting, because it provides all verification and
it attempts to ensure that no malicious image is booted. And it turns out that if
you issue the boot command, it compares the whole image to whatever
cryptographically function they use, and if it's successfully verified, they write
a constant to the address 0x0800 3000, and that constant is OxF00DBABE. And so, to
not have to verify the entire flash on each boot, they just do this once, so only
after firmware upgrade. So basically if you boot up the ledger, it boots, it waits
500 milliseconds. It checks if you have a button pressed. If yes, it goes to
bootloader. Otherwise it loads the constant at 0x08003000. And if it's
0xF00DBABE, it boots the firmware. So our goal is to write a 0xF00DBABE to that
address. First attempt, we just issue a select segment command to exactly that
address. We just write 0xF00DBABE to it, flush and reset the device. Didn't work
unfortunately. so we had to do more reverse engineering. It turns out that
they use an interesting approach to ensure that you don't accidentally flash over the
bootloader. So they basically blacklist a whole memory region. So if you try to
flash from 0x0800_0000 up to 0x0800_3000. It returns an error. If you try to
directly write to F00DBABE, They thought about it, and they have a very specific
code path to prevent that. So they memset it to zero and you're screwed again. And
then finally it writes assuming you didn't error out. But it turns out that the STM32
has kind of an interesting memory map and on a lot of chips, you cannot only map
your flash to one address, but you can also have it mapped to another address.
And in this case the flash is indeed also mapped to the address 0. And so the
bootloader uses a blacklisting approach, so it only excludes certain memory areas.
But it doesn't use whitelisting where you could only explicitly write to this memory
region. So they do not block writing to 0x0000_0000. Profit! Second attempt. We
just select the segment at 0x0000_3000, which maps to 0x0800_3000, we write
0xF00DBABE to it, we flush, reset, and we can flash custom firmware! Awesome!
*Applause* So what do you do when you have a device
that, where the display is not big enough to run DOM with a custom firmware. So in
this case it's an original letter, press the button, put it into bootloader mode,
which is part of the normal operation, and *Laughtes and Applause*
If you want to play a bit of snake, come by later. How are they protecting against
this? I've mentioned before Ledger is aware that you can reflash this STM32. And
they are, they put in some measures to prevent you from doing malicious stuff.
And basically what they do and this is very simplified, and we did not bother to
fully reverse engineer because we didn't need to, basically. When the chip boots,
it sends its entire firmware to the ST31, which then performs some kind of hashing
also, verifies that the firmware as authentic. And it also measures the time
it takes to send the firmware. This is to prevent you from just running a
compression algorithm on the STM32 and send it very slowly. How do we bypass
this? So our idea was, because we not only have flash, we also have RAM. So what if
we create a compromised and compressed firmware that copies itself to RAM? We
jump to it and then it writes its entire compressed firmware to flash,
uncompressed in that case, and then we just call the original code on the secure
element. It would verify the firmware, it would run with a real timing and boots up
regularly. And so we attempted this. It took quite a while to achieve.
Because basically, you can't do ZIP, you can't do LZMA, because even if you
compress the image you don't have enough space for complex compressor. So our
attempt was to find duplicate bytes, squeeze them together and make space for a
custom payload. And basically we just have a table that says, okay, now you will have
six zeros or something. And our each table entry only takes a single byte. So, and
it's only like 10 instructions in assembler to run this decompressor, so you
don't have the large code base. It's very easy to use. And it turns out that even
with a very simple detector, like in this case we rerun the script to find the
longest duplicate data, and you can see on the first try, we get like 260 bytes of
space for our payload, which is enough for a lot of things, let's say. And we have a
working PoC of concept of this and we would go into a lot of details, but if we
only got an hour. And so we will release after this talk and on non-offensive
example of this that you can look at how does it work, what can you do even if
you're firmware is attempting to be verified. And we also and this is very
exciting we are working with the YouTube LiveOverflow and he created a 20 minute
video on walking through this entire F00DBABE vulnerability, how did the
verification works and how to bypass it to a certain degree. We don't want to
weaponize it. So we did not, we will not release the first the full thing, but
yeah, very excited for this. Stay tuned on our Twitter and we'll link it for sure. As
part of this, we also have a lot of software that we will release. So public
release, we'll release the snake firmware. So hopefully this evening you'll be able
to play snake on your Ledger. If you bought some bitcoin at twenty thousand now
you're bankrupt, you can at least play snake. We will opensource the compressor
and the extractor. We built a logic analyzer plugin for this markup protocol
and we built software that analyzes the communication between the STM32 and the
ST31 on the Ledger specific data, and you can just dump it. So if you guys are
interested in for example trying to break into the ST31, please have a go. And
Ledger has a second device, which is called the Ledger Blue. We assume the
reason it's called the Ledger Blue is because it contains Bluetooth. But they
never enable Bluetooth. So it's basically just a regular Ledger with a color display
and a big battery in it. And we call this part "Fantastic Signals and how to find
them". *Laughter*
Because when we opened up this device and we were chatting, we have this nice
telegram chat room where we're chatting 24/7 while doing this. And we opened up
the device and the first thing,like literally five minutes after opening it, I
saw that you have the secure element on the left and the STM32 on the right. You
have some other stuff like the Bluetooth module and so on. The trace between the
secure element and the microcontroller is pretty long and contains a pretty fast
signal. So what is a long conductor with a fast changing current? Anyone got a clue?
*Interjection* Correct. It's an antenna.
So I pulled out my HackRF software defined radio, this
is just a very, a more sophisticated RTL- SDR, so you can just sniff arbitrary
signals with it. I got a random shitty telescope antenna on Amazon and they have
my Ledger blue. So on this screen, you can see the blue thing is the radio spectrum
around 169 MHz and if we start entering our pin we can see that there's a weak
signal. *Laughter*
You guys see where this is going. On the radio. Unfortunately that signal is pretty
weak. Luckily they included an antenna. They call it a USB cable, but I'm not so
sure about it. So this time with USB connected, and we do the same thing again.
You can see like crazy radio spikes and this is right next to each other. But even
if you go a couple of meters. I was limited as Josh by my living room space.
You get a couple of meters of decent reception. So our goal was to find out
what is this signal and if we just look at the recorded amplitude of the signal, we
get this. And if you do a lot of probing and so on, you immediately see, ok, there
are spikes and there are 11 of them and then there's a pause and then are small
spikes. So this is probably some kind of protocol that first sends 11 bytes of data
then pauses, and then sends more data. So we looked at the back of the device,
started probing every single connection and tried to figure out is this the secure
element? Is this whatever? And it turned out to be the display bus. So we can sniff
information on what is sent to the display remotely. And if you, if we look at the
signal that gets sent in blue, it's the signal that gets sent when you press the
letter zero on the pin pad and an orange when you press the letter seven. So we can
see a very clear difference at certain points on the signal which confirmed our
suspicion. But building software for this is kind of boring, like digital signal
processing is not really my thing. So what do we do? And we wanted to increase the
buzzword load in our talk a bit. And so we are hacking blockchain IoT devices, using
artificial intelligence, in the cloud. *Applause and Laughter*
So our ideal was we record training signals, we use some kind of prefiltering,
we train AI on it. Profit! Literally. Problem is, getting training data really
sucks, because you don't want to sit there for 10 hours pressing the same key on a
pin pad. It really doesn't sound like fun. And so this needs automation. So,
*Laughter* So we took in Arduino, we took a roll of
masking tape, a piece of acrylic glass, a PCB vice and this is a HUAWEI-pen for the
extra amount of Chinese backdoor. And we let this run for a couple of hours. And
you can actually see that every time it presses down, you can see that the digit
that you pressed is highlighted and the difference in the signal we saw earlier is
probably the x and y coordinate, of where it highlights the button. And that's the
difference. We can see in the trace. And so we had a lot of recorded data. Now we
created a training set. We created a test set, preprocessing Tensorflow ai model.
It's really easy surprisingly. And we tried our test set did a prediction. And
so the big question how accurate is it. And it turns out. So this is the the
result of a cut of the test set. And if we zoom in on this this basically tells you
we have the signal of this great thing it's just a picture representation of the
signal and it tells you how sure it is, what digit it is. In this case it's 7 with
98 percent likelihood. So pretty good. In our test set we only have one wrong result
and overall we get it wrong 90 percent accuracy and to move this in the cloud we
are hosting this on the Google cloud. As the LedgerAI for you guys to play with and
we'll publish it online with a limited dataset that is trained on a very close
space. You cannot do something super malicious with it but it's nice to play
around and see how this was done. And this brings us to the next part, glitch me if
you can. Thank you. *Applause*
Josh: So now we're going to talk about the silicon level vulnerability with glitching
attacks fault injectio so to review. So to review I will be talking about the
trezor one. And so I just want to go over very quickly what the architecture is of
the trezor one and some previous work that is done. So the Trezor One is quite a
simple embedded device. It consists of only a few components. It has an OLED
display it has some buttons and has a USB connector that are all externally facing.
Internally it has its main brain if you will the STM32F205 microcontroller which
controls all the other operations on the Trezor, that display, the USB, and the two
buttons. So last year we gave a talk at DEFCON "Breaking Bitcoin Hardware Wallets"
here we use the chip whisper to mainly do the glitching attacks, the conclusions
from last year is that the F2O5 was vulnerable to fault injection but it was
inconclusive if we could do a exploit via the fault. So this year we have a
different result but the output of that work was this board was
called the breaking bitcoin board.
Basically it was a Trezor clone that just made it easy to attach wires and probes
and so we made this board. The design schematics are all online. It's open
source hardware. This is the chip whisperer set up that we were using so we
made the board specifically to fit on the chip whisperer target board. And this is
just what it looks like when you use the chip whisper GUI to perform a glitch. And
here we were doing application level code so it's very different but I gave that
talk and then I met Dmitry and Thomas. Dmitry: Fortunately we had Josh to do the
talk last year and to kind of exhaust a lot of the firmware vulnerabilities that
were actually hardware vulnerabilities in the firmware that might have been there.
So we immediately knew that we could exclude this. And so you can start looking
at the underlying microcontrollers. So in this case it's STM32 microcontroller that
they use inside of it and it controls everything. So compromising the STM32
microcontroller means that you can compromise, you can compromise the device.
So I mean so there's a couple of papers that have covered some of the
vulnerabilities in the STM32 specifically there's one which describes a UV attack
which lets you downgrade the security on the STM32. So we determined that paper
unfortunately does not apply to our result because the Trezor or is smart enough when
it boot's to check the value stored in Flash. And if it has been altered in any
way to set it correctly. So they actually even protect against this kind of attack.
But nevertheless you can see that there is some vulnerabilities. So there is another
paper which unfortunately has not been published yet and we couldn't get in touch
with the authors yet. That should be coming out in January hopefully which
describes glitches against the STM32 F1 and STM32 F3. So now we have the F0, the
F1, and the F3 and so basically here's the product matrix. So three of them are
already vulnerable. So what we're looking at SDM 32 F2 and potentially STM32 F4 if
we're talking about the Trezor model T so those we do not have vulnerabilities for
yet. So let's take a look at how how it works really quickly. So the way that STM
implements security on the STM32 is that they store an option byte and the option
byte the thing to remember is on on a cortex M3 or M4 microcontroller that you
don't have anything other than flash. So even though they call it option buy or
refer you to this is fusing or being permanent and hardware. It's still stored
and flash just like the user application is stored in flash. So it's the same exact
same non-volatile memory that's otherwise used. So basically when you get a new SDM
32 it's shipped in a state where you have full access. So that's how Josh was able
to rework abord and flash it with new firmware. And there is the ultimate
security is what's called RDP2. So there you have no access but you can see that
basically if you have a value other than aa or cc which correspond to RDP0 and RDP2
respectively then you have what's called RDP1 and this is interesting because it
doesn't give you access to the flash which is actually where the cryptographic seed
is stored on the Trezor but it gives you access to RAM, it gives you access to the
registers but it doesn't give you flash access like I said and it doesn't give you
single stepping as well so connecting a debugger and this mode will actually cause
the hardware to hard fault which we'll see in the second. So basically what we want
to try to do is to downgrade RDP2 which is what the trezor is set to. And we want
to be able to access the device at RDP1 which is somewhat vulnerable state. This
so I should say that this is this is the correct way to approach this and it's
great for doing an educational talk. But in all honesty there's three of us. And so
we did this completely in the dark over a over 3 months trying different
parameters on our on our glitch setups which also later and were able to find
this. But I'm here to explain it to all of you so that it's easy to reproduce. So if
you actually watch the SDM 30F2 boot you'll see that it's relatively slow and
it's only this slow after you power cycle the board. So it takes approximately
1.8 milliseconds to boot which is a microcontroller terms pretty slow so you
can see there's the power supply there's the IO pin and that's approximately how
long it takes to boot the firmware so you can see that's where the IO actually
toggles so 120 milliseconds later. So we just wrote some firmware to basically
toggle one of the pins measured within an oscilloscope. Now we have the timing of
how long that takes. So that's not super interesting because that's not really a
trigger. And each one of these microcontrollers internally it has a boot
rom so it has some some rom read only memory. It's not non-volatile memory it's
not the flash. It's literally a rom which is inside the chip itself. It's it's hard
coded. It cannot be fixed or patched that gets executed first. So we wanted to
actually attack that because anything else is the user application and that's what
Josh did last year. So you can kind of start to fiddle this down. So you see that
1.4 milliseconds of the reboot nothing actually happens because this is
now the reset line. And so the reset line goes high after 1.4 millisecond
so you can ignore the first 1.4 milliseconds after you
cycle the power. So now the next step that you can actually do is you can connect
what's called a shunt resistor. So oscilloscopes are there to measure
voltage and so you want to actually measure current to be able to know how
much power is being consumed by the device. So you do what's called
a shunt measurement and that's what I have on this slide right here.
So you have the blue signal is now actually the power consumption. And so now
you can actually look and see what's happening. So the first thing that happens
is we have the execution of the BootROM. You can see in the power consumption curve
you can clearly see this moment in time. Then you have basically where the flash
and option bytes actually get read somewhat at least within the BootROM. And
finally the third distinctive moment in time is where the application actually
begins to execute. So now we've taken this 1.8 milliseconds which is a
relatively long time and reduced it to 200 microseconds. We're actually interested
in. And not only that we know that we're actually interested in having slightly
higher power consumption than the normal execution of the bootloader or the BootROM
rather and this is somewhere between let's say 170 microseconds and 200
microseconds. So this is the time at which we actually need to glitch and this is
also reasonable parameters. If you're trying to reproduce this at home. So what
do you need to reproduce this thing. So I. The greatest thing that came out in the
last couple of years is the these cheap Chinese power supplies where you take a
cheap you know old wall wart from one of your old Linksys routers you plug it in
and then you actually have a controllable power supply with with voltage and current
and you can adjust this and control this. And so that's what we're using here. The
second thing that I have to actually
control the timing is an FPGA. I mean I use FPGA's for everything and this is
something that was easiest to put together with an FPGA because FPGAs have constant
timing. So finally we have a multiplexer there as well and the multiplexers are
actually switching between two voltages between ground so completely cutting the
voltage off and the normal operating voltage of the microcontroller. And
finally we have a debugger, the J-link which is highly advised if you want to
ever do Jtag stuff. So it's just a Jtag debugger and basically what happens is
you let this run for a while and it looks like this. It's not really super eventful
so you can see that the voltage the yellow signal is actually the voltage and you can
see we're just dipping the voltage at different points in time and
simultaneously we have a python script checking if we have Jtag access or not.
Protip to all the new dads if you do this at home you can turn your oscilloscope
towards the door, so that when you get up at night because the baby's crying, you
can see if it's still running or not. So it's very, it's highly advised. So now
Thomas is going to tell us how to get the seed into into RAM.
Thomas: So we had this thing running for 3 months roughly across 3
continents because Josh is in America, Dmitry is in Russia and I'm in Germany and
so it took us 3 months to get a successful glitch and even then we didn't
believe it at first because we exhausted everything basically. And the only reason
we finally got it working is that we did a mistake where we misstook 70 ms with
170 ms and had it run for a long time. And that's how we found out that the BootROM
is actually super slow to boot on this device. And once we had this downgrade
from RDP2 to RDP1, we were able to read the RAM, but we cannot read the flash
which actually contains the seed. And so how do we find this? And our idea was we
start reviewing the upgrade procedure because on the Trezor, the way the
bootloader works is, it doesn't require a PIN or anything to upgrade the firmware,
which makes sense, because let's say you have a bug in the pin function you want to
somehow be able to get rid of it, right? And the other thing is if you flash a
fully valid firmware it retains the data, it retains your seed. if you flash and not
genuine one. It actually will erase your seed and so on. And the big, and they do a
really good job on the firmware verification. We reviewed it for days and
days and days and didn't find anything. But so how does this upgrade procedure
work? how is this seat retained? And so when you reviewed the relevant code you
see that there is a call to backup metadata which sounds like it's going to
retain somehow your data. And indeed you can see that it's literally a mem-copy
from the data on flash we're interested into RAM. And so our basic procedure
was, we go into bootloader we start the firmware upgrade and we stop it before the
RAM gets cleared. Because if you finish the upgrade procedure, the Trezor actually
clears its memory again, which is a very decent way to do it. But we've found a way
to retain it in RAM. So it turns out that when you start the firmware upgrade
process, it eventually asks you to verify to check some of what you just flashed and
it turns out that at this point in time, the seed is still in RAM and we can read
it out via RDP2. And this is relatively simple to do once you actually manage to
glitch the device. You basically just run openocd dump_image, you get an image of
the SRAM and you have the whole RAM contents and so.
Dmitry: What are we going to do,Thomas? What high tech hacking tool will be using
today to extract the seed? Thomas:So we actually before we were
successful, we had hours of talks on the how do we, how is this seed stored and so
on. But we've found this super sophisticated seed extraction tool that
only runs on POSIX and POSIX-like systems, it's called strings.
*Laughter* And so basically it turns out that when
you have a firmware dump as we have RAM dump as we do now, and we go to we just
run strings on the dump. We get a couple of really nice words and I don't know if
you remember the intro, but this is your seeds.
*Applause* And you might be wondering what this
little number is. This is your pin to the device.
*Laughters* That was a great day. And so Josh, or one
of Josh's employees took all this mess we created on all desks and made it into this
nice device which is basically a socket where you put in your chip and then we can
read out the seed and so on. Dmitry: And all of this stuff including
the board design, FPGA codes, and the Verilog code that we use, I mean if
somebody wants to, they can apply it and do the same thing with one of the ICEPICKs
or one of the more open source friendly FPGA boards. This just happens to be the
one that we all had lying around and could reproduce the work with. You can go ahead
and do it. I mean we suspect, I think Thomas said, we suspect you might be able
to do with Arduino as well, because the actual glitch pulse is only approximately
60 μs or sorry, 6 μs in time. So it's a relatively slow signal as well, so it
should be relatively repeatable even with something cheaper than this. But this is a
way to automate this even better and to not have dangling wires or any of the
small soldering that was required to do it in situ in the device which we had on the
previous slide. So all of that we're going to have it on GIthub. And so I think the
final, the final thing. Thomas: one more thing before we are,
sorry. One more thing. So this breaks a lot of the Trezor security, but there is
a way to protect your seed against this, So if you use a passphrase on your device,
the way we understood it, it basically doesn't allows somebody with hardware
access to steal all your funds. So if you add a passphrase to your Trezor, a good
passphrase and your machine is not already owned you can somehow somewhat protect
against this. But a lot of people don't. So we are really sorry we didn't mean any
harm. Dmitry: So yeah, that's the conclusion I
would say. So yeah I mean, so all the stuff we're going to put online, I guess I
said, so you can follow us for the links on the online. wallet.fail, it's a domain
name, believe it or not, fail is a TLD. So you can go to github.com/walletfail,
twitter.com/walletfail. You can follow me, Thomas, and Josh on Twitter as well and
like I said, we'll be releasing all this stuff so it will go up slowly. Just
because I think when we set out six months ago we did not expect us to have 100
percent success in everything that we were planning to do. so that's a first for me
at the very least. Thomas: The saddest part is that we have
more vulnerabilities to other wallets, but, only one hour. And so we also have
some stuff to give out so we have the hardware implant PCBs, we have thousands
of them if you want to get some. Dmitry: Off to Josh.
Thomas: We even have components for them for like 100 devices so hit us up and we
can do something. Thank you.
*Applause*
Herald: Thank you guys, it's an amazing talk. I feel really inspired to break
things apart in a very creative way. We have some time left for questions. So if
you have questions, please line up at the microphones. But first we're going to
start with a question from the Internet.
Signal Angel: Thank you, I've got two related
questions from the internet. First one, how hard did you guys laugh when bitify
announced that their Android-based wallet was unhackable? And second question, have
you had a try to attack larger processors like ARM-based processors?
Thomas: So maybe let's start with Bitfi. So we only talk about somewhat secure
wallets, we didn't want to use a Chinese phone in this talk. So we laughed pretty
hard and we ordered some, but yeah. Dmitry: And I mean this was covered
extensively. So another guy who you should follow on Twitter @cybergibbons gave a
talk at hardwear.io on the topic of the Bitfi. He was summarizing research that
he did in conjunction with a bunch of other people as well. So if you're
interested in the Bitfi you should go look at them.
So the second question was about ARM-based
controllers. I mean all of these were ARM-based. Every single chip as far as I
know that we looked at was was ARM-based in one way or another.
Thomas: Yeah and there's,
so if you're interested in this, look at glitching the Nintendo Switch where they
glitch the Tegra used in the Nintendo Switch, which is very interesting and will
give a lot of inspiration in that regard, basically.
Herald: Thank you. A question for microphone 4 please.
Mic 4: Hi, Trezor CPO here, first thank you for the talk, we worked with you to
fix the issues as soon as are recommend to prod and if anyone interested in hacking
hardware wallets, we are really interested in working with the hardware hackers
community and we have a responsible disclosure program.
you mentioned problems with supply chain attacks, but gave no solutions, so let me
give you one. Trezor is open source hardware so you can build your own
from locally sourced components
and if you are paranoid and don't want to deal with these kind of attacks.
but my question is, is there any other solution except for building
your own wallet or inspecting the code to run and
interrogate about basically?
Thomas: First Thank you. One thing we should mention is that when we looked at
the Trezor code, the reason we had to end up glitching this chip for three months is
that we couldn't break the firmware otherwise. So they do a great job. And
it's really awesome. *Applause*
Dmitry: Yes. The firmware on the Trezor is something to look at. I mean I recommend
that, I mean we all do consulting work as well. And so it's something that I
recommend that people who are interested in looking at how to prevent certain doom
mitigations and hardware. It's an excellent project to look at. And so
Trezor should be commended on that. But at the end of the day it doesn't mean that
the chip that the Trezor uses is secure against these kinds of attacks. And that's
where we had a fallback to looking for silicon vulnerabilities against a chip
or, sorry, a wallet like the Trezor.
Josh: I would say on this hygeine side,
this is a very difficult problem, governments especially have this issue.
You can do cryptographic attestation, but as we saw with the Ledger nano,
that cryptographic attestation didn't help verify that the requests were legitimate
against a hardware attack, so there's been talk about X-raying the board and all this
stuff, but this is still very much an open problem in hardware security.
Herald: Another question from microphone 3.
Mic: Actually I have a suggestion. Herald: Make it short, though. Because
usually we just take questions. One sentence.
Mic: A few MCUs actually have Jtag connected via hardware fuses.
So this might be useful
at least slow down glitching attacks. Dmitry: Thanks. I agree. But these are
not Cortex-M microcontrollers I can tell you that with 100% certainty. It has to do
a lot with the fact that the microcontrollers that are being used in
these devices, they're built to spec to the spec that ARM specified that ARM
thinks would be a good set of features for this class of device or rather for the for
the CPUs for the class of device that they ended up getting put in. So anything
Cortex-M is gonna to have vulnerabilities that are more or less like the silicon
vulnerabilities that we have. It's just I mean if you ask me I think it's a matter
of time just to sit there. I mean fortunately we had something like 3 months
of just glitching to be able to find find these bugs. But if you can apply that much
to find it silicon attack you might be able to find this kind of vulnerability as
well in other Cortex-M products. Only three minutes.
Herald: All good. Another question from microphone 4 please.
Mic 4: So obviously as part of your work you analyzed the firmware of these
devices. Did you find that the firmware is in any way obfuscated or encrypted?
Thomas: So basically yep, on these chips you cannot really encrypt the firmware. On
the ST31 you can encrypt it. But we didn't have to look at it because the ST31 is not
something you have to break but so no there was no real obfuscation that we
could see. But we also don't have the code in the case of letters so I just stared at
IDA pro for hours and yeah. Herald: The next person on microphone 4.
Mic 4: Hello, did you have a look at the entropy chip that generates the master
seeds on both of these hardware devices, and what's your take on that?
Dmitry: I mean, so we already hovered how the Trezor works. There is only one chip
and it's the STM32 so I know that there was a known issue with Trezor back in the
day where they weren't seeding the basically the RNG correctly. But this was
fixed. But for our attacks this wasn't this wasn't an issue. I mean if you were
concerned about how strong these are, how strong the random number generators are
for creating a seed you could actually create a BIP39 wallet outside of any
one of these and then just use them for their hardware features and get the seed
from outside. Herald: And if you have a question, do
move to the microphone if you're able to. But first we have another question from
the Internet. SA: Thank you. Did you guys see the
dinosaur hiphop zero wallet? Thomas: No but if you send it to us
we are happy to look at it. Thomas: Oh you did.
Dmitry: Yeah, we had the it Josh: The dinosaur hiphop wallet -
Thank you for the kind of trick questions - So the design of the dinosaur hiphop
wallet was a trezor clone that we looked at last year.
Thomas: Ah Josh: Called breaking bitcoin board
so that if we didn't, otherwise functionally it's a trezor clone
but we stole a lot of the instructions from dinosaur hiphop
make the breaking bitcoin board and then prepare the operating system.
Dmitry: I mean, and maybe on that note I would say that in terms of looking at
what wallets are actually be used you'll find that, so the Ledger is a very popular
wallet, the Trezor is a very popular
wallet. But since the Trezor is opensource there is a lot of clones and forks of the
Trezor. And when I say that not all of them run the latest security patches that
have been applied to the Trezor code base. So that's also something that you can do
is basically diff the projects and see which one of them which ones are staying
up to date and which aren't.
Herald: Your question has to be the very last one today.
Please speak directly into the microphone. Even closer to the mic.
Mic: Seeing as this is the first CCC for many of us and some of us might not have
that much experience in hardware hacking. Do you have any tips for beginners?
Thomas: Yeah lots of them. Buy an Arduino learn what mistakes you do with it and
learn how hardware works, basically. Watch a lot of online videos and I think you
gave presentations, you gave presentations. I gave some presentations.
So just watch talks, watch LiveOverflow. LiveOverflow, great YouTube channel on
exactly this stuff. And also don't hesitate to reach out to us. If you have a
question. Always contact us info@wallet.fail, on Twitter, wherever. we
are happy to talk to you. It might take a while.
Josh: On non-security electronics, if you go to Sparkfun or Adafruit, they have lots
of free material of how electronics work, how to get started. It's not security
related, but it's a very good electronics program
Dmitry: But I'll say I started with Arduino too.
Herald: All right thank you guys so much for the very nice questions and you guys
for the amazing and inspiring talk. Thank you so much.
*Applause*
Subtitles created by c3subtitles.de in the years 2018-2020. Join, and help us!