Thunderstrike shook the Apple fraternity earlier in the year when it claimed to be able to exploit a vulnerability in the 'Option ROM' to infect any Mac if an exploited Thunderbolt accessory was connected at boot. That Mac could then infect other Thunderbolt accessories, and so the circle continues. This was patched in OS X 10.10.2, or so it seemed until Thunderstrike 2 emerged from the shadows.
Trammell Hudson, along with two other researchers, then discovered what they call Thunderstrike 2 which adds a virus into the modified Option ROM firmware which they call a 'firmworm' – a rootkit that uses Thunderbolt hardware to infect Mac firmware and then spread by way of email and infected websites.
According to Trammell Hudson, Thunderstrike 2 was only partially fixed with the release of the Max EFI Security Update 2015-001 in June. What this means, Hudson says, is that systems running OS X 10.10.4 and higher are "no longer trivially vulnerable" which has to be a good thing.
A better thing would be that they were not vulnerable at all, especially when you consider that your average bad guy is not beyond the rolling up of sleeves to get at the booty! With the latest patch applied, it's still possible for Thunderstrike 2 to write to option ROMs and spread to new machines, as well as to persist in the S3 resume script until the next full reboot.
It can also still evade detection from software scanning and, Hudson insists, is still able to irrevocably brick systems by corrupting NVRAM.
"Partially patched means that the Protected Range Registers (PRR) are locked before the S3 script is run," Hudson continued, "which prevents a 'Dark Jedi' attack on the boot flash, but it does not fix several other issues."
Hudson said he has disclosed a number of the remaining problems to Apple's product firmware security team, namely:
- Option ROMs are still loaded during normal boots.
- Snare's 2012 Option ROM attack still works and could be extended to other Option ROMs built into the system's WiFi or video card.
- The S3 resume bootscript is still unprotected and executed code from RAM, allowing code injection into PEI from either a software attack or an Option ROM attack.
- BIOS_CNTL.BLE and BIOS_CNTL.SMM_SWP are not locked, allowing the NVRAM to be corrupted (and leaving open possible attacks on the PRR).
- TSEGMB is left unlocked, allowing DMA into SMRAM and code injection into SMM.
Speaking exclusively to SCMagazineUK.com, Peter Bassill, a security researcher at Hedgehog Security, confirmed that "there is a proof of concept in existence that works, and one that we have had working in our lab for a week" which adds weight to the argument that this will become ever more of a “real” threat over the coming months, if not days.
Indeed, with Black Hat coming to an end and Defcon this weekend, "the vulnerability and the proof of concept will have been widely discussed and there will almost certainly be a working exploit in existence by now," Bassill insisted.
He sees Apple as currently "fighting a rearguard action" by releasing two patches so far, with at least three vulnerabilities yet remaining. "Only partially patching an issue is not actually fixing it," Bassill pointed out, adding: "The more time the vulnerability exists, the greater the likelihood of a working exploit being seen in the wild."
Out here in the real world, although one admits it is speculative by nature, the risk does certainly remain that with a vulnerability which can impact System Management Mode, then it will not likely be very long before this attack is re-engineered to work through the remaining vectors.
So, what can Mac users do to protect themselves until the partial patch becomes a complete one? Bassill recommended the usual advice should apply: only click on links you have checked properly and know where they are going. "The one extra protection level I would recommend," he concluded, "is not using other peoples portable devices."
This would appear to chime with the advice given to SC in a statement from Symantec: "Mac users can protect themselves by continuing to practice good security hygiene."
SCMagazineUK.com, talking exclusively to Rafal Wojtczuk, a researcher at Bromium who was part of the initial vulnerability discovery last year, asked the same question. "Strong encapsulation of potentially malicious code, say, in a virtual machine running on a hypervisor designed with security in mind, will prevent an attacker from accessing BIOS/ACPI/hardware, thus preventing the remote attack," Wojtczuk said, before adding: "I think there is no sensible way to stop an attacker with physical access."