

Thunderstrike 2: Mac firmware worm details - georgyo
https://trmm.net/Thunderstrike2_details

======
thudson
tl;dr: Xeno Kovah, Corey Kallenberg and I ported several previously disclosed
vulnerabilities from Windows UEFI systems to Apple's EFI firmware. Using the
2014 Darth Venamis ("Dark Jedi") vulnerability we were able to unlock the
motherboard boot flash, write our proof of concept to it, then scan the bus
for PCIe Option ROMs and copy the worm to them as well. This allowed it to
spread to other systems via shared Thunderbolt devices, possibly across air-
gap security perimeters or via evil-maid attacks.

Like the original Thunderstrike vulnerability presented at CCC last year[0],
firmware passwords and FileVault encryption don't prevent infection,
reinstalling OSX won't remove it and it changes the RSA keys in the ROM so
that Apple's firmware update routines can't remove it either. The only way to
remove it is with a hardware in-system programming device connected to the SPI
flash chip.

This is a transcript of our hour long presentation at DefCon 23 / Blackhat
2015 last week, which is why it is too long to read... Here is a shorter
overview[1] and a demo video[2].

0: [https://trmm.net/Thunderstrike_31c3](https://trmm.net/Thunderstrike_31c3)

1: [https://trmm.net/Thunderstrike_2](https://trmm.net/Thunderstrike_2)

2:
[https://trmm.net/Thunderstrike2_demo](https://trmm.net/Thunderstrike2_demo)

~~~
outworlder
> then scan the bus for PCIe Option ROMs and copy the worm to them as well.
> This allowed it to spread to other systems via shared Thunderbolt devices

Is a thunderbolt display considered to be an "option ROM"? Meaning it would be
possible to have a rogue monitor spreading a firmware infection?

~~~
Sanddancer
Yep. It's got a chip covered by b57.c in it.

~~~
25L6406
I see that the chip has a Write-Protect PIN on it. Could it be held (high or
low) in order to prevent the attack from becoming persistent?

~~~
Sanddancer
Potentially, yes. However, if you want to have the ability to write firmware,
etc, you're going to want some way of toggling that pin, leaving us right back
where we started.

~~~
userbinator
You connect that pin to a small switch in a not-so-easily-accessible place and
tell the user to connect it whenever firmware updating is required. Something
as simple as pushing a paperclip into a hole would be sufficient.

Firmware updates should _not_ be "transparent", "seamless", "one click", or
whatever other terms are used today to describe silent or little-noticed
changes. They are modifying a very important part of the system, and the user
has to be aware of that.

~~~
spacehome
For better or worse, that's definitely not the "Apple Way".

~~~
userbinator
Apple did do that before though:
[http://support.apple.com/kb/DL1283](http://support.apple.com/kb/DL1283)

------
beagle3
Off topic, but highly recommended: Trammell Hudson's other projects[0]. The
most famous of which is Magic Lantern, an alternative firmware for Canon DSLRs
which makes them infinitely more useful for movie making (and a little more
useful for stills); but other projects are also worth looking at.

[0] [https://trmm.net/](https://trmm.net/)

------
Jedd
For me, this the single most insightful / unsettling quote from the article:

    
    
      > Thunderstrike 2 doesn't make use of any new zero-day
      > vulnerabilities -- these are all older vulnerabilities
      > that had been previously disclosed and fixed on other
      > platforms.
    

The 'other platform' bit is a tad ambiguous, or simply overly generous, if you
consider (U)EFI to be the platform.

~~~
tjohns
It sounds like unsigned Option ROMs are an even bigger problem. If anything,
UEFI provides an effective defense via Secure Boot. Sadly, Apple doesn't
currently implement this feature -- at a minimum, they'd need to upgrade from
EFI 1.10 to UEFI 2.3 to even be able to consider it.

------
Svenstaro
Why do exploits tend to have such ridiculously good names recently?

~~~
rdudek
The media loves good names so they can spread their fearmongering.

~~~
stephengillie
Firmware worm? Can we call this "Wormware"?

~~~
LinuxBender
I saw the name "FirmWorm" used for this vuln.

------
a2tech
Apparently having a programmable operating system that allows reading/writing
to RAM and system devices and that is rarely updated running under your own
operating system allows easy exploitation, who would have guessed?

System integrators shouldn't be trusted to write software. If you've ever
installed software from your various BIOS manufacturers you surely know that

------
PhantomGremlin
Collectively the computer industry has become much stupider over the decades.

Back in the 1970s, when 9-track mag tape was popular, there was a saying: "no
ring, no write". There was a physical plastic ring that needed to be inserted
into the tape reel hub before the tape could be written to.

When 8" and 5" floppy disks were popular, you needed to place a physical piece
of tape onto the side of the media, to cover a cutout. Without that, you
couldn't write to the floppy.

Then 3.5" floppies became more popular and you had a mechanical tab you needed
to move to enable/disable writing.

Same with early PCs. In order to update the BIOS you needed to physically move
a jumper on a motherboard.

All the above was enforced by _hardware_. There was no magic SMM that could do
whatever it wanted.

But all that was too expensive, or just not friendly enough for end users.

The bean counters and hipsters making the decisions nowadays have learned
_nothing_ from computer history. We've regressed.

Now get off my lawn. And be quiet, it's time for my nap.

~~~
saidajigumi
> The bean counters and hipsters making the decisions nowadays have learned
> nothing from computer history.

As someone who's also used and remembered write-rings, etc., this is nonsense.
The concern over threats back then was VASTLY lower than today, because the
threat was in fact far lesser. Computers were vastly less interconnected and
knowledge about exploit tactics was still nascent, and a fair bit harder to
come by. Stuff was _massively_ exploitable because in the "good 'ol days"
there were a lot fewer computer literate people to think about things like
"attack surface", and fewer still who had motive to use such knowledge
maliciously. I knew grad students back in the 80's who had written their own
illicit versions of "su" to make their lives easier. I.e. local privilege
escalation tools. An undergrad banned (and transformed into an overnight
pariah amongst his peers) for hacking CS dept servers. All kinds of devices
hacked by the curious via some hardware port intended for maintenance or just
left behind on the PCB. Those things happened, but the collective impact of
much of that is less than one major exploit pattern today (Flash 0-day, legacy
consumer routers, take your pick).

No, the root problem vs "yesterday" is just that our computers are cheaper and
far more interconnected than ever before. Things like the option-ROM-as-vector
being an economically practical technology. Our collective level of ability to
ship secure systems is probably far better than it ever has been, but that's
almost nothing in the face of an exponential explosion in the pervasiveness of
computing. We still ship an incredible amount of insecure software and
hardware systems, just because we make so damn much of it. Why design a
complex fixed _mechanism_ or _circuit_ for something when you can solve the
problem 1000x better with a CPU or DSP? That's great, but "oops, we forgot the
security again." Or we didn't, but an exploit was _still_ found and updating
is otherwise infeasible.

It seems that ability to ship secure tech needs to be nearly pervasive, enough
for a sort of technological herd-immunity (or herd-defense-in-depth), if you
will. At this point, I suppose we're looking forward the day when all our
little computers are muttering to themselves like trees in a forest chemically
signaling about attacking pests.

