Thunderstrike FAQ

The Thunderstrike page has an overview of the vulnerability and there is also a much longer annotated version of my 31c3 presentation. If your question isn't answered here, send email to hudson@trmm.net, preferably with PGP and I'll do my best to add an answer to your questions to the FAQ.

Thunderstrike EFI bootkit FAQ

General

Is Thunderstrike "in the wild"?

To the best of our knowledge there are no Mac firmware bootkits in the wild and Thunderstrike is only a proof-of-concept that does not have any malicious payload.

Should I be worried about Thunderstrike?

Probably not, unless you're a certain type of high-value target. Rich Mogull's well written two part article lays it out nicely: Thunderstrike Proof-of-Concept Attack Serious, but Limited, pointed out how unlikely such an attack was against normal users, and Your Risk Isn’t My Risk, which describes how this sort of vulnerability could be used in a targeted attack. One of the best tl;dr descriptions was by Brian Donohue at Kapersky in What You Should Know About the Thunderstrike Mac Bootkit:

There is no room for doubt here: Thunderstrike, like all boot- and rootkits, is a nasty threat that can wrest control over everything you do on your computer. You can think of it as the Ebola of computer threats: catching the disease carries devastating consequences, but the likelihood of becoming infected is relatively small.

Have you talked to Apple?

We have filed several Radar bugs over the past two years related to EFI vulnerabilities and been in communication with them. They are preparing a fix for part of the vulnerability that will not load Option ROMs during a firmware update and is described in the mitigation section of the talk.. It is currently shipping for the iMac Retina and Mac Mini, and should be available soon for older systems. However, while this does prevent the Thunderstrike proof of concept from being able to circumvent the signature process, the older MacBooks can be subjected to a downgrade attack to a vulnerable version. And the "Dark Jedi Sleep" attack from 31C3 might be usable against all Macs.

Is Thunderstrike fixed in 10.10.2?

The APPLE-SA-2015-01-27-4 OS X 10.10.2 and Security Update 2015-001 include in the change log:

CPU Software
Available for: OS X Yosemite v10.10 and v10.10.1,
for: MacBook Pro Retina, MacBook Air (Mid 2013 and later), iMac (Late 2013 and later), Mac Pro (Late 2013)
Impact: A malicious Thunderbolt device may be able to affect firmware flashing
Description: Thunderbolt devices could modify the host firmware if connected during an EFI update. This issue was addressed by not loading option ROMs during updates.
CVE-2014-4498 : Trammell Hudson of Two Sigma Investments

This change does prevent the current proof of concept of Thunderstrike from being able to rewrite the ROMs. The change log does not mention downgrade prevention, although reports in the media are that this boot ROM version will prevent rolling back to vulnerable versions. All pre-Yosemite machines remain vulnerable to Thunderstrike unless Apple releases firmware updates for them as well.

However, this firmware version are still vulnerable to Snare's 2012 attack against boot.efi since the systems will continue to load Option ROMs from attached Thunderbolt devices during normal boots. This means that a customs official or other evil-maid attacker can still install bypass firmware passwords and install backdoors into your system before OS X is started. Additionally, if the S3 "Dark Jedi Coma" attack can be launched from the Option ROM, then the boot ROM can be overwritten from a normal boot.

To properly close the vulnerability for users concerned about the physical security of their systems, there needs to be a way to disable Thunderbolt's PCIe functions entirely.

Does anyone actually use evil-maid attacks?

The easiest way to deploy an attack like Thunderstrike is via an "evil maid" that has a few minutes alone with your laptop, either in the house cleaning case or during an international border crossing, it is not clear how often this occurs. The border crossing might be more likely than the hotel, but no one has any numbers, nor do we know how often the NSA intercepts shipments of computer equipment to install backdoors.

However, since Thunderstrike can also infect other Thunderbolt devices, it can also be spread via shared devices or via adapter substitution by a targeted access operation. This no longer requires direct physical access to the computer, but instead allows an attacker to have access to an accessory like a Gigabit Ethernet adapter that might be plugged into the system later.

Does a firmware password prevent this attack?

The Thunderstrike attack is not prevented by having a firmware password enabled or if the machine is locked. The attacker needs to reboot the machine to launch Thunderstrike, which they can do by holding the power button for five seconds. During the reboot, the PCIe Option ROM on the Thunderbolt device is loaded before the firmware password, disk encryption password or user passwords are checked, allowing it to bypass any password protection. It can also clear or reset the firmware password if desired by clearing part of the boot ROM.

Additionally, there is no need to wait for a firmware update. The Thunderstrike Option ROM can detect that it is in a normal boot and write to the NVRAM variables to initiate a recovery mode boot. It can then call the EFI RunTime Services callback gRT->ResetSystem() to reboot into a firmware update mode.

Can it actually decrypt FileVault?

Thunderstrike can not directly decrypt FileVault keys, but it does record the password the user types in to decrypt an encrypted boot volume and could use other data exfiltration techniques to send the key to the attacker's system.

During an border crossing or evil-maid attack, the encrypted drive image could be quickly retrieved via Thunderbolt and stored by the attacker. This image could then be decrypted later once the user has typed in their password and the encryption keys exfiltrated by the bootkit.

Is it really impossible to detect or remove?

Thunderstrike changes the RSA public keys in the boot ROM, which prevents Apple's normal firmware update programs from being able to replace it. The proof-of-concept does not attempt to hide -- it changes the firmware lock screen logo and does not attempt to mask its presence in the boot ROM. However, a weaponized version of Thunderstrike would be much more stealthy and could make it very difficult to detect or remove. It could employ techniques like using virtualization to make the boot ROM appear to be unmodified, pretend to accept Apple's signed firmware updates, hide in System Management Mode, etc.

Does Thunderstrike require special hardware?

Thunderstrike does not require anything beyond a normal Thunderbolt Gigabit ethernet adapter. The device remains fully functional as an ethernet adapter, even while carrying the Thunderstrike payload. The Option ROM can be written by software, which allows a Thunderstrike infected machine to infect new Thunderbolt devices that it encounters. The devices does not need to be opened -- the one shown here was cut open for examination.

Is Thunderstrike really a virus?

Yes, with some caveats. PCIe Option ROMs are writable during the early boot process, so an infected machine can write the exploit to new Thunderbolt devices that are plugged into the machine while it boots. While the proof of concept only infects Gigabit Ethernet adapters, a weaponized version could target other devices such as external drives, SATA controllers, GPUs or anything that has an Option ROM. This allows it to propagate virally through shared devices and is what allows it to cross air-gap security perimeters.

Can you use the Option ROM technique to replace the modified boot ROM with a clean copy?

You can't use Thunderstrike to remove Thunderstrike. In effect it closes the door behind itself: the proof-of-concept patches the Option ROM vulnerability in Apple's EFI firmware as part of replacing the boot ROM. Thus a machine infected by the proof-of-concept is no longer vulnerable to itself and to clean it up will require either a firmware update signed with the attacker's private RSA key or a hardware in-system programmer to flash the boot ROM chip on the motherboard.

Will the source code be available?

Details are still being worked out; contact me via PGP to discuss your use for the proof of concept. The slides from the presentations contain sufficient pseudo-code for Thunderstrike to be reproduced, without giving a script-kiddie solution.

Is there a CVE?

Apple assigned the firmware update vulnerability CVE-2014-4498 and it is now published in the CVE database:

The CPU Software in Apple OS X before 10.10.2 allows physically proximate attackers to modify firmware during the EFI update process by inserting a Thunderbolt device with crafted code in an Option ROM, aka the "Thunderstrike" issue.

Other attacks

Thunderstrike uses the same attack vector that snare identified in his 2012 BlackHat talk. This PCIe Option ROM vulnerability still exists in the most recent MacBooks and releases of OS X. However, snare's attack modified the boot.efi file on the harddrive, which is loaded much later than the boot ROM and can be replaced via software.

Thunderstrike is based on PCIe Option ROMs, not DMA. Active DMA attacks like SLOTSCREAMER, Funderbolt and Inception are a very different class of vulnerabilities that take advantage of the ability to read or write memory via the Thunderbolt port. While the current proof-of-concept uses a PCIe Option ROM at boot time to launch the attack against the firmware update system, it is possible that a future version could use a DMA attack against the running system to launch a firmware update.

Corey Kallenberg and Rafal Wojtczuk revealed the "Dark Jedi Coma" attack at 31C3 the day before the Thunderstrike demonstration. Their attack is more general and also allows write access to the flash ROMs, although it is a very different vulnerability. A future version of Thunderstrike could use this attack vector to bypass the need to initiate a recovery mode boot.

Does Secure Boot prevent Thunderstrike?

Secure Boot does not use any cryptographic hardware, so if an attacker is able to write any changes to the boot ROM it can circumvent the checks. However, it does add signatures on Option ROMs, which would prevent a random Thunderbolt device from being able to inject untrusted code into the boot process.

Technical

What are Option ROMs?

The original IBM PC included six Option ROM sockets for optional features. These were typically used for things like "ROM BASIC" or drivers for additional devices. At boot time, the BIOS would see if there were any chips installed and execute startup code from them. Adapter cards in the ISA bus could also provide expansion ROMs with code to initialize themselves. This legacy feature was carried through all the way to the modern PCI Express (PCIe) bus -- when a modern computer boots it queries every device installed to check if there is code to be executed before loading the operating system. Thunderbolt brings the PCIe bus to the outside and allows external devices to provide Option ROMs to the EFI firmware.

What are SCAP files?

These are the firmware update files that Apple includes in their downloads. I believe it stands for "Secure CAPsule" (the EFI spec talks about "capsule updates"). They are signed with RSA2048 private keys on the SHA256 hash of the contents; the ROM contains the RSA public key and can use it to verify the signature.

What does the `bless` command line utility do?

The bless commandline tool is what Apple uses to copy the SCAP file to the EFI recovery partition and set the NVRAM variables to point to it so that the PEI phase knows to leave the flash unlocked and execute the code in the SCAP file. The man page does not document the -firmware and -recovery options, but they are present in the OS X version.

Do all file volumes have CRC?

You can verify the CRC32 on a normal firmware volume by extracting the data portion of the voume, skipping the 0x48 bytes of FVH header: mbp2014:~/efi: dd if=mbp101-b02.rom \ skip= $[<span style="color:green">0x190000</span>+0x48](<span style="color:green">0x190000</span>+0x48) count=$ 0x1a0000-0x48 \ bs=1 > /tmp/fvh 1703864+0 records in 1703864+0 records out 1703864 bytes transferred in 2.512802 secs (678073 bytes/sec) mbp2014:~/efi: crc32 /tmp/fvh 4a6f7b03 mbp2014:~/efi: xxd -s 0x190000 -g 1 mbp101-b02.rom | head -4 0190000: 70 0e 22 50 00 00 00 00 03 7b 6f 4a 50 a1 13 00 p."P.....{oJP... 0190010: d9 54 93 7a 68 04 4a 44 81 ce 0b f6 17 d8 90 df .T.zh.JD........ 0190020: 00 00 1a 00 00 00 00 00 5f 46 56 48 7f 8e ff ff ........_FVH.... 0190030: 48 00 11 76 02 00 00 01 a0 01 00 00 00 10 00 00 H..v............

If you try this on the last volume at 0x7F0000, you'll find that it doesn't match up since the last few bytes of the volume also store machine specific data like the serial number. The CRC32 isn't updated when the firmware is flashed and it turns out that this one volume is not crc checked at boot time.

Additionally, if the ZeroVector contains 0, the CRC check will be skipped entirely. This doesn't seem to be used in any of the firmware's that I've examined.

When is the SCAP signature checked and the Option ROMs loaded?

The SCAP file has a signature check performed during the PEI phase, but it appears that the DXE code for the firmware flasher stored in the SCAP file is used instead of the ROM version. This has been suggested as a way to make it possible to recover from a failed flash, although I don't see how it would work. This also makes the downgrade attack possible since there are signed SCAP files with the vulnerable DXE code present.

2015 Security

Last update: November 8, 2020