Slashdot Mirror
Researchers Demo BIOS Attack That Survives Disk Wipes
suraj.sun writes "A pair of Argentinian researchers have found a way to perform a BIOS level malware attack capable of surviving even a hard-disk wipe.
Alfredo Ortega and Anibal Sacco from Core Security Technologies — used the stage at last week's CanSecWest conference to demonstrate methods (PDF) for infecting the BIOS with persistent code that will survive reboots and re-flashing attempts. The technique includes patching the BIOS with a small bit of code that gave them complete control of the machine. The demo ran smoothly on a Windows machine, a PC running OpenBSD and another running VMware Player."
used the stage at last week's CanSecWest conference to demonstrate methods for infecting the BIOS with persistent code that will survive reboots and re-flashing attempts.
The fact that the BIOS is in a chip is not news. News is they've infected it.
Any life is made up of a single moment, the moment in which a man finds out, once and for all, who he is.
OK, that bolded part is pretty cool and suggests a serious flaw.
Needing root privileges means that an attacker could put this code on another malware he writes, get an user infected and upload this to the bios. From that point onwards, if they can really disable the AV (both article and presentation are light on details), they can ensure that the box will remain infected, by injecting more code.
Think of it as a sure fire way to get people infect for a botnet without any recourse to stop it. Except updating the EEPROM of the bios (although I couldn't see how it can survive a re-flashing.)
--- "When you gotta do something wrong. You gotta do it right. (Fighter)"
Motherboard vendors typically use some form of protection, to prevent the 'normal' user from hacking into the BIOS Memory. In the old days, BIOS was in the 512K range, however many BIOS chips now sport 1 or 2 MB of space. This additional space is usually reserved for the nice big splash-screen image re-sellers throw up instead of having the PC sit and display the DOS boot messages (Memory test, speed, processor, Hard Drives, CD Drives, ect).
So, there is 'plenty' of memory space that is non-violatile, that lives on your motherboard that could be used to hide either multiple compressed malware programs, or a host of viri. The only way you would know if you were infected would be the obvious crash, or if you were wise enough to compare the sum-check of the BIOS that you loaded against the sum-check of what is in your BIOS memory chip.
But, the part they didn't tell you is that the BIOS memory chip may live in a variety of different places, it could be on the root PCI bus, or off the SPI bus, or hanging off the SMA bus. The virus loader would need to be smart enough to know 'where to look' and also have both Phoenix and Award BIOS passcodes/proceedures for this to be effective.
Once hit, the only way to get rid of it would be to re-flash your BIOS (assuming the new BIOS doesn't have a self-preservation routine built-in - Like disabline the ability to write the BIOS again).
Not totally,
In one hand:
Sacco and Ortega stressed that in order to execute the attacks, you need either root privileges or physical access to the machine in question, which limits the scope.
Which makes the attack more difficult in operating systems which do not allow users to run with Administrative rights all the time.
But the methods are deadly effective and the pair are currently working on a BIOS rootkit to implement the attack.
I can imagine that, everything you need is ONE time root access to "install" the BIOS instructions and fsck the machine. After that, you are pretty much in control of what comes next.
In some way, I find this similar to the viruses that infected the Master Bood Record, just a bit more interesting...
On the other hand, this will just trigger a bios-patch / virus-release cat and mouse game similar to the standard viruses.
Ubuntu is an African word meaning 'I can't configure Debian'
Not technically... some motherboards with dual bios chips can be set to fail over to the secondary bios, and from there you could re-flash the primary off of the secondary.
I've found Intel's EFI strategy to be annoying and fragmented. The EFI shell is very dos like, has very poor performance for the frame-buffer devices and leaves a lot to be desired. However, it is likely to become de facto.
I did enjoy most the ALPHA systems SRM. Alpha-SRM had quite a bit of features for a "BIOS" of sorts.
The Sun and Apple OpenFirmware (OpenBoot) systems was probably the closest the world got to a sane pre-boot environment. Openfirmware also has the distinction of being an actual standard IEEE 1275-1994. Unfortunately, they (Sun, Apple mainly) did not help the "linux guys" or the open community until it was too late and protected nearly worthless intellectual property for no good reason. (worthless in the sense its not monetize-able) .
Now I found from long ago the concept of PC BIOS annoying. The BIOS vendors, like Phoenix, American Magatrends, Award, have a lot of collusions with the motherboard vendors in terms of getting all the secret register-poking needed to get things going. There is a lot of black magic, legacy code and the like, but it works.
It will be very hard for a non-Pheonx-AMI-Intel vendor to come up with a new BIOS for the ages. The LinuxBIOS (coreboot) project, last I checked, and very poor support and no major vendor (e.g. Dell or HP) has looked into it seriously.
The world lost when EFI eclipsed OpenFirmware's chances of spreading. Now we are stuck with a half-assed DOS-like shell, a still-extant BIOS like menu screen that the Intel motherboards provide, and judging from the number of revisions and the release notes on the various Intel EFI boards, we may have been better off with AMI/Phoenix's secret sauce and black magic than this EFI cruft.
In the age of 2TB+ volumes it is probably inevitable that we are going to all be using EFI very soon (along with GPT).
I do not foresee Coreboot or OpenBIOS or OpenFirmware making any real progress in pushing out EFI unless Asus or Lenovo sees the utility in having a real pre-boot environment.
From what I get from the summary, what is new is that it only replaces part of the BIOS instead of installing a whole new one. If it can somehow tell which part it needs to replace on different model motherboards, then it may be able to spread further than older BIOS malware which is normally motherboard-specific.
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
i remember building a system around 2000 with a Gigabyte mobo that had this exact thing. dual bios in case something went wrong that could be selected using a jumped switch. i don't know what happened to them now though.
hardware solution is a must here. if the bios is patched with malicious code, you can't trust any of its settings.
also, the backup bios has to be read-only.
On a lot of systems, reflashing the BIOS is performed by code in ROM, precisely to prevent it from being overwritten. That said, this code is executed via an interrupt, and it may be possible to replace the interrupt vector in the flash part of the BIOS.
I am TheRaven on Soylent News
If you read the article, it is vulnerable to a bios you can flash, and access to that process (except on VM's where you are patching the emulator).
It seems to me that the hardware demo seems to rely on physical access to the machine. The VMWare demo would require access to the host OS.
LedgerSMB: Open source Accounting/ERP
ISTR firmware viruses infecting C64 floppy disk drives......
Nothing that would survive a power-cycle, though. That was before we had flash memory - it was either true ROMs or UV-erasable EPROMs.
Flash that can be re-programmed by "in-band" communication (vs. a dedicated maintenance channel like JTAG) is convenient but it is also very risky. I'm glad to see that this issue is getting more publicity. Maybe now we'll see a shift back to hardware write-protection, like a physical jumper inside the PC that has to be connected before you can re-flash the BIOS.
It's not just BIOS either. Your hard drive has reprogrammable firmware (see the recent Seagate bugs). Your wireless adapters (including bluetooth) may have reprogrammable firmware. There's plenty of opportunity for someone with the right knowledge to compromise your system.
I think my BIOS actually has an option for flash prevention, although I don't have it turned on. I remember I owned a board once that would only let you flash when the CMOS clear jumper was set. That was actually quite convenient because you should generally clear CMOS before a BIOS flash anyway.
Nick
The stronger constraint that you are describing is important under the US patent system, which (unlike most of the rest of the world) is first-to-invent (rather than first-to-file). Under this model, if you can demonstrate that you had a complete implementation first then you can not just invalidate the patent, you can get it assigned to you.
I am TheRaven on Soylent News
UEFI won't be vulnerable in the same way because it's not structured the same way.
If you RTFA, they're actually discussing a *very* old approach, just using newer tools and procedures. They're also not talking about the guts of the virus being in the flash rom, just a glorified hook/loader. They're talking about patching into the decompression module, then watching for INT10 to be available. If it is, it's fairly late in the boot process and time to jump to work. The proof of concept as presented basically just hooks around the OS and offers system-level CPU access to a hidden file or patched binary, depending on the OS.
If they get really advanced, they could write around the BIOSes own reflashing code, and/or patch the flash rom as it's being written. As presented, it will do nothing unless the infected HDD and infected BIOS are in contact.
Back to UEFI: You could drop this payload as an app on UEFI, and you could try hacking around inside UEFI itself, but the exploit as presented is very very low tech and relies on the abysmal security of traditional firmware (checksums only). UEFI is a little bit more secure when it comes to tampering with the firmware in place.
The main reason I pooh-pooh this article is that it's repacking and re-presenting a very old exploit method as if it is new.
Also, to address your comment more directly: It's not the 'unified' or 'open' part of UEFI or OpenFirmware that makes them immune, it's that they are differently laid out and a little more secure than traditional BIOS.
Also, even though most motherboards no longer come with flash write protect jumpers, they do come with BIOS-based flash protections, which should be suitable to this task. Disable flash updating in your BIOS and the exploit can't get in. Need the exploit to bypass the protection, and the protection prevents the exploit.
The preceding comment is my own, and in no way construes an opinon of the Emperor of Mankind.
Sounds like someone who does not do this stuff for a living, or works only on PCs. Trust me you want to be able to flash a reboot servers remotely sometimes. Its not the kind of thing you can do during the day in a production world, and I for one don't like spending all night at the office.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html