Apple products have long enjoyed a reputation for superior security in relation to Windows systems, but a new proof-of-concept malware delivery method could put a serious dent in that reputation. The exploit, dubbed Thunderstrike, currently can’t be detected or removed by any known process without using specialized hardware. Security researcher Trammell Hudson has demonstrated how to use a Thunderbolt peripheral to load what he’s calling a “bootkit” via the device’s Option ROM.

Option ROMs are optional or peripheral-specific blocks of memory that were first deployed in the 1980s as a way of storing critical programs or retrieving peripheral-specific blocks of memory. They’re initialized early in the boot process and often “hook” to the BIOS to provide a bootable device or network boot. Thunderbolt devices contain their own Option ROMs, and Apple hardware checks these areas as part of its boot sequence.

The exploit package is injected from the infected Thunderbolt device’s Option ROM directly into the system’s extensible firmware interface (EFI). Official documentation on the EFI/UEFI standard, shown below, seems to imply that this is impossible, since the firmware is supposed to be locked by default:


In theory, EFI mechanisms prevent this attack.

Unfortunately, it isn’t. Hudson’s research and testing indicates that the Option ROMs are loaded during the recovery mode boot process. The one snag, at this point, is that Apple still checks the signature of the EFI file itself. Change the file size or contents, and it fails the check — or it would, if the research team hadn’t devised a method of replacing Apple’s stored public RSA key with a key under their own control.



Once this step is taken, there’s no going back. Without a proper RSA authentication key, it’s impossible for the end user to update the device’s firmware with a standard Apple image. All attempts to do so will fail authentication. With such basic access to the system, there’s very little an attacker can’t do. The entire system can be monitored, keystrokes logged, website visits tracked, password data recorded. The bootkit can also be passed to other Thunderbolt devices if they’re connected to a compromised machine.

Are “evil maid” attacks a valid vector?

The one slice of good news in this issue is that the attack does require at least a brief window of physical access to the system. In most cases, that kind of requirement confines most attacks to strictly theoretical exercises, but Thunderstrike is somewhat different. First, the attack is fast. The attacker doesn’t need to sit down at the PC for several minutes, or even enter data. Surreptitiously plug in a Thunderbolt device, hold down the power button for several seconds, and boom — the attack can execute and self-install in a scant number of minutes. Depending on how sneaky the execution is, a casual observer might see nothing but a longer-than-normal boot cycle.



The standard model for physical-access attacks relies on the idea of the evil maid — someone who can access a system while it’s stored in a hotel room or locked in a safe, but I daresay the speed and subtlety of this hack make it a larger threat. If you’ve ever attended a business conference or tech event, it’s not exactly rare for people to have laptops out but not strictly attended to, or to leave a system sit for a few minutes while they use the restroom or grab a soda.

Third, and most chillingly, we now know that government agencies actively engage in the kind of targeted intercept that makes an attack like this work. One of the reports leaked by Edward Snowden detailed how the NSA will intercept hardware en route from manufacturers like Dell and HP, modify it with rootkits and spyware before it reaches its destination, then repackage the equipment and ship it on its way. While there’s no way of knowing just how widespread such tactics are, we know it happens — exploits like Thunderstrike are likely worth their weight in gold to the various national intelligence agencies of the world.

Apple is preparing a firmware patch that will at least refuse to load Option ROMs during firmware updates, but it leaves open a different security exploit first detected in 2012. The timeline for a complete fix is unknown.

What is the source of the info?