Thunderstrike2 details
Thunderstrike 2: Mac firmware worm details
NOTOC
This is the annotated transcript of our DefCon 23 / BlackHat 2015 talk, which presented the full details of Thunderstrike 2, the first firmware worm for Apple's Macs that can spread via both software or Thunderbolt hardware accessories and writes itself to the boot flash on the system's motherboard. The original slides are available. This page is still being edited and updated with additional links.
Introduction
 |
 |
I like to take things apart, understand how they work and document it for other people to be able to do the same. I'm most well known for Magic Lantern, the reverse engineered Canon DSLR camera firmware that allows anyone to write code to improve their cameras. I also enjoy ROM and looking for Easter Eggs, such as the this one in the Mac SE.
This project has its original genesis several years ago when my firm, Two Sigma Investments, was considering deploying MacBooks. There had been reports of rootkits on the Macs and I was asked to use my reverse engineering skills to look into how we could better secure them.
 |
 |
This project was a collaboration with Xeno Kovah and Corey Kallenberg of LegbaCore. Their research into BIOS, EFI and early boot security vulnerabilities has helped make many systems much safer. Earlier this year they started a security consulting firm that does "digital voodoo" with devices and firmware.
Our collaboration came out of two talks at CCC last year. I presented
the original Thunderstrike vulnerability,
the first firmware rootkit for Macbooks. The day before my talk,
I watched Rafal Wojtczuk and Corey Kallenberg present very interesting
attacks on UEFI security on Windows and Linux systems. I was curious
if these attacks were adaptable to Macs and if they could be used
to compromise firmware security when combined with the other findings
of my Thunderstrike talk. After the congress we teamed up to try porting
their attacks to MacBooks and we found that they all worked.
And that's the key finding of this talk: many EFI/UEFI vulnerabilities are
portable between operating systems and hardware platforms.
Thunderstrike 2's 'firmworm' proof of concept demonstrates the entire cycle of a software exploit that can write to the motherboard boot flash, which can then infect Thunderbolt option ROMs, which can hook the S3 resume script or SMM and repeat the installation into motherboard boot flash chips on new machines that come into contact with infected removable devices.
(In the presentation we showed the demo video here; an annotated overview is available)
Background
Thunderstrike 2 doesn't make use of any new zero-day vulnerabilities -- these are all older vulnerabilities that had been previously disclosed and fixed on other platforms.
The reason we're able to do this sort of porting is that all of the firmwares
are derived from a common implementation. In the late 90s Intel needed to replace
the ancient 16-bit BIOS with something modular and extensible that would run on
their new Itanium chips. When Apple switched from PowerPC to Intel CPUs, they
also adopted Intel's EFI firmware and forked it to adapt to their platform.
A few years later Intel created the Unified EFI (UEFI) Forum and contributed the code to the new group, which bumped the version to 2.0 and deprecated the EFI 1.10 release that Apple had derived their firmware from. The UEFI Forum continued development in the EDK2 tree, but there are still millions of lines of common code between the 1.x and 2.x trees. For reasons of brevity, when we say "BIOS", we mean code running from the boot flash on the motherboard.
Typically the firmware vendors like AMI, Phoenix and Insyde fork the UEFI EDK2
tree, add some value and sell the package to hardware OEMs. The firmware vendors
will occasionally backport patches from the head of EDK2, but rarely do a full
git pull and merge. Apple has remain frozen on the 1.10 release with
occasional backports
This shared code base means that most EFI systems look very similar to attackers.
The source code trees are huge and have an enormous exposed attack surface.
In the example above we found that, despite being compiled by different compilers
and coming very different platforms, the random ASUS desktop used in Corey's CANSEC West
demo looks almost identical to a MacBook Air. The function calls are the same,
the code structure is the same, the GUIDs used are the same, etc.
As a result of the shared EFI/UEFI reference implementation, vulnerabilities are often
shared between these systems. A vulnerability found in any system is likely to be
portable to other systems, regardless of operating system or hardware platform.
The delay in trickle-down from Intel's EDK2 to firmware vendors to hardware OEMs to firmware upates to installation by end users can be years (or never). This means that a security patch in the EDK2 tree can be used as a guide by attackers looking for vulnerabilities.
Additionally not all vendors apply all of Intel's recommended security configurations. Over the decades of evolution, the Intel CPUs have accumulated many layers of control registers that must be set to properly defend against known attacks. Not all vendors use all of the features on all of their systems, leaving some machines vulnerable to previously disclosed attacks.
Vulnerabilities
Thunderstrike 2 takes advantage of four older, previously disclosed vulnerabilities.
These had all been known and fixed on other platforms, but not on Apple's MacBooks.
Thunderstrike 2 takes advantage of four older, previously disclosed vulnerabilities: Speed Racer (Incorrect BIOS_CNTL configuration, 2014, VU#766164), Darth Venamis (S3 boot script injection, 2014, VU#976132) Snorlax (Flash configuration is not set after S3 sleep, 2013 VU#577140) and PrinceHarming (2015) Unsigned Option ROMs (2007, 2012)
Speed Racer
The first vulnerability is incorrect BIOS_CTNL control register configuration,
and the related 2014 Speed Racer vulnerability (VU#766164).
The BIOS_CNTL register originally had two bits: BIOS Write Enable (BIOSWE), which prevented accidental writes to the BIOS, and BIOS Lock Enable (BLE), which allowed deliberate writes to the BIOS to be regulated by the System Management Mode (SMM) code. When the OS wanted to write to the BIOS on a system with BLE set, it would set the BIOSWE bit, which would trigger a System Management Interrupt (SMI#). SMM code was able to look at the write request and decide if it should be allowed. If not, it would set BIOSWE back to 0 and return from the SMI#.
This works great for a single core system. Unfortunately it has a race condition,
which was presented by Corey Kallenberg at 31C3. The problem is that there is some
time between the BIOSWE bit being set and the SMM handler setting it back to 0.
An attacker on a dual core or hyperthreaded system could have one thread constantly
trying to set BIOSWE and the other thread contiuously trying to write to the BIOS.
Sometimes it wins the race and, even if it loses, there is no penalty.
The vulnerability was disclosed to Intel and CERT in May 2014. Intel said that the SMM_BMP bit in the BIOS_CNTL register, which was added as part of the Platform Controller Hub (PCH) chipset, would mitigate this vulnerability. This new bit prevents any non-SMM writes to the BIOS unless all cores are in SMM, which fixes the race condition.
Intel recommends all firmware vendors to use
this protection bit, in addition to the BLE bit and the Protected Range Registers (PRR),
but it is not uniformly applied.
The vulnerability disclosure was coordinated via CERT, which has a feature that is
very useful for security researchers. They list all the vendors who have been contacted
and if they have responded, which allows researchers to follow-up with vendors who
claim to not be vulnerable. Vendors who don't respond aren't really held accountable,
although we can likely assume that they are.
Apple said that they weren't vulnerable to Speed Racer, which is
technically true, since their BIOS_CNTL setting of 0x008 means that
they don't use any of Intel's recommended BIOS_CNTL protection bits.
Without BLE, there is no SMM protection against an OS resident
attacker from being able to set the BIOSWE bit and write to the
flash regions that are not covered by the PRR.
The PRR cover the "Code and Stuff" regions, but not the EFI variables,
even those that are normally restricted. There are other holes in the
regions covered by the PRR whose function is not known, but corrupting the
data in this region will "brick" the Mac and prevent it from booting without
a hardware In-system Programmer rewrite of the boot flash.
Bricking a system isn't a very stealthy attack, so most attackers want to
be able to write to the code and stuff protected by the PRR.
Darth Venamis
Removing the PRRs became possible last year with the disclosure of
the "Darth Venamis" attack by Rafal Wojtczuk at 31C3. He realized
that all of the flash protection bits, including the PRR, were reset
during a S3 "suspend to RAM" sleep. Additionally, he showed how
the code executed during a resume from S3 sleep could be modified
on many systems, which allow an attacker to inject code into the
resume process before the lock bits are set.
The vulnerability was often
called "Dark Jedi" attack since it resembles the Star Wars story of how
Darth Plaguis killed Darth Venamis and then resurrected him to study his
Jedi powers.
The S3 script is built by the EFI firmware during a normal boot and used to
speed up the resume process. During the cold boot, the firmware writes
opcodes into a region of memory to represent the operations necessary to quickly
bring the system back up; these opcodes include IO, PCI and memory read/writes,
and, for operations that are not easy to reduce to those opcodes, there is a
catch-all dispatch opcode to call a function.
If the bootscript lives in unprotected memory, an attacker's function pointer can be written into the script. If the SMM Lockbox is used, the script lives in protected SMM memory, but if any dispatch opcodes point to function in unprotected memory, those functions can be hooked to execute the attacker's code.
Using this technique it is possible to lock the Protected Range Registers in a mode
that maps the entire boot flash as read/write. And since Apple is not using BLE
or SMM_BWP in the BIOS_CNTL register, this means that an attacker can now write
to the Code and Stuff region.
The vulnerability was disclosed to CERT and USRT in September 2014.
Unfortunately CERT didn't list which vendors they had contacted,
so at the time we didn't know if Apple had been notified. It turns out
that they were not notified by CERT, however, Apple is on the board
of USRT and was told about the vulnerability at 31C3.
Unlike the original Thunderstrike attack, which required physical access to the
MacBook via the Thunderbolt port or a hardware In-System Programmer, using Darth
Venamis allowed a software-only attack to escalate from root access to writing
to the boot flash firmware.
Normally the PRR are locked by FLOCKDN, but the S3 bootscript is not protected.
This allows the attacker to overwrite a function pointer in the script and store
their function in memory that will be preserved across the sleep. This function
can be as simple as a MOV $F008, (FLOCKDN), which will lock the PRR with
all zero and leave the entire flash writable. After putting the system to sleep
with pmset sleepnow, the system wakes up, executes that instruction
and now the PRR are no longer set. Since Apple doesn't use BLE or SMM_BWP,
the BIOSWE bit in BIOS_CNTL can be set and now the flash can be written freely.
Prince Harming
It turns out that on some systems this code injection in the bootscript isn't
necessary! In 2013 the "Snorlax" vulnerability (VU#577140, CVE-2015-2890) was discovered on some
PC BIOSes -- these systems failed to restore flash configuration registers coming out of a S3 sleep. CERT didn't publish the vulnerability, so it is not known who was notified about the problem. Pedro rediscovered it on his MacBook10,1 and Katie Mo dubbed it Prince Harming.
Pedro had seen our talks at 31C3 and the abstract for our BlackHat/DefCon talk and correctly deduced that we were looking into porting Darth Venamis to Macs. He tested his MBP10,1 machine with the HM77 chipset to see how it handled resuming from S3 and, like Snorlax, found that it didn't configure the PRR at all in the bootscript. In his writeup on his findings he pointed out that Darth Venamis attacks weren't necessary since the machine was completely unprotected.
We hadn't seen this problem on our MacBook11,2 with the HM87 chipset. The PRR
and FLOCKDN were restored coming out of S3 sleep, so we had to use the Darth
Venamis attack to unlock the PRR. This means that Apple or Intel had silently
or accidentally fixed this oversight in the firmware for the newer machines,
but left all of the older machines vulnerable. Since we hadn't seen it, we
hadn't included it in our disclosure to Apple and Oops! Accidental Zero-day!
Apple responded quickly to this disclosure, assigned it CVE-2015-3692 and rolled out EFI Security Update 2015-001,
credited to myself, Xeno and Corey, and Pedro. It applied to 24 models going back
to 2011 and dealt with "insufficient locking" by adding "improved locking".
I was curious to see what had changed, so I diff'ed the firmware and found that
they were now setting the PRR and FLOCKDN in PEI before executing the S3 resume
script. This is a reasonable way to do it since there is no need to leave the
flash unlocked during a resume; Apple's firmware update routine requires a reboot
to initiate an update. Their patch prevents an attacker from using Darth Venamis
to unlock the PRR and easily gain write access to the entire flash.
However... Apple is still not setting the BIOS_CNTL BLE or SMM_BWP bits, allowing an attacker to corrupt the boot flash. The S3 boot script is still unprotected, allowing an attacker to use Darth Venamis to inject code into PEI before the rest of the kernel is started. And another obscure control register, TSEGMB, is left unlocked allowing DMA into SMRAM and escalation into SMM.
Additionally, there is a silent vulnerability fix: the latest Macbook8,1 (the one with a single USB-C port) protects the S3 bootscript in someway, so it is not vulnerable to Darth Venamis at all. This fix hasn't been back-ported to other models, leaving them vulnerable.
Option ROMs
The last vulnerability used by Thunderstrike 2 is a legacy feature: Option ROMS.
These go back to the original IBM PC of the early 1980s with an Intel 8088 CPU.
In addition to the socket for the BIOS chip, there were sockets for "Optional ROMs"
or "Expansion ROMs" that would contain features like BASIC or driver for a additional
hardware. Cards in the ISA expansion bus could also contain Option ROMs so that,
for example, the BIOS could draw to a new video card.
Using Option ROMs as an attack vector is not a new idea. Jon Heasman showed a proof
of concept using PCIe cards at BlackHat 2007, and Snare showed a great demo using
Option ROMs in devices on the Thunderbolt port. His talk is the one that started
my original research in Thunderstrike.
Intel realized that untrusted Option ROMs posed a significant security vulnerability.
As part of developing Secure Boot for UEFI 2.3, they required that all expansion
cards with Option ROMs to be cryptographically signed. Apple is still using
EFI 1.10 and doesn't implement any signature checks on Option ROMs, nor any way
to disable loading them. As a result, there is an easy way to inject code into
the boot process via the Thunderbolt port or to gain persistence even if the
bootflash can't be written.
This is despite eight years since Heasman's demo, three years since snare's rootkits and a year since my Thunderstrike talk. For security concious users Apple needs to provide a way to disable execution of untrusted ROMs, as well as the PCIe functions on the Thunderbolt port (see snare's followup Funderbolt talk).
In the Thunderstrike talk I proposed that Option ROMs could be used for viral
transmission of malware. (I also pointed out that Thunderstrike 2 could use
"Dark Jedi Coma", in an advance hint of this talk).
At that time the only way to write to the ROMs was by rebooting to DOS and
using an ancient b57udiag.exe program to write to the card and required
physical access to the Thunderbolt device. It turns out that the Linux b57.c
network device driver has all of the registers documented for writing to the Option ROM
and was fairly easy to port to OSX. Now only root access is required to read
or update the ROM.
It also serves as an improved attack vector. Now an attacker needs only a remote
root shell (based on whatever vulnerability is currently unpatched), then they
can install the whitelisted DirectHW.kext driver to map the PCIe space and finally
poke at the registers on the Thunderbolt device write to its Option ROM. It is
also important to realize that Thunderbolt is not the only place that this works:
many WiFi cards, GPUs and SATA controllers have them as well.
Conclusion
We looked at six old vulnerabilities that had been publicly disclosed for years.
While one of them was not applicable due to the age of Apple's EFI, the other
five were easy to port. One of them, Snorlax/PrinceHarming, has been fully patched,
one of them, Darth Venamis, has been partially patched, and three remain still
vulnerable. Corey will present Queen's Gambit at HITB-GSEC 2015, which will
allow code escallation from SMM into writing the bootflash.
Going back to the main point: these are not new vulnerabilities. All of them have been discussed for years and many have been patched in Intel's EDK2. But not all vendors have pulled in all of those patches. While we're looking at Apple specifically in this research, the overall message is that many vendors are not keeping up to date and are not responding to CERT, especially if it requires effort to port or test vulnerabilities from other vendor platforms.
Vendors can improve their security by testing older vulnerabilities against
their systems. Sometimes this will involve porting the original proof of concept
or adapting it to the different platform, but we've shown that the common EFI
code means that many vulnerabilities will be portable. Once a vulnerability
has been found it is vital that CERT be updated and the list of affected
machines needs to be published so that users can know what vulnerabilities
are out there.
Additionally, vendors can use all of the locks provided by the platform. Intel publishes recommendations that should be requirements for BIOS_CNTL, TSEGMB, PRR, etc. Tools like chipsec can help diagnose problems in platform configuration.
Intel has also been innovating in the EFI firmware with features like SMM lockbox, although it must be used correctly to avoid exploitation. Newer Intel chips also have hardware features like Boot Guard to move the root of trust into actual ROM inside CPU and allow attacks against the boot flash to be detected before booting.
Finally, vendors needs to be provide better security and configuration around Option ROMs.
Everyone else can start doing firmware forensics! It is no longer sufficient
to just do forensics on contents of memory or harddrives; it is now necessary
to check on the firmware of expansion cards and devices. It is important to
dump the Option ROMs and watch for changes, to compare them against known
hashes, etc. LegbaCore can help with this sort of thing and has workshops on
low level assembly / reverse engineering as part of OpenSecurityTraining.info.
Thanks for attending our talk and we hope you've enjoyed learning about our adventures in porting vunerabilities between Windows and Mac systems. You can checkout Xeno and Corey's research and follow @qrs, @xenokovah, @corekal and @legbacore.
Security Reverse engineering Talks 2015