Fwd: Apple EFI Firmware Security Vulnerabilities
Stuart Cracraft
Begin forwarded message:From: Rich Cower <rco...@gmail.com>Date: January 5, 2015 at 10:22:12 PM PSTSubject: Apple EFI Firmware Security VulnerabilitiesTo: Stuart Cracraft <smcra...@me.com>
From ease of reverse engineering perspective--- Interesting to see the amount of lead points the researcher got by using search engine on strings/hex he saw and getting hits to clues of what data he was looking at.
He described how he reverse engineered in the presentation. http://thehackernews.com/2015/01/thunderstrike-infecting-apple-macbooks.html
Notes: It is possible to use physical access to a Mac to permanently compromise the system in a fashion that prevents repair later. This takes advantages of mistakes in the firmware update functions. It would benefit from some of the newer Intel hardware protection capabilities.
Thunderstrike is the name for the Apple EFI firmware security vulnerability that allows a malicious Thunderbolt device to flash untrusted code to the boot ROM. It will be presented at 31C3 and the transcript of the presentation and slides will be here after the talk.Overview
In this presentation we demonstrate the installation of persistent firmware modifications into the EFI boot ROM of Apple's popular MacBooks. The bootkit can be easily installed by an evil-maid via the externally accessible Thunderbolt ports and can survive reinstallation of OSX as well as hard drive replacements. Once installed, it can prevent software attempts to remove it and could spread virally across air-gaps by infecting additional Thunderbolt devices.
It is possible to use a Thunderbolt Option ROM to circumvent the cryptographic signature checks in Apple's EFI firmware update routines. This allows an attacker with physical access to the machine to write untrusted code to the SPI flash ROM on the motherboard and creates a new class of firmware bootkits for the MacBook systems.
There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction. It could use SMM, virtualization and other techniques to hide from attempts to detect it.
Our proof of concept bootkit also replaces Apple's public RSA key in the ROM and prevents software attempts to replace it that are not signed by the attacker's private key. Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the harddrive has no effect. A hardware in-system-programming device is the only way to restore the stock firmware.
Additionally, other Thunderbolt devices' Option ROMs are writable from code that runs during the early boot and the bootkit could write copies of itself to new Thunderbolt devices. The devices remain functional, which would allow a stealthy bootkit to spread across air-gap security perimeters through shared Thunderbolt devices.
While the two year old Thunderbolt Option ROM vulnerability that this attack uses can be closed with a few byte patch to the firmware, the larger issue of Apple's EFI firmware security and secure booting without trusted hardware is more difficult to fix.FAQ
§ 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.
§ 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. 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.
§ Does a firmware password prevent this attack? The Thunderstrike attack is not prevented by having a firmware password enabled. The PCIe Option ROM on the Thunderbolt device is loaded before the firmware password is checked, allowing it to bypass the password protection. It can also clear or reset the password if desired.
§ 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.
§ How is this related to the DMA attacks? Thunderstrike is independent of DMA attacks like SLOTSCREAMER and Inception. The current proof-of-concept uses a PCIe Option ROM at boot time to launch the attack against the firmware update system, not a DMA attack against the running system.
§ How is this related to Snare's boot.efi attack? 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.
§ 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 can make it very difficult to detect or remove. It could do things like use virtualization to make the boot ROM appear to be unmodified, pretend to accept Apple's signed firmware updates, etc.
§ Can you use the same 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 as part of replacing the boot ROM. Thus a machine infected by the proof-of-concept is no longer vulnerable to itself.
§ Will the source code be available? Details are still being worked out; contact me via PGPto 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.
§ Have you talked to Apple? We have filed several Radar bugs over the past two years related to EFI vulnerabilities. Please contact Apple for their plans on assigning a CVE to this vulnerability and fixing it.
§ Is there a CVE? A CVE has not been assigned. Only Apple can assign CVE's for their products.
§ What about...? Send email to hud...@trmm.net, preferably with PGP and I'll do my best to answer your questions.
