POC Shows Mac OS X UEFI Attacks Are Possible; What Does This Mean for Mac Users?
A critical Mac vulnerability was discovered by OS X security researcher Pedro Vilaca last week. According to his research, any attacker can disable the BIOS lock just by taking advantage of a flaw in Apple’s S3 sleep state (more known as ‘standby mode’) suspend-resume implementation. Once an attacker does this, he can install bootkit malware onto a Mac BIOS without the user’s knowledge.
This is can be a major issue for Mac owners since the vulnerability gives attackers unfettered access to their device. Since a bootkit loads before the operating system (OS), attackers can use it to bypass passwords and other security measures. What makes things worse is that bootkit malware cannot be removed or cleaned even after users reinstall their OS.
We tested out this issue on several MacBook models (specifically the 2012 MacBook Pro, 2011 MacBook Air, among others) and found out that the attack is easily replicable. The issue cannot be recreated in newer models like the 2013 MacBook Pro; it’s likely that the vulnerability has been fixed on newer systems. (Apple has yet to officially acknowledge the vulnerability at this time.)
However, it should be noted that while this threat is possible at this time, no web-based attack has been demonstrated yet. No attack has been seen in the wild, either. For now, this is an interesting proof-of-concept (POC). In the future, if a bootkit were to be successfully installed, an attacker could take complete control of an affected system.
A (brief) technical overview
Here is a possible attack scenario:
Figure 1. FLOCKDN is mistakenly cleared
The key point lies in that the flash lockdown (FLOCKDN) bit found in the HSFSTS SPI MMIO register and some BIOS region registers would be mistakenly cleared after one cycle of S3 sleep state and resume, so that the EFI/BIOS flash could be maliciously re-flashed to keep a persistent presence in a Mac as Bootkit.
The typical attack vector would be as follows:
Figure 2. Imagined remote attack for UEFI/BIOS Bookit
Moving towards BIOS attacks
When 64-bit OSs were introduced many system security features (such as the signature check and integrity check) were introduced to secure the kernel space from rootkit malware. Soon afterwards, we started seeing more malware targeting the BIOS.
The Unified Extensible Firmware Interface (UEFI) was designed to replace the BIOS and address its various technical shortcomings. However, hardware vendors and OS developers had to be aligned to properly implement UEFI. Microsoft responded by way of the Windows Certification Program. The widespread use of UEFI made people believe that rootkits and bootkits were now obsolete.
This zero-day vulnerability, as well as the ThunderStrike incident earlier this year, shows that bootkits are very much still possible.
This POC attack targeting the UEFI/BIOS could be a sign that that more evolved, mature attack methods would move towards the Mac platform. Researchers working for Intel Security (who created the original EFI specification that eventually became UEFI) presented a report titled Summary of Attacks Against BIOS and Secure Boot which outlined some of the attacks that could be made against UEFI.
Figure 3. BIOS/UEFI attack surface (Graphic courtesy of Intel Security, from report mentioned above)
Looking at disclosed cases/demonstrations, we can compare the EFI/BIOS attack surface between PC vendors and Apple.
|Attack Surface||PC vendor||Apple|
|SPI flash||Evil Maid||FLOCKDN bypass by S3 suspend-resume|
|HW Config/Protection||Top Swap Attack|
|Secure Boot||PE/TE Header Confusion|
|BIOS Settings (NVRAM,Variables)||Pre-boot password exposure|
|SMI handler||Branch Outside of SMRAM|
What is interesting is that researchers or hackers seem to have learned from some established attack methods and taken these to similar, but newer, similar platforms.
The Apple (dis)advantage
Attacks targeting Apple platforms are also evolving. The so-called ThunderStrike bootkit is based on a Thunderbolt Option ROM which requires a Thunderbolt hardware device to pull off a successful attack. Now, we can see that only software-based SPI flash re-flashing would possibly be needed to keep the BIOS/UEFI infected, which is more practical for real-world targeted attacks.
There are several reasons as to why attackers might find Apple-based devices more appealing:
- BIOS/UEFI specifications are public and should be followed by all UEFI/BIOS vendors, including Apple. Open-source BIOS/UEFI development frameworks could be used to find vulnerabilities.
- Apple only patches vulnerabilities in newer models of their devices. This leaves a lot of the older models vulnerable to potential attacks.
- Apple sustains multiple UEFI versions for different Mac models like the iMac, MacBook Pro, and the MacBook Air. This diversity creates a bigger probability of zero-day vulnerabilities.
- In certain instances, Apple has quietly patched critical vulnerabilities submitted by third-party researchers without publicly announcing them. People may not necessarily know about these vulnerabilities and patches, leaving their devices still vulnerable.
Protecting Mac devices
The primarily responsibility for issuing a fix lies on the part of Apple. While workarounds and mitigation steps are possible, a fix direct from the vendor itself is preferable. The apparent invulnerability of newer Macs to this problem suggests that Apple is aware of this issue, and is aware of how to fix it.
What this means for Mac users is that until such a fix is released, users on older Mac hardware are still exposed to potential bootkits (with the only “fix” being to buy a new Mac).
There are several factors that can lessen the impact of this vulnerability, so to speak:
- The vulnerability can only be found in certain, older MacBooks.
- Exploiting the vulnerability is not easy. The BIOS/UEFI has a complicated architecture that’s hard to debug and develop an exploit for.
- This vulnerability needs other exploits for remote code execution and escalation of privilege root. While this can be achieved with social engineering, using a single exploit lessens the impact.
- For attackers, testing the exploit on different Mac versions would be a massive undertaking.
While these factors do exist, they won’t necessarily completely deter attackers from exploiting this vulnerability. Any existing vulnerability, especially a zero-day, can become a valuable tool in an attacker’s toolbox.
Admittedly, there are no quick fixes when it comes to issues dealing with BIOS/EFI. That being said, there are several things a user can do to address issues regarding the BIOS/UEFI. They can:
- Keep their BIOS/EFI updated. Like software, BIOS and firmware updates are available. Most users may not be aware that these exist or they may not know how to apply the updates.
- Be careful of using their system’s root or admin password on untrusted applications.
In addition to the above steps, advanced users can consider using tools such as DarwinDumper to back up their system’s BIOS/UEFI and verify any modifications.
Additional analysis by Juwei Lin, Jack Tang, and Weimin Wu.