Return to Video

35C3 - wallet.fail

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

more » « less
Video Language:
English
Duration:
01:01:58

English subtitles

Revisions Compare revisions