Does the Mebromi BIOS flashing rootkit mean APTs for personal computers are here?

Question

With the recent discovery of the Mebromi BIOS firmware virus/MBR rootkit in the wild are we now actually in the age of Advanced Persistent Threats (APT) for personal computers and does that imply the malware solutions of the last two decades are obsolete?

The APT term has been thrown around for some time in reference to state-level attacks like Stuxnet or cooperate-foundation-shaking events such RSA SecureID, Sony PS Network, and the recent PKI CA compromises. This discovery appears to differ from those events.

Those high value target events all either needed an APT attack to penetrate the layers of defense or the story of same to protect the reputation of the victim. Unlike those high value targets, the Mebromi virus is designed to work against mundane PCs with the Award BIOS running the previous generation of the Windows OS. The technology employed has been seen separately and discussed in theoretical papers. This forum has cogitated over the theory vs. reality nature of firmware flashed attacks in the last few months relative to video card firmware persistent attacks. Is it time to consider that debate over and declare viable, zero day, common user system APTs are here? If so, is it not also time to reevaluate the find, patch, rinse, and repeat method of malware protection?

Answer 1

First, APT does not refer to exploits, rootkits etc., but to the threat actors and the organisation behind them.

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 compromised machine may require cleaning at firmware and hardware level, not just OS.

Answer 2

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.