This is an annotated version of my 31C3 talk on Thunderstrike, a significant firmware vulnerability in Apple’s EFI firmware that allows untrusted code to be written to the boot ROM and can resist attempts to remove it.
Very detailed write-up on this remarkable vulnerability.
This is probably the correct link:
https://trmm.net/Thunderstrike
Using secure boot to protect malware from the legitimate OS/user … ingenious!
The ease with which this attack works is troubling, however in general if your hardware is ever in the hands of an enemy, you shouldn’t trust it afterwords whether it ran secure boot or not. It’s a false sense of security.
Edited 2015-01-02 19:08 UTC
And you’d know because your enemy isn’t sneaky and gives the user a sporting chance by letting him/her know their Mac went AWOL for a bit.
It looks like all they have to do is reboot the computer with a thunderbolt device plugged in, wait 10-30 seconds, and it’s installed permanently.
If you ever leave your laptop in a hotel room or send it through security you could get it, or even leave it alone to go to the bathroom.
It’s pretty worrisome, even if you run an alternate OS like Linux (I do on my Macbook Retina).
Edited 2015-01-02 20:19 UTC
When you buy a Mac, maybe you should be aware that your device has a wide open port on the outside, Firewire for the older Macs and Thunderbolt on the newer Macs which gives Direct Memory Access:
http://en.wikipedia.org/wiki/DMA_attack
This means, you can never keep any secret information save in memory while your device is running.
Like for example encryption keys.
It seems like PCMCIA and PC Card buses should also be vulnerable to the same vulnerabilities as Thunderbolt exhibits.
Are those still in widespread use ?
https://en.wikipedia.org/wiki/ExpressCard#Availability
It seems that since 2010 they’re not so common, but I’ve seen them on a lot of business laptops (Lenovo and such), though being phased out on newer ones.
There is no Secure Boot (at least, not in the UEFI specification term) involved here. Apple is not using UEFI Secure Boot.
What Apple has is a firmware upgrade procedure that requires the update to be signed using a private key where the public complement is in the computer ROM – so that it can verify firmware upgrades as legitimate (signed) before acting on them.
What this attacks does is that it allows any rogue (or even subverted) thunderbolt device to *replace* the public key. This allows the attacker to perform a (malicious) firmware upgrade at a later point in time, of his choosing. At the same time it effectively *totally* shuts out any Apple issued firmware upgrades as they are no longer signed using the “correct” key.
This is not secure or insecure boot. This is about *completely* taking over the machine. Infection comes from the very firmware, so reinstalling the OS will not help. Firmware upgrades will be rejected. If the attacker is competent enough he can even shut out the thunderbolt vector to avoid anyone using the same vuln to revert the machine.
If anyone figures out a way to program the option ROM of popular thunderbolt devices so that the machine will be reverted on next boot, this could get very nasty.
I have no idea about the penetration of thunderbolt devices. If it’s low the vector may only get used for very targeted attacks and not broad trawling.
benjymouse,
I guess you are right, apple does not use secure boot. Apple is a UEFI member, do you know why they decided to keep using their own mechanism rather than to use secure boot? Their approach seems less secure. In any case it’s still ironic that a security mechanism designed to protect the system from malware can be exploited by said malware to protect itself.
I have no idea. I could guess, though: One one hand it would be a no-brainer, since Apple has tight control with HW as well as OS and bootload’er.
On the other hand there is more to designing a *secure* Secure Boot system than simply signing a bootload’er. The signature must span *all* resources used during boot, i.e. not just executables but also scripts, config files etc; basically anything that could be used to divert the regular boot process.
Windows has all core OS components in “signed cabinet” files – i.e. executable files, drivers, config files, policies etc. AFAIK even the Linux distros that support Secure Boot has not solved the “sign everything” problem and thus could be just as vulnerable as before. I suspect that OS X has a similar problem.
My best guess would be that the firmware signing was originally a way to protect Apple IP and prevent customization of Macs more than it was considered an end-user security feature.
I would expect Apple to embrace UEFI Secure Boot sometime in future models – after all Apple has been on board with UEFI for a long time and they once they’ve designed a goof solution they could trivially easily start using it.
benjymouse,
I’m quite certain that this was a goal for UEFI secure boot as well – to protect manufacturers from owner tampering as much as from malware. The official UEFI spec lacks any means for an owner to take control of the key chain. This only became possible because MS eventually added it as a requirement for windows certification, but just on x86. For other architectures where they don’t have a monopoly the owners are denied the ability to control the key chain, and therefor cannot load alternative operating systems.
It’s exactly because they were big UEFI proponents that I’m a bit surprised that they are using their own mechanism. I guess maybe they decided to sit back and watch MS take the hit for the debate over secure boot?
Mac products don’t face the same anti-trust scrutiny as Windows, so I have to wonder whether apple would depart from microsoft and use it to effectively lock out owners from their own x86 hardware? I can’t imagine this would be a popular move, but who knows… manufacturer restrictions haven’t stopped consumers from buying apple’s mobile products in droves.
I do know one thing Apple started to deploy their software on EFI machines obviously UEFI didn’t exit yet.
Maybe there are still EFI-only machines in use today which their software needs to support and they want to add support for it when those don’t need to be supported anymore.
Also no system with secure boot has ever held up when security researchers had a look at an implementation.
So Secure Boot at this point is basically a misnomer.
It reminds a bit FireWire vulnerability (Another Apple stuff), as the FireWire controller could be programmed to remotely trigger an arbirary DMA transfer.
Well documented and fascinating story.
The very scary part from an user view point is that this vulnerability enabled changes to the boot firmware of the machine. These changes would be subtle enough to remain unnoticed for a very very long time – how often the boot firmware is updated during the life cycle of a system?
On the other hand, it was limited in that it could be exploited only via a physically connected device.
A few lingering questions nevertheless:
Do Apple systems have a network boot option like the common WinTel based machine and a similar approach used?
Could “fake” Thunderbolt devices with this payload be put on the market allowing a two step attack with 1) installation of a hacked firmware and 2) using the hacked firmware to download from/upload to the Internet information not intended to be public?
There hasn’t been a general purpose computer or embedded device or SoC on which they haven’t been able to re-flash the firmware.
There have been a lot of attempts by device manufactures to implement things that try to prevent it, but every time a knowledgeable person looked at them and tried to break it the manufacturer solutions always failed.
This is why I bought a Chromebook and installed Linux desktop software on it.
The Chromebook I have (I assume all ?) is one of the few devices widely available on the market that has a hardware switch on the inside (you need to open the casing) to enable/disable the flashing for the firmware.
That is the good thing about the Chromebook design Google came up with. It isn’t a difficult solution, it’s just something they demanded.
There are obviously also cons to Chromebooks.
Edited 2015-01-03 16:35 UTC
That is the stupid thing about most systems out there.
A simple $0.05 switch that blocks the write line can protect against any software or external hardware hack in existence. Yet time and time again we see these software controlled solution that always fail in the long term.
I can’t do it with a SATA drive but with the older IDE drives it was possible to write protect a drive if you wanted to too.
I agree that a hardware switch is preferable to a software one, but in this case hardware access is needed so that wouldn’t matter at all
avgalen,
It’s worth distinguishing between different types of physical access: internal (ie jumpers) versus external (ie thunderbolt/firewire). It’s not the same at all.
Can an internal jumper be exploited? Sure, but it increases the difficulty as well as the risk of being caught, especially if you use the physical locking cables that many computers/laptops are designed to work with. It will be very difficult to open the computer without leaving physical evidence.
Obviously it’s still possible to hack a physically locked computer, but having DMA bus access on the outside is akin to placing your valuables on the front lawn (or perhaps in the back yard).
Edited 2015-01-04 20:53 UTC
I didn’t know there were still cases for non homebrew pc’s that had inside jumpers. I expected we were talking about a hardware switch like the write-protect on a floppy or usb-stick.
Anything that requires opening the casing is a no-go for normal consumers (but then again, why would those need to update the firmware or multi-boot, etc)
So yes, in that case a hardware-switch would definately be a plus in security (although “case-has-been-opened” flags would easily be faked by this firmware vulnerability)
In a word: Yes.
Another vector is the “evil maid” attack.
But a third vector may exist:
As I understand it, some thunderbolt devices have programmable option ROMs. A process on the Mac could program such a device to perform the attack on next boot.
That could be used in a blended attack where an attacker uses some other (future) vulnerability to run a process on the Mac that programs the device and then vanishes itself. As in no trace. One of your own devices have now been programmed to perform the low-level firmware attack, and next time you boot the firmware if pwned and any future firmware updates from Apple are shut out at the same time. Seriously pwned.