Researchers Demo BIOS Attack That Survives Disk Wipes 396
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."
I've already had BIOS malware (Score:4, Funny)
preinstalled, on ASUS boards: it was the BIOS itself. It too survived hard disk wipes, but it didn't survive my sledgehammer.
Requires root privileges or physical access (Score:5, Interesting)
"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."
Hmm, I'd say you are pretty much pwned in that case even before the attacker infecting the BIOS.
Re: (Score:2, Insightful)
Re: (Score:3, Interesting)
I think the point is that once this happens that you cannot fix it by reflashing the BIOS.
Would something like OpenBIOS help?
Re:Requires root privileges or physical access (Score:5, Funny)
Re: (Score:3, Interesting)
It doesnt require physical access, it requires root level access, ie ring0 (which can almost always be gained trivially when you have physical access) even if you have to swap the hard disk for one that contains your malicious code.
Re:Requires root privileges or physical access (Score:5, Informative)
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.)
Re:Requires root privileges or physical access (Score:5, Insightful)
(although I couldn't see how it can survive a re-flashing.)
Presumably reflashing the BIOS is normally performed by code within the BIOS. If you can corrupt the code in the BIOS you would have control over the flash programming, so could prevent the user from overwriting the infected blocks. I doubt this refers to physically removing the PROM and reflashing with an external programmer.
Re:Requires root privileges or physical access (Score:5, Informative)
Re: (Score:3, Informative)
also, the backup bios has to be read-only.
Re:Requires root privileges or physical access (Score:5, Insightful)
Getting root (administrator) privileges in Windows appears trivial for most current malware, so getting to the BIOS is not that hard from there.
It makes me more wonder why doesn't a motherboard have a jumper that disables BIOS updates? That would be quite a strong safety measure. Anyone capable of knowing why to, and how to execute a BIOS update is certainly capable of opening/closing that jumper for the procedure.
Re:Requires root privileges or physical access (Score:5, Interesting)
It makes me more wonder why doesn't a motherboard have a jumper that disables BIOS updates? That would be quite a strong safety measure. Anyone capable of knowing why to, and how to execute a BIOS update is certainly capable of opening/closing that jumper for the procedure.
I've been thinking that this is necessary ever since I lost a nearly-new DVD Rom drive to a rogue piece of software that managed to wipe out one bit in sixteen of the drive's firmware.
Re: (Score:2)
The BIOS isnt protected because the guys in the black helicopters have been doing this for years.
Re: (Score:2)
Re: (Score:2)
Here, LMGTFY [google.com].
Re:Requires root privileges or physical access (Score:5, Interesting)
I've been using Windows based BIOS flashers for a decade. It was originally a feature limited to enthusiast boards but now it's standard. You can even sometimes flash from within Linux for boards that support it via /dev/nvram.
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
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.
Re: (Score:3, Insightful)
Because adding that useful safety feature might cost a WHOLE NICKLE!!
Similarly, I have seen a number of chipsets where the top and second from top erase blocks can be swapped just by pulling a logic line down (with a jumper for example). The idea is that even a screwed up re-flash of the boot block can be recovered easily just by setting a jumper.
Too bad I have NEVER seen a board that actually hooked that line up nor a BIOS image that had a second emergency boot sector programmed.
Re: (Score:2)
Re: (Score:2)
It does not make privilege escalation easier, it just makes it more serious.
Re: (Score:2)
The problem is that even if you follow the recommended procedure for when a virus is discovered, wipe and reinstall from backup or fresh from the install media, you're still screwed.
If the virus is smart enough to lay low for a while when you do that, it could become a truly maddening 'recurring' infection in spite of following best practices (after the initial infection, of course).
Re: (Score:2)
if your BIOS password were changed, you'd be out of luck
Or you could reset the BIOS with the jumper or by unplugging and removing the CMOS battery. Unless said hijack somehow creates a permanent BIOS password, in which case you'd be totally screwed.
Re: (Score:3, Informative)
Re: (Score:2)
This would be fine if your BIOS chip were a field replaceable part, but mine is soldered to the motherboard itself!
Re: (Score:2)
Every motherboard I've ever worked with either had a BIOS reset jumper or the CMOS battery was removable. The settings entered into the BIOS configuration screen are not normally saved to the Flash ROM, but are stored in CMOS and kept alive by the battery. If you remove the battery or use the reset jumper procedure, it kills power to the CMOS and the settings are cleared, this normally includes the BIOS password.
Also, I just reread my post and realized that you might have misunderstood. I was referring to r
Re: (Score:3, Insightful)
Every motherboard I've ever worked with either had a BIOS reset jumper or the CMOS battery was removable.
You've never worked on a laptop.
Re: (Score:2)
Fatal flaw: No BIOS reset (Score:5, Insightful)
If BIOSes, CPUs, and other low-level software had factory-reset pins that could not be bypassed through patching, we wouldn't have these problems.
If the pin is set during POST, the CPU, BIOS, or whatever would reset itself to factory conditions. The device would be configured so the factory-reset sequence could not be tampered with through software updates alone.
Re:Fatal flaw: No BIOS reset (Score:5, Insightful)
This is why there should always be 2 copies of the BIOS. One that is physically read-only and contains the BIOS as shipped. And another writable one that can be disabled with a jumper. If your BIOS is corrupted or hijacked, you could always go back to the backup BIOS and restore.
An alternative would be replaceable BIOS chips like the ones from the days before writable BIOS. If a customer gets a BIOS corruption or virus, they could call and order a replacement and not have to buy a whole new mobo. That would also be a good way to distribute BIOS updates to people afraid of bricking their system.
Re: (Score:3, Insightful)
Or a friggin' write-protect jumper on the flash, which is actually present in the PCB wiring of most motherboards but 99% of the time the manufacturer is too cheap to solder on the pins. Actually it's not the 1 cent manufacturing cost they save but the zillions of tech support calls from clueless users desperate to reflash their BIOS (usually for no good reason) but unable to locate the WP jumper with both hands and a map.
Hardware flash WP has been high on my list of mobo spec priorities for years but it's
Re:Fatal flaw: No BIOS reset (Score:4, Insightful)
Probably most customers didn't care about the feature compared to what it cost to implement. I do wish this was standard though.
Re: (Score:2)
Is the backup BIOS writable? If not, then perfect! If yes, then it would help protect against BIOS update failures, but might not against an attack like this.
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Add another layer to your tinfoil hat?
No surprise (Score:5, Interesting)
Of course you can infect a BIOS. It has drawbacks, however. One is very limited space. A second one is that BIOSes flash differently on different mainboards. Maybe not too differently, which would be a real problem. Hoperfully, there is not enough space in the average BIOS for self-relication (which would need exploit code and flasher code at least).
The fact that this is possible is mildly entertaining, nothing revolutionary. Would have been possible (and obviously possible) with the first Flash BIOSES around.
Re:No surprise (Score:4, Insightful)
Them Old Time Viruses ran with a lot less then what modern BIOS have, so I wouldn't focus to much on size to save us.
When the Virus initially runs it is probably in the Hard Drive to the RAM which can can fit a LOT of configurations to break into a lot of BIOS manufactures.
Re: (Score:2)
The old viruses sometimes fit into 300 bytes floppy boot code. But these did not need any exploit (i.e. attack) code, no network functionality and no flasher code.
While very small worms are possible today (think Witty which was about 470 bytes worm code), whou cannot do a lot with them, certainly not include a generic FLASH writer.
Re: (Score:2)
There are OpenSource tools which handle re-flashing of most BIOSes.
Also, there are just a few BIOS manufacturers. So it might be not that hard to write semi-unversal code.
Now I wish my computer had a TPM module....
Re: (Score:2)
Re: (Score:2)
The virus could check if the motherboard is compatible with coreboot [coreboot.org] or something similar before flashing a modified version. If coreboot can boot a linux kernel directly without any other bootloader, it is likely possible that the average BIOS has enough room for self-replicating code.
I do agree that it is not revolutionary, I've heard of BIOS viruses for a while, but the general consensus was that they are too motherboard-specific to be of any real threat. However, coreboot claims it is supported on over
Re: (Score:2)
Flash code can be crammed into 50 bytes or less, counting the code that sets the GPIO lines to allow the flashing.
The part that determines which MB you have and loads the correct 'driver' can be fetched over the net. Many BIOS images have over 16K of free space on the chip. That's well more than enough for a polling UDP network stack (w/ DHCP), code to exploit the SMM vulnerability, and patch the bootloader.
A simple jumper on the write enable line of the flash chip could stop BIOS infections cold, but that
Re: (Score:2)
Only if you consider it as a stand-alone virus.
Most of the viruses today are able to integrate different viruses. First you get infected with a 0-day exploit and then the virus will download what it needs to further fuck you up.
That needs at least working networking code, loader code (the download has to go somewhere) and startup code. Still, I agree that this would be a necessary design decision to do anything useful with malcode in FLASH.
PDF (Score:5, Funny)
Re:PDF (Score:5, Funny)
Or, you really need to take off the tinfoil hat.
Re: (Score:2)
great! Now I am a botnet zombie.
BRAAAAAIIIINNSSSSSS
Re:PDF (Score:5, Funny)
Re: (Score:2)
Re:PDF (Score:4, Interesting)
Perhaps you haven't seen Pontypool [wikipedia.org], a Canadian horror film about a virus that adapts to transmit itself through language. The film itself treats the premise as improbable but the best fit for the observed circumstances.
I liked the film most because of how much imagery they convey through the lack of film footage; the story centers around a small-town morning radio team and what they hear and broadcast. Almost everything is left to the imagination. As I was watching it, all I could do was think back to Cloverleaf and how Pontypool was the same thing, but better, because shakey-cam was replaced with no-cam.
I know this one (Score:2)
Re: (Score:2)
Mostly come at night?
Re: (Score:2)
why is it OS dependant (Score:2)
Re:why is it OS dependant (Score:5, Funny)
Come again? (Score:3)
I was with the summary until that last part... A windows machine, I can accept that. An OpenBSD machine, I can accept that too. But another machine running VMware Player? Thats not an OS, so I don't even know what they were trying to say.
Re: (Score:2)
It isn't but it certainly simulates a BIOS to the guest OS. My guess is they infected the simulated BIOS.
This seems curious to me - why on Earth would VMWare want to make a virtual BIOS "flashable"? (in inverted commas because it's not a real BIOS so it isn't flashable in the true sense of the word)
Limited scope (Score:3, Interesting)
Not only do you need root or physical access, you also need the victim to be using a particular type of BIOS. While you could abstract this up to a module, so that it nailed all Phoenix BIOSes, or all Award BIOSes, you'd still need semi-specific payloads for each BIOS OEM. Also, you'd need the target to be using a mainstream commercial BIOS, not UEFI, OpenFirmware, or anything similar.
UEFI will be here and widespread very soon (it's in some machines already, and more every day), and the only real power this 'new' malware has is the persistence/difficulty in removal.
Not impressed.
Re: (Score:2)
Grab BIOS signature, send query to server in wheresthatistan, receive back instructions and code for that configuration.
Re: (Score:3, Informative)
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
How fun! (Score:3, Interesting)
And here I thought that all the virus writers were just wimps using XSS and Word macros to run generic malware. I wondered where the old school BIOS viruses had gone.
there were number of BIOS attacks (Score:2, Interesting)
Can someone explain... (Score:2)
I thought since that really nasty virus that would brick PCs by writing to bios' that every mobo maker put in write protection that, if enabled, would halt the system when something tried to write to the BIOS.
Wouldn't this prevent this kind of attack?
Re: (Score:2)
Most of them depend on SMM/SMI to 'protect' the BIOS. There's an exploit out there that can overwrite the SMM and nullify that protection.
When can I expect the commercial version? (Score:3, Interesting)
Let me get this straight:
It pretty much requires physical access and root. If a malicious person gets that sort of access, I'm screwed anyway.
Ok, so I'm not too worried about anyone installing this on my computer without my knowledge.
What I am interested in is the sort of equipment-tracking possibilities this creates. If I could install a tracking rootkit on a laptop which could silently persist and survive disk wipes and ROM flashes, automatically reporting in whenever it gets net access, it would be a huge advantage if the machine were ever stolen. An OS reinstall is likely, because it's a simple way to circumvent the user account password, but this would even protect against a BIOS flash (which is less likely, but still not out of the question).
Eventually, somebody somewhere would hook the laptop up to the web, probably with a completely fresh OS install, and a subpoena on the IP would reveal their location.
Re: (Score:2)
Let me get this straight:
It pretty much requires physical access and root. If a malicious person gets that sort of access, I'm screwed anyway.
You are but you can be un-screwed by reloading the operating system and restoring data from backup (being careful not to restore whatever it was caused the compromise in the first place, of course).
This effectively neutralises your ability to do that.
Re: (Score:2)
What I am interested in is the sort of equipment-tracking possibilities this creates. If I could install a tracking rootkit on a laptop which could silently persist and survive disk wipes and ROM flashes, automatically reporting in whenever it gets net access, it would be a huge advantage if the machine were ever stolen. An OS reinstall is likely, because it's a simple way to circumvent the user account password, but this would even protect against a BIOS flash (which is less likely, but still not out of the question).
Interesting indeed. It would also be invaluable for rental companies that lease out computers.
Re: (Score:3, Interesting)
Yeah, I know that such things exist, but they don't protect against a disk wipe and re-flashing the BIOS, which this apparently does. I'm sure the companies that make that sort of tracking software would love to get their hands on this.
Re: (Score:3)
TFA said "survive reboots and re-flashing attempts". I was merely wondering how long it would be until the existing commercial applications manage to incorporate that feature.
I wasn't aware that the lojack was being included in default installs, though. Do you have any way to back up what you're claiming?
Doesn't affect me (Score:5, Funny)
And the NSA hasn't been doing this for years? (Score:3, Insightful)
You're being watched . . .
Re: (Score:2)
Re:Of course. (Score:4, Informative)
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.
Re: (Score:2, Informative)
Re: (Score:3, Interesting)
Sounds like they've somehow written a BIOS that detects code that would overwrite it and either kills the code, causes it to silently fail, or silently infects the new BIOS.
Obviously a failed BIOS flash would be suspicious; a silent fail would be slightly harder to notice. If they could somehow infect the new BIOS, it'd be truly devious and almost impossible to detect.
Re: (Score:3, Interesting)
ISTR firmware viruses infecting C64 floppy disk drives......
After reading the article, I don't think this is novel or new, rather a friendly reminder that firmware viruses are still a potential threat.
Re:Of course. (Score:5, Informative)
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.
Re:I guess it's official. (Score:5, Funny)
It's official - we're screwed.
Happy news for most of the nerds on this site who sigh and collectively whisper "Finally!"
Re: (Score:2)
Happy news for most of the nerds on this site who sigh and collectively whisper "Finally!"
Don't know about you, but I like to be the one doing the screwing.
Re: (Score:2)
-1, Ewwwww
Re:I guess it's official. (Score:5, Insightful)
We've had evil viruses around for a while. Anyone remember
W95.CIH [symantec.com]? Back in the Windows 95 days, this mean son of a bitch could nuke your BIOS from orbit. And we're talking over a decade ago.
Computers are still chugging along fine. This will probably end up breaking more computers than it ends up hijacking. A broken computer is one that gets flagged and fixed or throw away.
Re: (Score:2)
If it works well then it will silently infect lots of machines...
A virus that destroys it's host is pretty ineffective at spreading because it gets noticed and destroys it's host that might have been usable to bring it to more victims.
Re:I guess it's official. (Score:5, Interesting)
Heh this did happen to me a few times, very cool virus. From then on I pulled my BIOSes and cut the write-enable pin off the chips, no problems then.
Re: (Score:3, Interesting)
Re:I guess it's official. (Score:4, Informative)
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.
Re: (Score:2, Funny)
Re: (Score:2)
What were the editors thinking of when they wrote "perform unveil"?
Perhaps they just executed a landing procedure. Flown recently? The amount of official sounding meaningless BS they come up with is mind boggling.
Re: (Score:3, Informative)
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
Re: (Score:2)
Virtually none of the real-mode code in the BIOS is ever used anymore. Any system that can boot DOS bare-metal would have plenty of room for code that is never used on normal systems.
Re: (Score:2)
If it replaces anything it would probably be the hardware controls that a modern OS normally controls directly. So you could keep a copy of DOS handy and if it stops working with some bit of hardware then you may be infected.
Re:Intel only? (Score:5, Interesting)
Better question is what typeof BIOS? Is EFI vulnerable? How about open firmware? Or is this limited to just plain ole BIOS that should have been killed a decade ago but remains as msft doesn't support anything else for most versions of it's OS?
Re:Intel only? (Score:4, Informative)
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.
Re:Intel only? (Score:4, Insightful)
Better question is what typeof BIOS?
Your many hours of programming C/C++ betray you :-)
Re: (Score:3, Interesting)
Now that a researcher has done it, and made that knowledge public means it's only a matter of time before we see real ones in the wild.
I almost find it hard to believe those idiots did this. It's been an unwritten research area for decades because of the known risk.
(Or more accurately, what the unintended effect would be, the eventual creation of a BIOS infector.)
Sounds like you're advocating security through obscurity? I'm not a computer security expert but it seems to me that keeping a research area unstudied for this reason is not the best approach to any kind of intellectual endeavor.
Re: (Score:2)
Re:Tsarkon Reports Obama bent on bankrupting USA (Score:5, Informative)
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.
Re: (Score:3, Insightful)
Does anyone use EFI outside of Apple and IA64 based machines?
Microsoft don't support EFI, even tho Vista promised support for it... EFI is really only of benefit to run OSX or possibly Linux.
Re: (Score:2)
But most computers already are pre-installed with a Faraday cage, at least the ones with compliant power supplies and a conductive case.
Anyhow, it's just not physically possible to overwrite an EEPROM or any semconductor storage medium with a blast of induction.
Re:Been around for some time... (Score:4, Informative)
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.
Re: (Score:2)
You mean, like the BIOS-induced "Flash Write Protect" option in virtually every single BIOS ever made in the last ten years or so?
Re:IANABPE (I am not a BIOS programming expert) bu (Score:2)
Why the heck not? They used to be the standard. But, people found it ANNOYING. So, it's a much touted feature that the modern BIOS can be rewritten by anybody, without direct access to the machine. My first flashable BIOS, you had to make a boot disk with the new BIOS image, and flashing tool. Then you had to turn the PC off and open the case. Then you ha