Malware in BIOS stirs concern at Black Hat meet

(Phys.org) -- Security researcher Jonathan Brossard has drawn attention to a backdoor espionage problem that is in an ornery class by itself. Presenting his finds at the recent Defcon and Black Hat events, Brossard has shown that any snooper placing rogue firmware on your computer basically owns you forever. Brossards proof of concept is bracing news for security professionals in public and private sectors. The importance of his research is that this kind of back door allows secret remote access over the Internet, no matter what the attempt might be to switch the hard disk or reinstall the operating system; such moves will not help.

The backdoor that Brossard created, Rakshasa, is according to Brossard a generic proof of concept malware for the intel architecture. This is also what he refers to as permanent backdooring of hardware.

Installed into the computers BIOS chip on a motherboard it can compromise the operating system at boot time without leaving any traces on the hard drive. A computer's BIOS chip contains the first code, or firmware, which a computer runs when it is powered on to start the process of booting up the operating system, as explained in Technology Review. Brossard tested his deliberate misdeed against 43 antivirus programs and he found that none flagged his move as dangerous. The malware can also affect other peripheral devices such as network cards or CD-ROMs.

Brossard built Rakshasa by drawing on open-source software packages for altering firmware. He used (nonmalicious) Coreboot, SeaBIOS, and iPXE. Coreboot was used to re-flash the BIOS with a SeaBIOS and iPXE bootkit.

Aside from relative permanence, the other concern deals with big-picture what-ifs for government to government spying. Computers manufactured overseas at the factory or warehouse stage can be injected with malware at the time of manufacture.

While there is no evidence of such attempted espionage by hiding surveillance tools inside new equipment, the question is raised whether something like Rakshasa, which refers in name to a demon from Hindu mythology, could be used to infect the BIOS before a computer is delivered to its overseas consumers.

The good news is that this fiendish takeover ploy has a remedy. The bad news is that the remedy would seem daunting for those with limited knowledge of computers. One could get rid of the malware by acting to reflash both the motherboard and all peripherals at the same time, The x86 architecture, according to Brossard, is plagued with legacy.

He recommends that when you get a new laptop to reflash all these dodgy firmware that you don't understand, and which you can't understand, because it is proprietary, with open-source stuff that you can actually understand."

Brossard also said he hoped his research will raise awareness of the security community regarding the dangers associated with non open source firmwares shipped with any computer and question their integrity.

Related Stories

(PhysOrg.com) -- In science, one of the issues of great interest is that of quantum computing, and creating a way to make it possible on a scalable level. This could be achieved by taking advantage of the strong interaction ...

A new publication from the National Institute of Standards and Technology (NIST) provides guidelines to secure the earliest stages of the computer boot process. Commonly known as the Basic Input/Output System (BIOS), this ...

(PhysOrg.com) -- Security experts Sergey Golovanov and Igor Soumenkov of Kaspersky Lab have detailed the threats of a new strain of the TDSS botnet, dubbed TDL-4, on SECURELIST, calling it likely the most sophisticated botnet ...

(PhysOrg.com) -- Research consultant Charlie Miller, currently with Accuvant Labs, has made it known that he intends to demonstrate a security hole in certain Mac laptops at next months Black Hat security conference. ...

A new draft computer security publication from the National Institute of Standards and Technology (NIST) provides guidance for vendors and security professionals as they work to protect personal computers as they start up.

Recommended for you

It sounds like a science-fiction nightmare. But "killer robots" have the likes of British scientist Stephen Hawking and Apple co-founder Steve Wozniak fretting, and warning they could fuel ethnic cleansing and an arms race.

A startup team calls their work a product. They also call it a social movement. Many people in the over-7,000 islands in the Philippines lack access to electricity .The startup would like to make a difference. Their main ...

Are some people fed up with remembering and using passwords and PINs to make it though the day? Those who have had enough would prefer to do without them. For mobile tasks that involve banking, though, it is obvious that ...

67 comments

Installing however is going to be harder than just clicking a link or inadvertently running a piece of malware. It needs physical access. It can be detected when recognized as a threat and search for. Any foreign company that was stupid enough to supply infected PCs would never be able to export a computer again -- it would be commercial suicide.

Installing however is going to be harder than just clicking a link or inadvertently running a piece of malware. It needs physical access.

You can flash a BIOS with software. This can be done remotely. Contracting this sort of virus is no more difficult than any other type of virus. From that ponit on the virus is undetectable, unless you come in with an external hardware that reads out the BIOS (and maybe not even then).

And what's to say you won't infect your BIOS with malware WHEN you flash it. It might have been clean before but not afterwards.

That would be entirely your fault. Brossard recommends flashing with open source firmware you can understand, if instead you flash with stuff you can't (or if you yourself can't understand code) and get infected then tough luck. Be smarter next time and get someone knowledgeable and trustworthy to do it for you.

There is a simple, foolproof solution that will never be implemented: a hardware interlock to enable BIOS flashing. A button on the machine that had to be pressed before each flash would block this attack.

This isn't standard, today, but if you manage to get government agencies to buy stuff with this 'feature' you're as good as in. (Either getting them to buying it knowingly "because it makes IT easier - as they can update your BIOS when needed"...or include it on your board as an undocumented feature)

That's neat, but it has what is basically a hardware interlock like John Hasler was talking about... someone has to physically connect a USB cable to the motherboard and upload the firmware from a DIFFERENT computer system... I don't see how this qualifies as being vulnerable to a regular virus as you implied.

You can perform the install without a reboot, the reboot just allows the new instructions to execute so that the changes 'take effect', there's no reason why you can't do the flash at any time and just casually wait for the next reboot.

So again if you read carefully, you can perform the install itself without a reboot, the changes may not yet take effect, but that's just a matter of time (in a corporate environment it'll be a short wait).

That's just silly, why would I install firmware which has malware? I don't think you understand how this works. The point would be to use open source firmware or go straight to the manufacturer of the hardware to get the original firmware instead of the 'potentially tainted stuff' from Dell/HP/etc.

Correction: It appears you can loop the USB cable to the same system and use it to upload the new firmware to itself while running... so I was wrong about that, but it doesn't change the fact that the cable must be connected, so 100% foolproof virus protection is as simple as not leaving the cable plugged in...

You can perform the install without a reboot, the reboot just allows the new instructions to execute so that the changes 'take effect', there's no reason why you can't do the flash at any time and just casually wait for the next reboot

Because the OS doesn't allow programs access to that hardware... no?

In a modern OS all hardware resources are virtualized by the system, rogue applications would have no idea the memory mapping of the hardware they are interested in UNLESS they get this information from the OS, which it will not provide for security purposes... Are you talking about Linux or Windows?

I think you are right -- BUT it's been a while -- over 7 years - since I flashed my BIOS because it could not recognize hard drives above 4 GB.

Anyway I think i remember that you have actually leave your OS to flash the BIOS. You boot into the falshing software -- or maybe i did it through the command prompt in windows, but I don;t think so. I think I had to not have loaded into Windows to flash my BIOS... its to low level for the permissions windows allows.

Deathclock: I've had to download an updated bios for my ASUS motherboard several times due to things like certain brands of HDDs not working properly (specifically mentioned as "fixed" in a later version of ASUS's BIOS release notes that I downloaded).

Anyway, here's all I had to do:

1) Go to ASUS's site and search for my motherboard.2) Click the download link.3) Run the ASUS's BIOS flash program from within Windows.4) ... actually there are only 3 steps. The first time I did it I didn't bother rebooting, because I was doing something else that I didn't want to stop. Updated BIOS took effect the next time I rebooted.

No special steps are required to flash the BIOS on a modern computer. They've made it super, super easy. Click a link and *boom*, done.

That's neat, but it has what is basically a hardware interlock like John Hasler was talking about... someone has to physically connect a USB cable to the motherboard and upload the firmware from a DIFFERENT computer system... I don't see how this qualifies as being vulnerable to a regular virus as you implied.

You can do it via USB or a LAN. Think of it this way:User X contracts a (regular) virus on his machineUser X is connected via LAN to other machines.The machine of user X then starts flashing the BIOS of other machines in the LAN (and one of the machines then flashes the machine of user X to make the penetration complete)

Correction: It appears you can loop the USB cable to the same system and use it to upload the new firmware to itself while running... so I was wrong about that, but it doesn't change the fact that the cable must be connected, so 100% foolproof virus protection is as simple as not leaving the cable plugged in...

the presence of hardware in the OS can be faked for example "Oracle VM VirtualBox" emulates an entire computer (with obvious exceptions), this type of software has been around for decades and i have no doubts that there are probably malicious programs which emulate hardware

I think you are right -- BUT it's been a while -- over 7 years - since I flashed my BIOS because it could not recognize hard drives above 4 GB.

Anyway I think i remember that you have actually leave your OS to flash the BIOS. You boot into the falshing software -- or maybe i did it through the command prompt in windows, but I don;t think so. I think I had to not have loaded into Windows to flash my BIOS... its to low level for the permissions windows allows.

This is what I remember too, but I, like you, haven't done this in a while... and I believe what other people are saying about how this is not required anymore, so I will bow out of this conversation due to my knowledge probably being outdated since I haven't reflashed a BIOS for 3-5 years probably.

A checksum would have to be separate from the firmware, otherwise the malicious individual would simply change the checksum to match their rogue code... Firmware publishers, the manufacturers of the BIOS chips, could list checksums on their website, and then the user would have to use a trusted utility to generate the checksum of the firmware image prior to loading it and compare it against the published one on the manufacturers website... but from what I can tell the concern is that these firmware updates can take place behind the scenes without your consent (which really surprises me but you guys have convinced me it's possible).

Is there any way to do something like a checksum you see on RAM but instead on the bios? Can it be read out and checked if the bits are the same as a benign one?

Where would the checksum be stored? A ROM might do it - but then you could never legitimately update your BIOS (in that case the BIOS may as well be a piece of ROM itself).

Maybe encryption could help. (I've not fully thought this one through, but here's a first idea)Encrypt the BIOS with a two part key (as in PGP).In that case the 'public' key based on your BIOS ID would be only known to the vendor. To get an update you request a file from the vendor encrypted with that key.You hold the private key that lets you decrypt the BIOS but not encrypt a file in a manner that would allow flashing it onto the BIOS.A hardware chip with the private key (ROM) checks the file for validity beforehand and signs it (and also decrypts the BIOS instructions on startup). Only files with valid signature can be flashed.

@deathclock Anyway I think i remember that you have actually leave your OS to flash the BIOS. You boot into the falshing software --

With full administrator permissions software running under any OS can do anything that software booted "standalone" can do. It's a matter of writing to the correct addresses and I/O ports.

It's a matter of determining those addresses and ports, which are not consistent. The BIOS itself enumerates hardware resources for the OS at bootup, if software running under the OS wants to know the memory mappings for a piece of hardware it has to either ask the OS or ... What? Guess and check, and in the process potentially do damage to other hardware?

This isn't standard, today, but if you manage to get government agencies to buy stuff with this 'feature' you're as good as in. (Either getting them to buying it knowingly "because it makes IT easier - as they can update your BIOS when needed"...or include it on your board as an undocumented feature)

As I see it, the word "Remotely," as used in the cited article, is improperly used. What DFI did with this is that if you were no longer able to boot your computer because of a failed BIOS update, you could still reflash the firmware from a USB port. In no way, though, is it possible flash the bios without physical access to the computer.

With BIOSeSecure, you can plug in a USB cable and reflash the BIOS remotely.

It is not possible to plug in a USB cable without physical access to the computer.

This isn't standard, today, but if you manage to get government agencies to buy stuff with this 'feature' you're as good as in. (Either getting them to buying it knowingly "because it makes IT easier - as they can update your BIOS when needed"...or include it on your board as an undocumented feature)

I suspect that Openmanage is likely specific to Dell. Now there's a possible exploit for a hacker and one more reason to avoid dell. ;)

As to USB flashing, most motherboard manufacturers have that ability, the question would be what can you do if you can no longer boot your computer because of a failed bios update.

The BIOS itself enumerates hardware resources for the OS at bootup, if software running under the OS wants to know the memory mappings for a piece of hardware it has to either ask the OS or ... What?

The BIOS itself. That's what it's there for: a Basic Input Output System.

Older operating systems just made a BIOS call whenever they needed something. Today the operating systems can figure things out themselves, so they don't technically need the BIOS after they've booted up. But it's still there, and will answer if you call it. Calling the functions while the operating system is running may result in a crash, though.

The BIOS itself enumerates hardware resources for the OS at bootup, if software running under the OS wants to know the memory mappings for a piece of hardware it has to either ask the OS or ... What?

The BIOS itself. That's what it's there for: a Basic Input Output System.

Older operating systems just made a BIOS call whenever they needed something. Today the operating systems can figure things out themselves, so they don't technically need the BIOS after they've booted up. But it's still there, and will answer if you call it. Calling the functions while the operating system is running may result in a crash, though.

I just assumed it was protected in some way... I wasn't sure, but I assumed it because it seems careless to leave it open to any random software that wants to access it.

My feeling is that you should be able to update the bios from the OS, but that (as someone stated) you should have to physically do *something* at the same time. Flicking a switch would be the best. The computer and the OS should run just fine if the BIOS switch is set to "write" when it's already running, but the BIOS won't boot unless you flick the switch from "write" to "read-only".

I think that would solve this problem. It would also stop people from simply setting the "update BIOS" switch to on and leaving it there (because it's easier, or because they forgot).

indio007

Flashing firmware is a bitch, trust me I know, I've implemented such systems in embedded products that I've designed. We use TI DSP's with codespace in on-chip flash memory, to do a firmware upgrade a user navigates to a .bin file on a flash drive inserted into the instrument and selects it, then the fun begins... I copy the file to off-chip flash memory (dataflash), set an "upgrade" flag in dataflash, reboot the processor, on startup the firmware looks for the upgrade flag in dataflash, upon finding it it copies the TI FlashAPI and my own functions into RAM, begins executing from RAM, calls the flash erase API function to erase the on-chip flash memory, then reads blocks of the firmware image that I put in dataflash and programs each one to the processor using another API call, then I remove the upgrade flag from dataflash, add another "1st start" flag, reset the processor, perform migration tasks, reset the CPU again..

If anything goes wrong during any of that process you will "brick" the instrument... it's just the nature of the thing, you are erasing the firmware, so if you erase the firmware and then don't write the new firmware, or write corrupted firmware, as soon as the processor restarts it will hang (it will likely hit an illegal instruction trap eventually, after doing random shit for some time), and that's that, no recovering from that without hooking it up to a programming/debugging interface (JTAG) and flashing it again using special hardware and software that no one has.

There are various methods you can use to make this safer, like using a multi-step boot loader where the first step is less likely to ever need to be changed, but at the end of the day some code has to start the process, and if you need to change that code there will always be a potential to hose the entire system.

"Brossard has shown that any snooper placing rogue firmware on your computer basically owns you forever.

Surely, this dude isn't an idiot but quite frankly when it comes to software (any kind) if it can infect bios or firmware, then this necessarily means it can be disinfected(unless ROM) and or in the least detected. So, there's nothing stopping Antivirus vendors from designing software to scan the firmware. Why this has drawn so much attention is beyond me. It's been common knowledge that the FBI and similar intelligence agencies can do this though I'd say its about time we have public proof so that we may be better equipped to defend ourselves from espionage.

I'm kind of surprised no one has yet mentioned UEFI/EFI booting, which is becoming rather prevalent. EFI enabled systems copy the BIOS firmware code to a small standalone partition on the hard drive, and then the system boots straight from that--mainly to decrease boot times. This could easily be infected, and I doubt antivirus programs scan the EFI partition.

Foolish1 has it right. The technique has been around forever although I never encountered it either in the field or in our networks. Fortunately I only had to deal with a few models of machines and the hottest were under my physical control (thanx boss!). IAC, one of the things that I do here is check how current my BIOS, what issues were resolved with each version, and I make 2 backups of the original!

Now if were talking about the new UEFI having this kind of vulnerability, maybe it'd be something serious. Supposedly the signature of the UEFI firmware *and* the boot code have to be signed and validated. We'll see.

Surely, this dude isn't an idiot but quite frankly when it comes to software (any kind) if it can infect bios or firmware, then this necessarily means it can be disinfected(unless ROM) and or in the least detected.

The real problem is that BIOS goes first. So whatever you do in your system can be compromised. The BIOS could simply carve a piece of the harddisk (make it invisible to the OS) and store something there that will reinfect the computer on startup if it were to be cleaned. It can inject code that will make the OS think it is talking with the BIOS when it is in reality just talking to an image of an unfected BIOS stored somewhere to make it look nothing is wrong.

With computers it's always the same problem. If you have access at the most fundamental level then anything that runs a level above that (like virus scanners) have zero chance of detection/disinfection.

This is why some computers have a spare ROM on the motherboard - or at least they used to have. This ROM had an original copy of the legitimate BIOS in it for the specific case where someone messed up the working copy.

One can achieve a similar effect by making a backup copy of the flash chip using the motherboard software from the manufacturer. This of course needs to happen when buying a new computer and before installing anything on it other than what it[the computer] came with and of course also before connecting it to any other computer.

so if you ever suspect your machine of having been hijacked, you'd boot up using the spare disc and restore the original bios to the flash-chip.

Another option would be to set the flash to disable write operations to it. Permanently. These days technology changes so fast that it's mostly worthless updating the BIOS in any case so simply preventing a BIOS update would be a permanent fix.

I just assumed it was protected in some way... I wasn't sure, but I assumed it because it seems careless to leave it open to any random software that wants to access it.

The original purpose of BIOS was to be a hardware abstraction layer ROM for PCs which houses the basic system calls for manipulating memory and hardware, so that the system software don't have to know which exact chip handles things like keyboard input on any particular machine - they'd just make a standard BIOS call and get a keyboard scancode in return.

It's like having built-in device drivers, so you never have to worry about compatibility. Of course, it became too small and inflexible for that purpose, so operating systems stopped using it.

Uh, guys, you are barking up the wrong tree. There is now a NIST recommendation: BIOS Protection Guidelines (NIST Special Publication 800-147) that suggests (demands?) that the BIOS code contain a cryptographic signature, and not allow any updates that don't validate cryptographically.

Translated that says that the US government is asking vendors to sign BIOS code, and design it so that no one other than the original signer can modify the BIOS. This closes a number of security issues discussed here as far as the USG is concerned, but small users don't have the same clout. (For example, the USG might ask vendors to escrow a copy of the key in case the company goes out of business.)

Years ago when Java was about to come out I was working on a cryptographic security approach for applets. Basically cube the provided bits modulo the applet supplier's public key. Details omitted here. But the nice feature of the system was that anyone could examine the actual (JBC) code.

That plus a key escrow and signing system would allow the necessary "web of trust" without hiding anything. Well, the private key corresponding to the public key that allowed the applet provider to take cube roots. The mechanism for avoiding cubes that could be found easily was documented and need not be secret.

Do I expect the NIST document to result in something like that for BIOSes? Or better yet for UEFI? No. The system I was designing could be provided as part of a compiler that normally output JBC. But I was designing a system that once deployed did not have any preferred vendors or customers. That is not a requirement that the US government has, and their recommended solutions solve their problems. (And that of other large preferred customers.)

All this shit with insecure BIOS started when that old crooked beancounter Steve Jobs foisted Apple on coming out with the 'Apple-III'. This apple did not have a BIOS on a ROM, but on the boot disk. Some kind of primitive protoBIOS read this from the disk into the machine. If that disk screwed up, your expensive $7,000.00 Apple III became a brick. Jobs made sure that you would NEVER own any AppleIII software that was not made by Apple, so nobody made any third party stuff for it. Apple's offerings did not impress as they were prototypes of the stuff that made it into the first Mac, the little lunchbox. AppleIII did not come with a hard drive, just two 'stringy floppies' with proprietary disks with a proprietary format on them so one even had to buy floppies from Apple as well. They held no more than regular 5-1/4" floppies, so instead of five bucks for 10 blanks, you paid $25 bucks for two! Sound like today's monopolies! All that fawnin over that creep Jobs makes me puke.

You can do it via USB or a LAN. Think of it this way:User X contracts a (regular) virus on his machineUser X is connected via LAN to other machines.The machine of user X then starts flashing the BIOS of other machines in the LAN (and one of the machines then flashes the machine of user X to make the penetration complete)

Actually this type of BIOS infection via USB has been done before. It was just a few years ago and it was found to have started on picture display devices from three different vendors. The malware changed its name each time it infected a new item but it only seemed to be designed to penetrate and spread between systems. Last I read of this particular instance over 80,000 of the infected units that were found in the USA were returned to the three manufacturers in China.

And no, it's no longer commercial suicide to sell mass quantities of junk. It's all about price and 90% of the buying public is ether unaware or unconcerned with anything but price.

Granted, those were (probably!) just bugs but, what's to prevent a certain company from hardwiring their CPU so, that some command like innocent looking ADD A, B will, for certain values of A & B, instead of producing expected value of C trigger an ICBM launch?

Or if that seems too far-fetched, just freezing the CPU and shutting down the whole system which just happens to be a Friend-Or-Foe recognition system in some guided missile navigation unit?

WTH, I heard about this back in the early to mid 80's on 286 machines and had forgotten about it. How in the hell could manufacturers allow such a serious vulnerability not be either hardware protected or scannable by antivirus software?

There's a couple of ideas how to scan for BIOS viruses - none of which are foolproof.

1) The response time of a BIOS with a virus is different (as the virus code has to run in addition to the BIOS code)2) You can create a 'honyepot', which is basically a method by which you give a virus something to infect (e.g. by creating a state in memory where it thinks that you have loaded an uninfected version of the OS and then needs to infect that.) Then you can track the changes it makes without it affecting the 'real' OS - which is presumably another virtual OS you've set up just for the scan.

Both these methods only give you a chance of detection. Neither gives you a chance at cleaning the BIOS. Both can be circumvented if the BIOS virus is geared towads thwarting these types of scans (by manipulating the clock or by checking for virtual machine software)

The reason this is "new" isn't that BIOS viruses are new, it's that now it can be distributed over the internet just like any other virus. In the old days you needed physical access to the computer, so it really wasn't a big concern. Now it is.

There's a couple of ideas how to scan for BIOS viruses - none of which are foolproof.

Sorry, but the post you quote wasn't about BIOS at all, please check a couple of earlier posts between the posters. It was about something (a bug, trap or backdoor) hardwired right into the CPU logic itself.

Sorry, but the post you quote wasn't about BIOS at all, please check a couple of earlier posts between the posters. It was about something (a bug, trap or backdoor) hardwired right into the CPU logic itself.

The honeypot idea might still work for detection purposes if the backdoor is used occasionaly. If there are also known chips with an identical make but without the backdoor then the profiling detection system might also work.

If you have a sleeper, though, then there's really no way to detect it.

Please sign in to add a comment.
Registration is free, and takes less than a minute.
Read more

Click here to reset your password.
Sign in to get notified via email when new comments are made.