Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/397 Thanks!
All right, thank you, General Hudson, and
I really like to take things apart, so in
this talk, I'm going to be talking about
Thunder Strike, which is a SFI
firmware rootkit for Apple MacBook.
And the talk is going to have
a few parts. The first half is going to
be about the sort of the journey
of reverse engineering, the EFI boot
rom in the MacBook.
The second half is going to be about
developing the Thunder strike
vulnerability and then
the third half is going to be that
mitigation strategies.
What can we do to prevent it that
hopefully are better than EPOXI in
the ports shut?
So reverse engineering is a hobby
of mine.
One of my more famous projects is the
magic lantern firmware for the Canon
Cameras. It's a old runtime
that lets you write your own software.
I also thank
you.
I also really enjoy retro computing and
digging through old computers and in the
ROMs to see what sort of Easter eggs
there are, such as this Mac
that contains a four photos
of the team that worked on it back in
the mid 80s.
And I'd really like to thank my firm, Two
Sigma Investments.
It's a high tech hedge fund in New York
City that has encouraged
me to do this research and to publish
it. I'd especially like to thank my
colleagues, Thor, Simon, Victor
Tacony and Larry Rudolph for their
assistance in preparing this for
publication.
You might ask, why is a hedge fund
interested in this sort of vulnerability?
And it really comes down to security
that we care about the security of our
data and of our systems.
And we'd heard about some some
attacks on Mac books and we were thinking
about deploying them.
So I was asked to use my reverse
engineering skills to look into
some of these attacks.
So I started by going through and reading
and watching conference presentations,
and there's an enormous amount of
marvelous presentations, in fact, a lot
by people who are even
here today, that that helped
teach me about how systems boot
and how to protect
the boot process.
Although most of them are looking at the
the Intel and Windows side of things,
the secure boot path.
And comparatively few are looking
at Apple's
boot time security or things like
Thunderbolt security.
The Snares Black
Hat presentation in 2012 was one
that actually started me on this project.
So with most reverse engineering
projects, the first thing that you need
to do is get into the system to get
a feel for what's there.
Apple uses these little screws
to make it a little bit more difficult
to get in.
I did it the old fashioned way, made a
bit of a mess.
But you can also buy screwdrivers
for a few dollars or a few euros.
So once you get inside, Apple has done
a beautiful job on the esthetics of this
machine, despite the fact that they make
it so hard to get into.
They've they've really paid a lot of
attention to the esthetics and the
layout.
Usually what happens with malware is
it comes in over the Wi-Fi or the
Ethernet gets a buffer overflow
into into RAM, get some code
running on the CPU that eventually
writes something to the to
the hard drive.
What this talk about, though, is the boot
from now, which is this chip over here.
If we zoom into it, we can read out
the part number, the two five
six four zero six,
and we can look up the data sheet.
It's a sixty four megabit, eight
megabyte serial flash
and we call it a boot rom.
But it's really an easy problem with
flash memory in it.
S.P.I means that it has
data in, data out and
external clock that's controlled
by external hardware.
You put a lot of other researchers
have done is used the the bus pirate,
which is a off the shelf logic
analyzer tool, and
it comes to these test clips so you can
easily hook it up.
The problem is that the bus pirates kind
of slow. It takes a couple hours to to
read and write the ROM and it's very
fiddly.
Since I do a lot of work with ROMs, I've
actually built a
a spy flash reader
based on a teensy, which is kind of like
nor do we know the sources are
GPL and you can download them and
have at it.
This one can read the wrong in a few
seconds and write it in about a minute.
One word of caution.
If you're doing reverse engineering of
this, disconnect the battery before you
hook up the external programmer.
Otherwise there you'll have conflicting
voltages on the rails.
And as the voice of experience,
that's not a good thing.
So
two years ago, when Snare was doing his
work, he found that if he changed
the ram at all, the machine wouldn't
boot. And he conjectured
that there's something checking a
signature on the boot room.
And that made me very curious.
You know, what is doing that check?
So I repeated his his
work and I made a one by change to
somewhere in the room.
And the result is
pretty much a bricked machine, that
there's no lights, no sound,
no sign of any life at all from
the outside.
But since we have the bottom
off, we can flip it over and we can look
at the inside.
And when we power it up,
the fans spin up the
CPU cooling fans and then a few seconds
later they spin down.
And that indicates that something
is check in the room.
It could be an external piece of
hardware, which is a lot of folks have
conjectured or it might just be something
in the boot room itself,
which, of course, we just
to question what is doing that
if it is only software,
we could perhaps
bypass that check
in. The easiest way to figure that out
would be to change the first instruction
they could run and find
out what that is.
We go back to the late 70s,
early 80s for the
80, because when you're modern, actually
664 starts up it boots in
real mode and reads the
first instruction from
what at the time was the top of physical
memory at one megabyte and
then does a jump somewhere elsewhere
in memory to finish the initialization
using the bus pirate or the flash from
Tooele or my S.P.I Flash Reader.
We can disassemble that part of the
ROM and we find that
indeed it starts the cache invalidate
that's actually new, but it has
a jump lower in memory
to finish the initialization.
What if we changed the address that that
jumps to? So rather than jumping
off to there, it just creates an infinite
loop and will
just spin there when
we flash using the system programmer,
when we flash this into the room,
there are two possibilities that could
happen.
The fans might spin up and then spin
down again, which would mean that
there is something outside that's
actually check in that room
or the fans might just keep spinning
continuously, which would indicate
that that is only a software check.
I'm up here today, so there's probably
not too much of a surprise as to what
happens. But yes, the fans stay
on. So this gives us
one bit of output before the rest
of the system has started that we now
know a way to signal
what's going on.
And this infinite loop is a very common
reverse engineering technique.
You can drop it somewhere in the code.
And if the system hangs, that means that
your code is running.
But this also means that there
is no external hardware.
Apple used to have a TPM on their
motherboard, but they they actually
removed it because
they weren't using it at the time.
So there's a quick recap.
We now we can now
reprogram the RAM with the
system, Pergament Hardware, and we know
that there's no external hardware that's
actually checking the ROM validity,
but something is checking the
validity and we need to find
that piece of code.
So to figure out how
the RAM is organized, we can go to
Intel's F.I.
specification for their
firmware volume and
it has this field labeled signature,
which sounds perhaps likely,
except it's literally just the
four characters underscore Fage.
There's this checksum, but it only
covers the header.
And the other interesting thing
in this section is the zero vector,
which isn't really defined
what it's used for.
So we'll come back to that
if we do a hex dump and there will be
some hex dumps in this presentation.
If we do have some of the the top segment
of the ROM, basically the last sixty four
kilobytes we can spot that
underscore for signature pretty easily.
And there's the sixteen bit checksum
here covering these
hex forty eight bytes of header
and the zero vector we can see is not
zero, it contains something
this first eight bytes for always the
same in every firmware volume in
the ROM.
But these last eight bytes varied between
each of the firmware volumes.
And that that's interesting,
the way to
try to figure out where things are in the
room, we can use a tool like strings.
And what's interesting is this from image
actually doesn't have very many strings,
but we can find things like
that for signature.
And then a few bytes later, this really
tantalizing string that says rom
integrity.
So let's fire up our interactive
dissembler.
I'm using Hopper in this case
on that section of the ROM
and apologized a little small.
The slides will be available if you
actually want to dig through it later.
We can see that it does a comparison
of that signature there.
And then there's this chunk of code here
that computes some stuff with the
length and then it does something with
the offset eight into the zero
vector at the start of that
Fermor volume.
One thing Hopper can do is give
a pseudocode that we can then massage
into something that looks kind of like
see, and what
we can see is that it's calling
a function on the
data part of the the
firmware volume, storing the result in
that in that address.
And then it compares it to
that part of the zero vector.
So this this function is
clearly involved in somehow and check
in on on that validity.
Using Hopper, we can interactively step
into the into that
function and we find that it does
a bunch of stuff in a loop reading over
the bytes of data, but
also accesses this table
32 bits at a time.
As Rudolf suggested
two days ago, when you run into
these random hex values,
toss them into a search engine and
you never know what you're going to find
in this case.
There's that constanten.
There's the next five constants.
So a lot of our
reverse engineering is done.
We now can probably guess
this function is 60, 32,
and in fact, we can now
make a one by change to the firmware,
manually compute that CSC 32,
reflash it with the insistent programmer
and it now works.
So we have a new bullet point that
there's only about time.
Seriously, 32 to check of of
the ROM. This is not a cryptographic
check. This is only to
ensure that the RAM is not accidentally
been corrupted or that
somehow it has been programed.
So simply by regenerating
that CRC, you can you can change
the ROM.
You might ask why isn't there a
cryptographic check?
Other researchers have looked into this
and come to the conclusion
that the flash
ROMs are only checked
when they're being updated.
And once it's written, it's never checked
again.
One possible reason for that is
for speed to have a fast reboot time,
but doing the CRC requires
reading through the whole ROM anyway, so
it's not like you're going to save that
much time.
The real reason is that malicious
software can just skip the checks that if
you can write to the ROM, you can just
change that, whatever the function is,
and to always return true, or
it can return a pre computed hash
value.
So without any sort of cryptographic
hardware to help out the software, only
attempt is doomed to failure.
Earlier I mentioned that there weren't a
lot of strings in the ROM image
and all eight megabytes, very
little of it had any actual human
readable strings.
Most of that was up here in the early
boot code and there are two copies.
I don't fully understand why
this is a graph of the entropy of
the ROM you generate
with a beanstalk, which is a really great
free software tool.
The zero entropy regions are free
space. They're all FS and the rest
of the room is very high entropy,
which could be encrypted or compressed.
So when we have
to figure out what part of the room to
look at, we can decode
the flash descriptor region of
the ROM and Flash from what
tells us that the BIOS is
the latter part of it from one nine
zero zero zero zero and until
the end.
So let's let's look at what's stored
at the start of that byas region again.
We can go back to our Hexton
and it looks like a firmware
firmware image,
assuming a firmware image file
section.
So we've got three bytes for
the length. About 15 K for this section,
the next fight is the section
type in type one is
a compressed section which matches well
with with what we thought.
So we then turn to the
compression section documentation
and we see the next four bites
are going to be the uncompressed length,
about thirty six case.
We've got a little better than two, two
to one.
The next fight then is the compression
type and they've got type two,
which is not defined in
the specification.
So that's a bit
of a problem.
But I did notice, though, is that these
next four bytes in all
of the firmware sections were the same.
What do we do when we see something like
that tossed into the search engine
and we get a perfect hit for
LACMA at compression
level, negative seven.
So to verify this,
we can use a tool like DD
to extract the
compressed bytes, skipping
that nine byte section header,
filtering it through Elzy CAD,
which will decompress it if it's a valid
LACMA format and
no complaints from multi-cap.
That's that's great.
The file sizes match up with what we
saw in the header
and there are now human readable
strings.
These are just absolute golden
if you're doing reverse engineering
especially. Printf strange, there's a
percent zero percent zero
s and what not.
Those are what tell you how
things are happening inside the code.
So once you have that sort of thing,
it's very, very easy to start figuring
out what else is going on.
So we now know how
the Fermor volumes are compressed.
It's type two.
We can flashmob could with the system
programmer after recompression.
I'm not the first person to figure this
out. I'm quite certainly not the first
person, but I've never seen anyone else
write it down. So I wanted to make sure
that this is now out.
There were other people can can start
working with these firmware volumes.
Thank you.
So why can't we write to the boot,
the boot from flash, from software?
Why do we still have to use this hardware
programmer?
It turns out that the Flash is not
directly connected to the CPU, that
in the flash over here is actually
connected to the platform controller
hub and access to it is
mediated by things like the management
engine.
When the system Boutte's the
the UniFi Forum
recommends that all of these
regions be locked as quickly as possible.
This is done via registers like
lockdown down that
control, access to the configuration,
the read write access, and they
can only be cleared during a hardware
reset.
So this means that
once the system is booted, you can't
write to to those parts
of the room.
But we know that Apple updates
the firmware that they pretty
regularly ship EFI
and EMC firmware updates that that write
new code into this ROM
and it has a really nice GUI that will
make sure it's the right version for your
system and whatnot.
But under the covers, it's using a
tool, a command line tool called Bless
that takes
the ESCAP file that is stored
in the image that you download and
copies it to the EFI system partition
and then sets a EFI
in VRAM variable so that the next
time the system Boutte's, it sees that
variable and does what's called a
recovery mode boot.
So the account files another
undocumented blob that
we need to figure out what's actually in
it. What are they, what are they doing in
there.
So hex dumps are
spent too much of my life staring at hex
dumps and it's kind of a
good way to to get accustomed to what's
going on in the machine.
We can easily spot the file
volume signature there, but it's
not at the start of the file.
It's actually offset by about 50
bytes. And we see that there's a 50 byte
value among all those zeros
based on the firmware volume
specification. We know that that's the
size of the volume.
And we see there's a similar value
elsewhere in the header, which actually
matches the size of the total
file.
One thing that you encounter a lot, if
you do F.I.
Firmware reverse engineering is
that there are these 16 byte
guides, which
they can be frustrating, but they're also
marvelous search engine
targets.
So when we toss that in
into whatever search engine, we get a
perfect head on yet another
SFI specification document.
And as expected, here's the header size,
here's the image size and
the rest of the fields are all zero.
But one thing that that we notice there
is that the there's an extra
two hundred and twenty hex bytes at the
end of the file.
So let's look at that
again, hex dump in it.
And it's all high entropy.
There's nothing, there's nothing human
readable. It's just random values.
Well, on the off chance that this might
be another goed, what do
we do?
We search for it.
We get one hit and
it's a mailing list post from
just a couple of months ago.
I wish I had actually found this much,
much longer ago.
And it's describing a RSA twenty
forty eight shot six
signing and gives us a structure
that's two hundred and ten hex
bytes. So this matches very closely
to the trailer that we're seeing.
So this is a pretty good idea of
what's going on there.
So
my next step would be let's let's
try to check that and
Supergirl program.
I realized Perl may be worse than
assembly for some people, but it's
handy.
So it reads in the the cat file
and extracts out the firmware volume
and then the RSA public key and the
signature based on that that structure
that we found in that mailing list post.
It then uses the default RSA
exponent since there's not one stored
in there.
And I really need to give huge thanks
to my colleague Victor de Coveny,
who suggested swapping the byte
order to put it into a big
Indian.
And once we've done that, we built the
RSA key.
We verify the signature
and it's OK.
So we now know
how Apple is signing their firmware
updates, which.
Not only do we know how they're being
signed, but we know
that the blessed tool doesn't check
the signature, that something in
the boot process that does it.
And as a word of warning, if you bless
an invalid file,
plus will happily copy to the partitions
that the variable and you will break your
machine, you will have to do a full in
system programing
reflash of the ram to to clear that.
So but,
you know, where are the signatures being
checked?
We know somewhere in that update process,
but it could be hardware.
Again, the management engineer
or the assembly perhaps could be helping
out or might just be software.
So if we do a binary grep
for those, there's two that we just
found.
We find one file in the
uncompressed forum that matches
and it actually matches all three
of them.
So if we look at the bit of code that
that works with them, we find that it
does the the Jewed compares
as we'd expect it checks the file
size along with that HEX 220
byte trailer.
And it also then references
this G. UID, which is the DC
services table,
which becomes very interesting.
If we step a little bit further in the
code to what refers to the table,
we find that it passes the
firmware volume,
the contents of the firmware volume
through a function pointer at Offset Hex
ninety eight in the services
table.
To find out where that is, we go back
to the specification and they don't give
us offsets. But we can count eight bytes
at a time because we're we're in long
mode here and we find that that it's
calling process firmware, a volume
that takes the RAM copy
of the the firmware volume
and essentially mounts it and makes
it available to other
functions in the firmware.
If that succeeds, it then calls another
function. It offset Hex 80
and this is dispatch,
which will execute any code that was
in the firmware volume that was just
mounted.
So simply a little messy.
Let's translate that to some pseudocode
we see it. Does the the
grid check
it? Does the RSA
check on the shot two, three, six.
It then calls process for more volume
and dispatch
and that then
jumps into the flasher that's in the
in the ESCAP file.
So we can now,
because of what we've learned already, we
know how to make modifications to the ROM
to find out how to try things
out. So one question
that I had is, is this
this RSA check the only place that is
done or is something in the management
engine or some of their hardware also
doing it? So I
just commented out, I can just
put jumps around that so it doesn't get
executed.
And then I can generate a
bogus ESCAP file.
Now here's the trailer on it with the
the usual guides and whatnot,
but that is pretty clearly
not a valid RSA signature
in the file.
So if I bless this camp
and the machine breaks, that
means that some piece of hardware is also
checking it.
But if the
system accepts this has kept file and
updates the firmware with its contents,
and that means that it is just software.
Once again, I'm up here giving this
presentation, so you
probably guess what happens.
The firmware gets updated,
which again is pretty
fascinating. This means that
there isn't the firmware
signatures are only being verified by
software. There is no hardware
involved.
So next question is,
can we could we
do this sort of change without
internal access to the system right now
to make these changes, we have to open
the machine and to the RAAM.
And based on the work that Schnorrer
did with the Thunderbolt port, I thought
we might be able to.
So Thunderbolt brings the
internal Pybus to the outside
world. And when the system
starts up, it it enumerates
all the devices on the bus and it asks
if they have any option ROMs that
should be executed.
Option rooms are a legacy feature that
literally goes back to the very first
IBM PC with that
Intel 80 80.
The virus was typically a mask
or you've from and there were these
six sockets where you
could put in optional ROMs that would
have things like basic and device
drivers for four other things.
And the NASA expansion bus
cars could also carry their own ROMs
that would then become available
for the BIOS.
So that's what we're talking about.
A legacy feature going back thirty five
years here.
Using it as an attack vector is not a
particularly new idea.
John Heasman at Blackhead in 2007
showed how to put a attack
factor onto an expansion card
and snares work on
the was pretty damn awesome.
He built a gigabit Ethernet
Thunderbolt adapter that could
could Back-Door the Austin kernel
and that was done in 2012
that Flor's actually still in Mac
books.
So if you put
one of these Thunderbolt adapters with
a with the option
rom exploit on it and beat the system.
This is one that I built that
will capture your
fireball password.
I have since changed it to a password,
one which is much more secure.
So the problem is that
option rooms can't write to
the Flash because
they are loaded in the dark
phase of the boot, but the
flash is locked during the P.I.
phase.
However, except
during boot rom firmware updates, in
which case the flash is not locked.
And we saw that the the
flash the
flash code is running in sixty four bit
mode, which means the firmware update
program is now also running in the dark
phase along with the option ROMs,
which leads me to question our option
ROMs also loaded during
those firmware updates
and the way that I wanted to figure that
out, I could go through and do a bunch of
reverse engineering and walking through
code and stuff, but that's too much work.
So I go back to the infinite loop trick
and I built an auction room that
just doesn't infinite loop
that the I firmware is
single threaded.
So this will basically lock up the
machine.
So now if I connect the
Thunderbolt device with that infinite
loop option rom and
power on the machine after Blessin and
ASKAP file,
if it goes into the firmware update, that
means that the option rooms are not
loaded during a recovery mode boot.
But if the fans just spin
and the machine appears to be bricked,
then that means that the option rooms are
being loaded and executed.
So.
You guys know what the answer is, yes,
option arms are loaded during the
recovery mode boot.
However, there's a minor roadblock that
there is a
32 bit murd signature check of
the cap file before the option
gets executed.
So is there a way that we could
bypass that check?
If we go back to that pseudocode for
the the flasher verification,
remember that process for volume
is being called via a function pointer
that Cinram not in Romme.
So the option
could replace that that function
pointer in a process called Hook In.
So we can modify
the option right now to
hook the process, firmware volume
function pointer and replace it with its
own and also then stores the old one
so that it can reuse it later.
If you have a sufficiently large option,
Ram, you just put your whole firmware
exploit in there and and
it's game over.
However, the one that we're
using, the gigabit Ethernet
adapter, only has about thirty two
K of space available and so we can't put
a full eight mag rom image in there.
But what we came up with is actually even
more interesting that we
can instead
put in an RSA public key that we
control and
the process from our volume function
will search through the firmware volume
looking for Apple's public key.
If it finds it, it MWM copies
it.
Our public key over it,
then fixes up the CRC 32
since we now know how to do that.
And then it calls the old process for
more volume on this now modified
image.
And
when we so
when we now get the machine with
again with the Thunderbolt device, with
what we're called the Thunder Strike
exploit, because all cool exploits have
have names these days.
So when we put up the machine,
the here's the exploit code
running in the recovery mode
boot and we're not worried about
stealthiness is proof of concept.
And now here is Apple's own firmware
update routine, flashing
our option rom with our
RSA key into the boot rom on
the motherboard.
And once that's done,
we now own the system and we can flash
whatever we want using Apple's own update
tools.
So.
So all exploits also get logos and I
think theme songs and websites now,
so we now know
how to circumvent flash security
with the option rooms.
And because we've replaced the
key, this boot camp be
removed without
through software alone because we control
the key that the firmware is going to
use, that there's no
official channel that that can
remove it.
So how would something like thunder
strike if it were to be weaponized
actually be deployed?
One option is something like
what the NSA is doing, where they
intercept shipments of hardware and
make modifications,
as they're seen here doing to Cisco
routers.
The other ones, the evil made attack
that folks hypothesize in which
you're at a conference, say, in Hamburg
and you go down to the hotel
to get some breakfast in room service
comes in and they they make the bed
and back toward your laptop and
leave some fresh towels.
Or when you're flying
through international borders,
in fact, the U.S.
courts have said that
there is no protection
for citizens or visitors
alike at the US border.
In fact, in this
decision against the
a U.S.
citizen photographer that they
said that the laptops are the most
dangerous contraband and
there's no you know,
you have no expectation of privacy.
So this
this all this venerability is in
pretty much every MacBook
since about 2011 when Thunderbolt showed
up. I've personally tested about six
or seven and found it in there.
The pre thunderbolt devices
are not affected.
These also have mask from so right
into that would be a more challenge
anyway,
you guys might also have heard of another
exploit called Stuxnet that spread
via shared USB
media and was able to
get all the way into the air gapped
scatter systems of Iran's
nuclear refinement system.
It turns out that option rooms on
extra on thunderbolt devices can be
written from that early boot code.
So this allows thunder strike to actually
spread virally through shared
devices.
So you get you know, you have
a Thunderbolt Ethernet device that
you share between machines at work and it
is able to go across them.
So, you know, all
Thunderbolt Max Mac books are vulnerable.
They can spread virally.
What can we do to prevent this?
So I've been in contact with Apple
and they have a
they on their new machines,
the Mac Minis, an iMac retinas
that we've tested, they're no longer an
option. Ramsland, firmware updates.
They will be rolling this out for the
other Macs.
However, they're still loading option
ROMs on normal.
Boutte's snares attack from 2012
still works.
You can still get back doored
via the Austin kernel.
It's also possible on the older machines
to do a downgrade attack that you can
downgrade to an older, vulnerable version
of the firmware and then attack it that
way.
And Thunder Strike V two could
use the dark Jedi
sleep attack, which you may
have heard of.
It was introduced yesterday
here at thirty one C three
by and Quarrie.
And what they found is that
during a S3 sleep,
all of the lock bits
are cleared, including lock down in the
BIOS control the thunderbolt
option. RAM is in a prime position
to be able to do this sort of attack.
It doesn't need to be privileged
execution.
It's already running in ring zero.
So there was not
enough club mate for me to actually
implement this last night.
But, you know, look for it in a
upcoming paper perhaps
so Apple could add TPM hardware
back to their Macs.
It wouldn't prevent the dark Jedi
attack, but it would at least let you
detect it on the next boot.
Um, they could also implement drivers
sign in the
future if EFI protocols have it as
almost mandatory.
But the version they have has
this rather ill-Defined security
architecture specific security protocol,
and they do implement that.
But this is the entirety of the
the implementation.
And it turns out that actually Proteau
can never be null.
So it just unconditionally
approves every option around that it
encounters, which does not
provide any security at all.
So because I don't
think option ROMs are a great idea and
none of my devices need it,
I've modified all of my Mac
books to to bypass this call
process option rom
and then strike actually does this
on the systems that it infects.
So you can't actually use thunder strike
to remove thunder strike.
It's close the door behind it.
However, closing down the
option arms might not even be enough.
How many have you plugged into the
projector up here?
How many of you actually verified what
the connector was that Ed Black
had earlier this year?
The Alloy Viper was deployed.
It's a decoy.
Vijay adapters.
Kind of hard to see there, but it does
change to a real VGA adapter
going through a slot screamer, which
is doing active DMA attacks against
the PCI buzz of the running
system. And it can back Doros 10
with a little bit more work.
It could actually launch a Thunder strike
attack as well.
So I believe that
we need a way to disable
PKU functions on Thunderbolt entirely,
that if you just want to use it for your
display, you shouldn't have to
expose your system to this sort of
attack.
I don't know a little bit of work trying
to do this. This would be a lot easier
for Apple to implement as a
configuration option, just like they do
right now. But if you said a firmware
password, the machine
won't boot from external media because
that's a security risk.
If you have a firmer password, it
shouldn't live in option rooms.
You should be able to turn off these
things.
You could also go a little more extreme.
Last year at thirty three, Peter
Susur suggested hard wiring,
right? Protect pens and disordering
programable controllers and he
went through a bunch of work on how to
harden a think pad against
external attacks.
And if you do go that far, you
also should consider using some sort of
tamper evident coverings over the screws
to figure out if anyone has opened
your machine.
This is suggested by Eric Michoud
last year, also at thirty three.
So to sum up, how bad
could an actual weaponized version of
Thunder strike be?
You know, there's nothing looking for
from over Kitchen Austin right now.
It's in control of the system from
the very first instruction.
It can backdoor the kernel, it can lock
keystrokes, it can exfiltrate data.
It can't be removed by software
since it controls the RSA keys.
It also controls the update routines.
You can reinstall Austin and
it'll still be there.
You can swap out your SSD.
It'll still be there.
You can swap out your laptop and
your thunderbolt device might
reinfect your new one.
So it's very persistent.
It can also hide in things like Samim
virtualization or maybe even
the management engine, though that's
another area of interesting research.
It can spread virally via shared devices
and it affects all current models
of intimate books with Thunderbolt.
So that's a pretty bad
combination of things.
If somebody were to actually take this
and turn it into more
than a proof of concept.
But what would really make it worse
is I think this is actually remotely
insoluble, combining
the the deep Jedi coma attack
with option ROMs embedded in the system.
I think this could actually be launched
with just merely a crude exploit
onto the system.
So on that cheery note,
I'll take some questions.
And also we'll be having a workshop
for folks who want to do a little more
deep dove into the into the firmware
images in Halsy
in a little while after after the talk.
Thank you very much.
We have some time for questions, other
questions from the Internet.
Yes, thank you.
There's one question from the Internet
How many Macs have been destroyed making
this presentation?
I have been quite lucky,
both with Magic Lantern and with this
project. I have managed to not brick
any machines.
OK, you can also line up behind the
microphones if you have questions, there
was the second question from the
Internet.
Then microphone number one, please, thank
you, was very, very cool presentation.
Um, if you have been thunderstruck
and you bless an original firmware,
uh, will you break the machine?
Yes.
Is that something that Thunderstruck can
prevent?
Yes, it's the proof of concept
is very, very simple, that it could
actually be much more sophisticated.
It could detect that this is a
sign an Apple Sinophile
and do something different.
It has total control of the update
process.
So it could do it could even
allow the update to go and then
patch it after the fact,
depending on how sophisticated you want
it to be. Or it might just pretend
to to run the update and then
and then ignore it.
OK, thanks.
Microphone number two, I understand
that you have to request the if
I upgrade while that device is
attached in order to exploit or
is it possible to do it just like by
attaching it without having to if I
upgrade so the option can
initiate a SFI update that
it can basically anything
that the kernel could do, the option arm
could do, but have to be doing the
boot Facebook and just attach it while
the thing is running if I want to.
So in this case with this with
a passive device like the gigabit
Ethernet adapter, the machine does have
to be rebooted
while it's running to its second screen.
Should be possible, but I have to reboot
it basically.
Yes, you do have to reboot it.
So, you know, from the perspective of
someone who's been attacked, they come
back and they find their machine is
rebooted or their machine is shut down
and they would say curses.
You know, it's pretty rare that Macs
crash, but they do crash occasionally.
So it's not out of the question, you
know, that that would tip them off
microphone number four.
So this attack would be Mizuki's
is on PCs with Thunderbolt biosecure
boots requiring option.
I'm right.
Absolutely.
So a case where security
does actually protect against
vulnerability being demonstrated on
stage?
I believe so.
Awesome. Thank you.
Microphone number five, hi,
thanks.
Thanks for your talk here
and back, as
can you imagine,
working on other laptops to
sensors, the Sun PCI Express
option, something could be done
on not Apple devices to.
In some other fashion,
so Jon Huntsman's work was on a
PC using just a generic PCI
card that had a programable option from
a lot of SATA controllers have them and
are potentially vulnerable.
The the ease
of sort of evil made attacking
a MacBook via Thunderbolt is much, much
simpler than having to open up a PC and
put a card into it.
OK.
Microphone number one.
So this would also apply to other
machines with Sundwall, for example, is a
better Lenovo's have thunderbolt
now and if
you switch off the TPM
chip, then you're probably vulnerable.
Or if somebody has a private
key and sign some malware with a private
key, then you are all vulnerable, I
think.
Exactly. And is, as Matthew
pointed out, that if you have a secure
reboot that actually signs the option
ROMs, then they would they would not be
vulnerable to this, although
a device with Thunderbolt would
potentially be subject to the
to the slot screamer attack, which was
an active PCI DMA
device.
Another question from the Internet.
Yes, thank you. I've got two
other questions.
The first one is, could you imagine of a
pure software solution as well?
And the second one is, is there a way
to detect that the, um,
um, the ROM is tampered with?
So to the software question,
I could imagine perhaps someone could
produce bug free software and
bios updates, but the
the number of presentations
that find flaws in
in software, particularly
in BIOS updates, makes me think of
software.
Only solution is unlikely.
And
what was the second question again?
Um, is there any possibility to detect
that the ROM is temporary?
So in the proof of concept, it's
quite trivial. It actually advertises
itself with the with the logo.
But a weaponized version would
be very hard to detect that if it's
hiding in the system management mode, it
can detect attempts to write
to the extent to read from the ROM
and serve up a clean copy, or
it could put the system into
virtualization and just provide
a complete virtual from that looks
intact.
Microphone number two, are
you missing any features like booting
from network if you disable the option
ROMs?
Now the it turns
out that the modern Mac books have the
driver for the gigabit
either adapter bundled into into their
room already.
So the option room is completely
superfluous.
It serves no purpose.
Thanks No.
One. OK, two quick questions.
First, if you mentioned, I
think that you have to bless a former
update to launch the attack.
So if I said a firmer password and
shut down my computer before I leave it
in my hotel room, can I prevent it?
Now, the former password is
actually checked after option rooms.
So there's a another
there's a much simpler attack that an
option can actually clear your firmware
password.
And to the other point, your part
of your question, the option doesn't
actually even need a boot OS 10.
It can it can just set the environ
variable and initiate a recovery
and then initiate a recovery mode reboot
from the option room because it's in
zero.
It can do pretty much anything.
Microphone number three.
So do you
think that a opensource
solution, do you think that an
open source solution as opposed to an
open standard solution?
Would be able to avoid this problem
or have you investigated in
particular, Corbould, if Corbould is
vulnerable to this problem, I believe
GROBART is not vulnerable to either
thunder strike or to the jet Ikoma
attacks.
I have not done really any work
with Corbitt, so I'm not
sure, although in general
we should talk then we should.
In general, I think that having open
source for the for the early
Bhoot is really vital
both to trust that the system
is doing what we think it is.
And this is one of the reasons I'm really
excited about things like Bunny's laptop
that we're all of the source for.
Every piece in the system is available so
that we can actually understand how it
all works.
OK, so
we are running out of time, so please
keep your questions and if possible, the
answer short microphone number four.
Yes, as you've shown, the firmware
update not only contains a signature,
but also a public key.
What happens if you replace a public
key and then just create another
signature?
Have you tried that?
Oh, I'm sorry.
Oh, yes, actually, the
I didn't go into the presentation.
I have a paper that I hope will be coming
out sometime soon that actually goes into
a lot more technical detail.
The the public key in
the signature is actually ignored.
You can write whatever you want there and
it doesn't matter.
The the public key is actually
stored in in the in the boot from
there. Actually five public keys, but
only key zero is ever read.
And that is the one that is actually used
to to validate the signature.
Thanks.
Microphone number two, have you looked
at other attack vectors
than Thunderbolt or PCI?
Ilene's like express cards.
I have not, but I've
I've received email from someone who has
looked at it and suggests that it would
also be vulnerable to this sort of attack
on microphone number one again.
And I launched this attack from another
MacBook with a Thunderbolt cable.
Or do I need special hardware?
That's an interesting question,
I have not looked into that, whether or
not if you boot into a target drive mode,
could you could you fake it out?
Possibly that might be
cheaper that.
I don't know, I haven't looked enough
into that part of the firmware
microphone number five.
Yes, you said that
with your like you can close the
door behind you for this exploit.
Can you provide the service to close
all our Mike Brooks
if anyone would like to borrow a
Thunderbolt Ethernet adapter?
So right now, my proof of concept is
has a lot of hardcoded things for the
specific version, so
I verified that the the
sort of exploit works against the other
ones, but I've only actually implemented
the 10 CUMA one MacBook.
So if you have one of those, I'd be happy
to to let you upgrade
microphone number three.
OK, so I'm wondering, since the option
Rum's only loaded during boot and you
can basically, as far as I know, prevent
access via the system running by
setting a firmware password.
And you said it's possible to write
the option rom if you are
early in the process.
Is there any way, once you've booted
to check if your adapter has
been infected?
I.
Potentially so from a clean system,
you could read out the option and find
out if it contains an exploit in it.
But once from an infected
system, if it were being sufficiently
stealthy, it could mask that attempt
to read.
And you had a second question that
actually I thought was quite good, that
regarding DMA, there's
a lot of interesting work being done with
Thunderbolt and DNA attacks, especially
looking into how well does
in the amamou actually protect
you. And it's not clear
that it provides as much protection is
as we would like.
Microphone number four.
OK, forgive me if this is a stupid
question, but other than open sourcing
the process entirely, which is a no
brainer, could vendors protect
against this kind of attack by using
something like timing based attestation
of the firmware?
So knowing the timing
signature that the legitimate firmware
has and measuring that in
the operating system, also another
kind of electronic device that measures
that, that then if an attacker uploads
their own malicious firmware, they at
least have to emulate the timing
side channel of the legitimate firmware.
So to the first part of the question,
I don't think so.
The Meitner presented a really
neat piece of malware called a tick
that I think was 51 bytes, and it was
capable of beating the time timing based
attestation.
The other is that it could put
the system under vocalized
environment or it could just rewrite the
timestamp counter that it's you know,
it's in ring zero.
It's in real mode.
It can do really whatever it wants.
Thank you. Another question from number
four.
Um, just very two
very short questions, uh,
the one was to verify, again, you
said the current IMEX and McManis
are not affected and future Mac books
will won't have this
problem that.
So Apple
has produced a fix that they are
shipping in the current Mac minis
and iMac retina's that
protects against the proof
of concept.
However, it leaves out
a huge hole in terms
of the option ROMs that I believe could
be a thunder strike V
two, which would fairly easily be able to
attack.
And the second question was,
um.
Um, proprietory 2pm
modules have been, uh,
criticized, um,
what do you think is is other
more helpful or are they
in any kind?
Uh, do they have any drawbacks
if they're not open source?
So is it better to have a machine with
the TPM module or without one?
To perhaps 2pm is not not
exactly the right word, but some
systems have sort of
a coup processers
or sometimes even hardware devices that
will leave the main CPU and reset until
they do cryptographic verification of
the boot rom.
So that's the sort of technology
that I think is really necessary
to detect these sort of attacks.
There's a huge number of papers about
defeating TPIMs and security via
the other techniques, so I'm not
sure how well,
you know, proprietary TPM versus
some more open source one would really be
able to do.
OK, one final question from number two,
just to make sure it's not that I can't
leave my computer in a room, I can't
leave any of my Thunderball devices
either.
Right.
That's that's a great
point. Yes.
You should keep your your thunderbolt
devices with you along with the computer.
And having said that.
Would it theoretically be possible if you
do achieve good execution from the
Thunderbolt device to actually perform
tests through that code?
Could I create a Thunderbolt device
that actually uses an option room
to check my own?
If I you could.
Unless you're running, unless you've
already been hit, in which case the
option won't be loaded at all.
OK, that so all
of my machines are protected in this way
that they will not load option
rooms, which is also,
you know, the sort of thing that
would be great if it a configuration
option just to be able to say, you know,
don't do this first, then you'd know.
If it doesn't execute, then you'd know
if it had some way to let you know that
it had executed, I
suppose it depends how targeted of an
attack you you're expecting.
OK, so please give again a round
of applause to general.