– Thunderstrike courtesy of Shutterstock –
Thunderstrike is back.
And like your favourite movie sequel, it’s called Thunderstrike 2.
The sequel builds on work reported at the start of 2015 that used security holes in the firmware on your Mac to inject malicious code into the very earliest part of the boot process, where it can run long before OS X itself.
To explain: the firmware is a sort-of hardware-level operating system, stored in a special chip on the motherboard, that prepares your computer for running a regular operating system such as OS X or Windows.
The Boot ROM
In the early days, computer firmware was stored in a special Boot ROM chip – a read-only memory device that was programmed in the factory, plugged into your computer, and remained forever unmodified and unmodifiable.
So, Boot ROMs couldn’t be infected with malicious code, which was very handy; but they couldn’t be updated or patched, either.
To fix bugs, you had to extract the chip and replace it with a new one – a troublesome task on a single computer, let alone in an office full of them.
For convenience, therefore, Boot ROMs were ultimately replaced by Flash chips that were usually write-protected, but could be rewritten under controlled conditions. (They’re still commonly called “Boot ROMs,” but they are no longer truly read-only.)
In other words, only by using special hardware configuration settings could the firmware be updated, which prevented accidental overwrites.
Digital signatures
Apple and many other motherboard manufacturers eventually went one step further, and organised things so that the firmware chip could only be updated by code already contained in the firmware.
For additional security (and control), firmware updates would only go ahead if the new firmware version was digitally signed by the motherboard vendor.
The cryptographic key used to verify the digital signature was stored, of course, in the firmware.
Once the firmware had booted up, it enabled various hardware lockout mechanisms so that from OS X, or any other operating system, you couldn’t change anything.
In theory, both accidental and deliberate overwrites were now prevented.
You couldn’t change the firmware during its own bootup unless you had the right cryptographic key to sign the update.
And you couldn’t change the cryptographic key after the firmware had loaded because it “locked the door” behind itself.
The loophole
Unfortunately, at the start of 2015, researcher Trammell Hudson figured out that there was a loophole, thanks to an intermediate stage between the execution of the firmware itself, and the loading of your chosen operating system.
The Mac start-up-process goes something like this:
- Load firmware from the Boot ROM (soldered onto the motherboard).
- Load firmware Option ROMs from any connected Thunderbolt devices.
- Load and run the Extensible Firmware Interface (EFI) code.
- Load and run OS X itself.
During stage 2, Hudson found a way to bypass the hardware interlock that was supposed to protect the firmware from being modified.
Worse still, he could change the cryptographic key stored in the firmware.
From then on, the usual firmware update process would only accept firmware images that Hudson himself had created and signed.
Trying to restore Apple’s official firmware would fail.
Thus the name Thunderstrike – an infected Thunderbolt device, such as Apple’s own readily-available Ethernet Adaptor, could be used as a vector for unauthorised firmware updates.
One door closes, another one opens
Apple introduced security patches in OS X 10.10.2, released at the end of January 2015, in an attempt to shut off the Thunderstrike hole.
Unfortunately, it seems that Apple didn’t close all the doors.
Hudson, together with two other researchers named Xeno Kovah and Corey Kallenberg, have figured out Thunderstrike 2, which they’ll be showing off at Black Hat USA 2015 and Def Con, two security events taking place back-to-back this week in Las Vegas.
They’ve actually gone one step further with Thunderstrike 2.
As well as using a booby-trapped Thunderbolt Option ROM to modify your Mac’s firmware, they’ve figured out how to include a virus in the modified firmware code.
Their virus will, in turn, attempt to modify the firmware of Thunderbolt devices you insert from then on, thus turning them into carriers of the firmware booby trap, too.
With a touch of techie humour, they’ve dubbed their firmware-borne virus a “firmworm“.
Thunderbolt devices, of course, include removable hard disks…
…in an echo of Stuxnet, the virus that used USB devices to travel between computers on physically separate networks.
Unfortunately, while USB disks carrying Stuxnet could be purged altogether by overwriting them from inside your operating system, infectious Thunderbolt devices can’t be cleaned up, or even detected, in that way.
What to do?
- Avoid plugging untrusted Thunderbolt devices into your Mac, for example if someone you don’t know offers to lend you a network adaptor at a conference.
- Avoid leaving your computer unattended. (This is obvious advice anyway, but Thunderstrike 2 adds another reason to keep it with you as much as you can.)
- Keep your eye out for forthcoming patches from Apple!
Andrew Ludgate
To add a layer in the history of boot ROMs:
“Old World” Macintosh computers bridged the gap between the replaceable ROM chip and the flashable ROM chip by providing a non-replaceable ROM chip that had enough of an OS in it to set up the System Toolbox. Apple started this with the 512Ke and Plus computers. This was designed in such a way that each call could be patched by the OS as part of the init sequence — which meant that anyone could write an Init (later called an extension) to the ROM to override its functionality.
This resulted in many novel pieces of malware for the classic Mac OS, as the ROM could be patched in memory by any running or initializing process.
Fast forward to Thunderbolt 2 and the upcoming USB-C: we now see the downside to having a single connector that’s used for removable storage, node communication, video out, HIDs and serial communications…. it becomes extremely difficult to monitor exactly what the device is actually doing over that connection.
I’m hoping that Apple will soon change their firmware such that TB2 and USB-* devices are treated with the same level of trust as Bluetooth devices: pairing is needed, and requires authentication. No option ROM loading until the device has been properly authenticated.
A clever person could still write a piece of malware that would wait on the device until after it was paired and authenticated, but the process would be much more difficult to exploit.
Paul Ducklin
Agreed! Considering that you almost always plug a Thunderbolt device in *after* you’ve booted (with some special exceptions such as PiXiE-booting over ethernet, say, or booting from an external drive), why allow the Option ROM to run before the OS at all? Or perhaps allow it to run only if a special key is used during startup, in the same way that you choose your boot device by manual intervention.
Running the Option ROM code in the morning when I reboot just because I happened to leave my ethernet adaptor plugged in overnight…strangely reminiscent of the problem we had in the 1980s and 1990s with booting from floppy disks “just because they were in the drive,” when most of the time there was no intention to do so.
Paul Phillips
I’m now running 10.10.4
Is this old news now?
Let’s be responsible.
Rob
“Apple introduced security patches in OS X 10.10.2, released at the end of January 2015, in an attempt to shut off the Thunderstrike hole.”
Note that this did not address theThunderstrike issue:
“Unfortunately, it seems that Apple didn’t close all the doors.”
Let’s read the article :)
Rob
Sorry, that should be “doesn’t address the Thunderstrike 2 issue.”
let’s proofread our own answers! :)