That said, bios and firmware attacks have been around for a while. The only change here is > the same one any class of attacks goes through: they have become commoditised.
This doesn't change the approach of find, patch etc., but it does mean that a c>ompromised
machine may require cleaning at firmware and hardware level, not just OS.
Respectfully, I disagree. I had encountered the previous generation of BIOS flashing malware some years ago, and they presented no real change in principle. One merely had to flash the BIOS or infected firmware and low level wipe the disk before reinstalling.
In contrast, as a SR Sys Admin, with many years experience with forensics, I have been completely ruined, shamed, my-show-run by the latest gen of Platform Independent Firmware/GPU Based Paravirtualization Hypervisors.
The only solace I can take from the experience is at the cost of having to basically throw away, or sell (for whatever was offered to whoever was foolhardy enough to take it after my warnings) 4 Desktop computers, a somewhat aging SBS server, and all attached peripherals... I have had to over the past several months elevate my own game a couple quantum leaps to even make coherent sense of what was going on.
However, my point is - that there is some fundamental rethinking of strategy/approach that this emergent class of malware demands of us. Because one cannot feasibly and simply start the cleaning process at firmware, and work their way up from there. The Mebromi, and even worse: Rakshaksha / TDL4 firmware variants that are in the wild right now include infections, such as mine, which effectively appaer to be flashing copies of the very small core germ of the infection to all attached peripheral firmware. The BIOS itself as you recognize is it appears to be virtualized. CoreBoot & SeaBIOS are running underneath it. The malware has drivers for 16bit DOS, Linux, Windows and BSD, similarly flashing from your BIOS UI all amount to flashing a Virtualized BIOS. However, a hardware blind flash with the appropriate bin image did appear to work. BUT... at next post a cursor sat there for about a minute, a few carriage returns later, the system restarted, and the legit BIOS was back under CoreBoot/SeaBios & hypervisor again. The GPU had flashed it. I repeated the process. removing the GPU, the onboard Video did the same thing. And if I were able to clean somehow seperate and Flash GPU and BIOS in the same reboot cycle before reuniting them (without unwittingly infecting the machine i used to to flash the GPU) ... I would discover the Firmware on any of the HDD, Optical Drive, NIC, even my router's ROM, would reintroduce the infection in short order. I met a few others with this same variant on a thread on the sysinternals forum, where 1 or 2 posters were initially met with incredulity until 1 by 1 others found the thread and corroborated the experiences. Two such posters had even BIOS and bootsector code/data in all their PCI ROM. From what i've gathered, with current technology and the pace malware removal/detection/defense products and practices being a good 6-18 months behind the badguys. There does not appear to be any financially or practically feasible way of removing an infection of this sort short of taking absolutely everything the system has touched that has NON Volative Writable memory and flashing it all in isolation from each other, and then reintegrating. Or somehow flashing them all in the same reboot cycle.
I even managed to spread this infection onto my IPhone unwittingly and unbenkownst to me, a week or so later, I put up a personal hotspot for tethering access to my cellular internet connection via Wi-Fi for a friends laptop. 10 minutes lataer his system became unstable and restarted, whereupon I immediately started seeing the hallmarks of the infection on my own machines. Later I found another machine i was working on had a strange active to bluetooth connection to a MAC address I recognized. I pulled my phone out of my pocket and confirmed Bluetooth was turned off in the settings and also confirmed that it was nevertheless the MAC address of my IPhone's very much disabled BlueTooth adaptor that this machine had somehow auto-paired with. We had to replace that users computer as well. Whereas in the case of a couple other machines, for reasons i'm not clear on - we seem to have been able to somehow wall in the rootkit, and prevent it from either contacting C&C or sucessfully downloading the additional packages (via iSCSI & BITS among others) that it appears to deploy in its GPU ROM/ System Memory FileSystem, which you can sometimes catch for about a second or two before it reparses.
Yeah... i'd say we have to as an industry re-evaluate how to approach these things. Because the conventional tactics basically kill months of productivity and get you about as far as questioning your own sanity, unsure of what is definitely happening, and which inferences are shaky or will lead you down the wrong branch... and ultimately wont get one much farther than knowing that something is definitely very wrong.. but short of physically removing and evaluating the ROM/BIOS, unable to determine exactly what you're dealing with.