Slashdot Mirror
Researchers Create Mac "Firmworm" That Spreads Via Thunderbolt Ethernet Adapters
BIOS4breakfast writes: Wired reports that later this week at BlackHat and Defcon, Trammell Hudson will show the Thunderstrike 2 update to his Thunderstrike attack on Mac firmware (previously covered on Slashdot). Trammell teamed up with Xeno Kovah and Corey Kallenberg from LegbaCore, who have previously shown numerous exploits for PC firmware. They found multiple vulnerabilities that were already publicly disclosed were still present in Mac firmware. This allows a remote attacker to break into the Mac over the network, and infect its firmware. The infected firmware can then infect Apple Thunderbolt to Ethernet adapters' PCI Option ROM. And then those adapters can infect the firmware of any Mac they are plugged into — hence creating the self-propagating Thunderstrike 2 "firmworm." Unlike worms like Stuxnet, it never exists on the filesystem, it only ever lives in firmware (which no one ever checks.) A video showing the proof of concept attack is posted on YouTube.
I prefer a slightly simpler approach—give the chip a command whose sole purpose is to prevent future firmware updates. During normal driver initialization, set the flag. When you power off the computer, the flag gets cleared. Any update to the firmware requires you to install the new firmware in a particular location on disk, where the driver can wait to set the flag, then verify the firmware signature (with access to a full security stack, Internet access for pulling down CRLs, etc.) before installing it during the next boot.
After all, if you can't protect against someone with physical access rebooting, then there's no reason to have the physical switch at all.
There don't need to be security updates to the firmware. The ROM firmware only needs to do just enough to receive the operational firmware. All these devices run the firmware from RAM anyway. The device can provide that firmware to the host from flash memory, but should not load and start it on its own. This way the host is always in control of the firmware and can make sure that the firmware has not been tampered with.
It used to be that every computer had one of these DIP switches on the motherboard. Need to flash the BIOS? Flip the switch physically, boot the machine to the MS-DOS floppy, let it do its reads/writes/verifies, then flip the DIP switch back.
I'm pretty sure it was cost that did away with that physical safeguard, replacing it a signature algorithm. I first saw this in the mid 1990s where one major brand of computers has a "password" in the BIOS flash mechanism, that if it wasn't part of the upload, the machine wouldn't accept the code.
However, now, it has become a vector for permanent infection. Flash a SSD, motherboard, CPU, video card, keyboard, mouse, or any one of the tons of subsystems, and malware can become a permanent part of the computer. The closest thing I see to this is LoJack for Laptops which, if a BIOS setting is selected (and one set, it is there for good), it will always reload that program no matter what, when Windows is installed. Now, do the exact same thing, except with some ransomware, remote access Trojan. If the malware can access the iLO functions of most machines, it will have keyboard and monitor access for screen-scraping regardless of OS on the box, and has the ability to reformat/reinstall the OS at anytime.
So, what is the fix for modern computers? Can't really do a DIP switch or else Joe Sixpack will cut himself on the inside of the computer case and sue.
The fix is likely two fold:
1: The first something like a bootloader, which is something well tested, hardened against attack, and so on. It would be a v1.0 edition and burned into ROM. Yes, it can't be updated... but we had programmers deal with non-updatable code in the past. In fact, all PS1 games were architected and coded to never, ever need an update. It would be expensive, but this amount of code is relatively small, so it can be built secure.
This would be something that comes up with a certain key combination, and perhaps flashes a certain light pattern or color that the normal OS could never do (like a red LED instead of the normal blue /white one) This shows the user that they are in a "trusted" part of the computer, nothing else is running, nothing else can be run. From there, one can stick a SD card or a USB flash drive in a slot where the firmware to be upgraded is stashed and update from that, which would be signed, and if for some reason the core signing key was compromised, the device maker could have a manual challenge/response system to override it.
Another part of this would be the ability to revert to a "last known good" configuration as well as a burned in ROM. No, going back to a v1.0 BIOS isn't great for security, but it allows the machine to be up and running. Similar with storing 1-2 previous firmware versions that are signed.
The key is to have this feature be something that has to be done physically at the computer, and show the user in some telltale way that a fake OS isn't mimicking this screen. Of course, this "bootloader" would have to be extremely bug free at the outset, as it really couldn't be upgraded.
Of course, nothing is perfect. There is a need for remote upgrades in the enterprise, so having to go manually pop up a special menu on every single blade and server isn't going to cut it. This could be addressed via the standard iLO functionality on a management network.