LightEater Malware Attack Places Millions of Unpatched BIOSes At Risk 83
Mark Wilson writes Two minutes is all it takes to completely destroy a computer. In a presentation entitled 'How many million BIOSes would you like to infect?' at security conference CanSecWest, security researchers Corey Kallenberg and Xeno Kovah revealed that even an unskilled person could use an implant called LightEater to infect a vulnerable system in mere moments. The attack could be used to render a computer unusable, but it could also be used to steal passwords and intercept encrypted data. The problem affects motherboards from companies including Gigabyte, Acer, MSI, HP and Asus. It is exacerbated by manufactures reusing code across multiple UEFI BIOSes and places home users, businesses and governments at risk.
Hardware is trusted (Score:3, Interesting)
Re: (Score:1)
To be fair, people have been exploiting hardware for decades - this isn't new, though I suppose it's new-ish (less then a decade?) for casual black hats.
56k modem exploits back in the day were kind of useful.
Re:Hardware is trusted (Score:5, Insightful)
It would be easy to prevent such attacks by requiring a physical switch to make any changes to the BIOS possible. But that would give power to the end users instead of big industry, and we cannot have that, can we.
Re:Hardware is trusted (Score:5, Interesting)
It would be easy to prevent such attacks by KISS as well. Sticking with something a lot more like BIOS instead of a multi-Megabyte EFI mess.
Re: (Score:1)
UEFI is much better than the old BIOS system. It runs ROM code from PCI/PCI-e devices in a VM, for example. While Secureboot worries a lot of people, as long as the option to load your own keys exists it's a nice security enhancement. It boots a lot faster too, due in part to ditching a lot of legacy crap that was probably full of security holes too.
Re:Hardware is trusted (Score:4, Insightful)
Not sold. Sticking with something like BIOS does not mean sticking with BIOS. Its time to drop the legacy support, sure. Sticking with a small amount of boot code to fire up the storage controller and jump to boot loader, set some memory timings etc is going to more secure than a massive interactive application that UEFI is.
Fewer inputs mean fewer inputs to sanitize and less opportunity to screw it up.
Re:Hardware is trusted (Score:4, Insightful)
I think UEFI has two different tasks confused. One is to boot my OS, which should just involve pointing it to the right storage device and loading X bytes into memory. The other is to provide a system configuration environment where I can boot and other hardware settings and there I want a rich environment. I want to be able to use my USB mouse and Bluetooth keyboard in a GUI, wired and wireless drivers for PXE boot, storage and RAID drivers, you name it. Basically it is a little OS in itself, running off motherboard firmware.
Now I have the impressions it's doing all this loading of a micro-OS with complex drivers only to finally hand over control to the real OS. Why? Maybe the OS wants to run a newer and better Bluetooth driver and now it can't because UEFI is running an old version. And if you do update the UEFI driver and break shit, you also broke your boot configuration. Just do the minimum requires to get the boot image, load it into memory and hand over control to the OS then get out of the way. If the boot fails, then you can launch the full configuration environment.
Re: (Score:2)
(picking teeth) Ain't that what we called a bootstrap loader in my day?
Re: (Score:2)
I would be less worried about Secureboot if it was absolutely mandated to allow a user key and allow disabling. Alas, it hasn't been all that long and the one mandate out there (from MS) is now gone. It's interesting that it is supposed to be for the owner's benefit but typically doesn't offer a simple way for the user to bless a bootloader or OS nor does it offer a boot anyway option. Almost as if the benefit is meant for someone else.
Perhaps the best approach would have been for the firmware to be just a
UEFI or UFIA (Score:2)
Somehow I always get these two mixed up.
http://www.urbandictionary.com... [urbandictionary.com]
Re: (Score:1)
It would be easy to prevent such attacks by KISS as well. Sticking with something a lot more like BIOS instead of a multi-Megabyte EFI mess.
In other words avoiding all that systemd embodies and assimilates.
Re: (Score:2)
just leave that portion writable and make everything else read only?
besides, you would likely want to be notified if the boot disk was about to be changed anyways, wouldn't you?
Re: (Score:2)
Re:Hardware is trusted (Score:5, Insightful)
Something like this: Firmware upgrades are not possible from inside the OS. At all. Instead there's a switch on the mainboard that is only accessible when the computer has been physically opened. When that switch is on, EFI will refuse to boot any OS and all onboard SATA/SCSI controllers are physically disabled. EFI will scan every USB port* for a FAT32-formatted mass storage device containing a file with a certain filename, which is then displayed for your approval, checked and installed. While the switch is off, changing the firmware should be prevented in hardware, such as by detaching a certain line required to write to the flash chip. (Settings should be stored on an unprotected chip and can be changed while the computer is bootable.)
You're in a corporate setting and need to update 16.000 identical desktop computers all at once? Make sure the computers have an enterprise-ready mainboard that can pull the update from the network (e.g. using something similar to BOOTP). You'll still have to toggle that switch and confirm the prompt. That's as convenient as it should get; after all, if there is any chance that the firmware is modified while an OS is loaded, any successful attack on the OS leaves your firmware in a potentially compromised state.
* Yeah, I know, USB also has infectable firmware. Unfortunately, I don't know of a reasonable mass storage standard that doesn't. And making people physically swap PROM chips won't fly.
Re:Hardware is trusted (Score:5, Informative)
Most older server motherboards had this. you had to install a jumper to enable write for Bios upgrades. Problem is the first thing you did as a sysadmin is install that jumper and leave it there.
Re: (Score:3)
Most of the boards I am familiar with wouldn't allow a full boot if the jumper was enabled to flash. The nice thing was a recovery option where you could rename a bios extension, and it would load it automatically from the FDD. But as far as I know, it would stop the boot process if you left either setting jumped.
Re: (Score:2)
We only had a couple of skilled admins, all the rest were brain dead MCSE's that barely knew how to plug in power cords.
But they were CHEAP! A lot cheaper than hiring people with actual skills and experience.
Re:Hardware is trusted by us at the NSA ... (Score:2)
To allow us to hack your system, so don't change UEFI/EFI.
Re: (Score:2)
Re: (Score:2)
It'd be nice if the next iteration of EFI had a more robust upgrade security design.
Something like this: Firmware upgrades are not possible from inside the OS. At all. Instead there's a switch on the mainboard that is only accessible when the computer has been physically opened. When that switch is on, EFI will refuse to boot any OS and all onboard SATA/SCSI controllers are physically disabled. EFI will scan every USB port* for a FAT32-formatted mass storage device containing a file with a certain filename, which is then displayed for your approval, checked and installed. While the switch is off, changing the firmware should be prevented in hardware, such as by detaching a certain line required to write to the flash chip. (Settings should be stored on an unprotected chip and can be changed while the computer is bootable.)
You're in a corporate setting and need to update 16.000 identical desktop computers all at once? Make sure the computers have an enterprise-ready mainboard that can pull the update from the network (e.g. using something similar to BOOTP). You'll still have to toggle that switch and confirm the prompt. That's as convenient as it should get; after all, if there is any chance that the firmware is modified while an OS is loaded, any successful attack on the OS leaves your firmware in a potentially compromised state.
* Yeah, I know, USB also has infectable firmware. Unfortunately, I don't know of a reasonable mass storage standard that doesn't. And making people physically swap PROM chips won't fly.
Some, if not most mother boards have a slot or space for tpm chip. That tpm is a smart smart card chip that can store data, can encrypt data and act like a vault. Thats a few pennies and does not require an external pair of wires to a physical switch.
TPM = Trusted Platform Module. ( http://en.wikipedia.org/wiki/T... [wikipedia.org] )
Re: (Score:3)
No, that would be useless. Just think it through a bit.
OK, so you have a physical switch somewhere. Bear in mind the trend in laptop design is to try and eliminate ports and switches, so Jony Ive will throw a fit if you suggest such a thing and Apple won't do it. But let's pretend the PC makers all do.
When does the user have to press this switch? When there's a BIOS update that needs to be applied.
How do they know there's a BIOS update to be applied? Because a message pops up on their screen telling them th
Re: (Score:1)
Re: (Score:1)
I don't know if it's that sinister. IIRC it was pretty standard practice to require a motherboard jumper change to enable updating BIOS. I think it was abandoned out of simplicity because users found it to be a pain in the ass.
Code reuse exacerbates the problem? (Score:5, Insightful)
Manufacturers/vendors don't write their own BIOSs; they license them from the likes of Phoenix Technologies and Insyde. These licensors don't write a completely new BIOS and bits for each licensee, let alone for each motherboard and their variants. As such, of course there is code reuse. Imagine the probable security issues there would be if each Vendor, let alone motherboard, received a BIOS that was written from scratch. QA would be a nightmare, as would the security of the code.
The problem isn't the reuse of code. The problem is that the code that was reused had security vulnerabilities.
Re: (Score:2)
The problem isn't the reuse of code. The problem is that the code that was reused had security vulnerabilities.
If you have physical access to the machine, it doesn't matter. You can rewrite the BIOS. And then, yes, it is an advantage to malware authors if there's only a couple of kinds of BIOS, because their malware only has to support those kinds. So yes, reuse of code becomes a "problem" for the rest of us if viewed from that perspective. It's not clear though that life would be any better for users overall if there were more kinds of BIOS. As bad as Phoenix, Award et al can be at making BIOS that works, I shudder
Re: (Score:3)
If you have physical access to the machine, it doesn't matter. You can rewrite the BIOS. And then, yes, it is an advantage to malware authors if there's only a couple of kinds of BIOS, because their malware only has to support those kinds. So yes, reuse of code becomes a "problem" for the rest of us if viewed from that perspective. It's not clear though that life would be any better for users overall if there were more kinds of BIOS. As bad as Phoenix, Award et al can be at making BIOS that works, I shudder when I imagine vendors rolling their own. I'll live with the disease, thanks.
Yeah, I agree with with regards to the physical access vector. I have a background doing IT in a DOD TS/SCI environment for three years and a TS environment for eight with DOE. Our (those of use who knew what we were doing) had the philosophy that if you had physical access to a system then you could pwn it. AT DOE it wasn't our duty to design systems with any consideration of the "insider threat" unless it was for the use of FORNATs. Systems for US use relied mostly upon personnel and site physical securit
Terrible "Article" (Score:5, Informative)
The "article" is three paragraphs and a few quotes full of FUD. There's no real information in there; it contains no good suggestions as to how to check for or deal with bios infections. It takes three clicks to get to a site that actually has some of the research, but that's just a static page listing conference topics. Don't waste another minute on this nonsense.
In Soviet Russia... (Score:3)
Soviet hackers have known something VERY similar for some time:
https://xakep.ru/2011/12/26/58... [xakep.ru] (In Russian but you can try Google translation).
Re: (Score:1)
Re: (Score:1)
EFI was actually invented and specified by Intel. The specification for UEFI, its successor, is maintained by a consortium of manufacturers.
If you think UEFI is the baddest thing out there, check out SMM. It can be used to silently subvert any Intel-based machine going all the way back to some '386 parts.
Re: (Score:3)
Windows is only one of possible paths of BIOS infection. It may also be implanted by any of 3-letter agencies of your choice during a shipment or during a secret search, by bribed hardware vendor or by service processor that is included into some really cool servers (See "In Soviet Russia" above).
Right (Score:2)
In Soviet Russia, the Party can always find YOU! (Score:2)
Problem is NOT the trashed computer - you can simply buy a new one. Problem is that the 3-letter agencies can use this mechanism to covertly collect information about YOU, which may possibly land you in GULAG. And it seems it's quite difficult to detect this leakage.
Re: (Score:2)
No it's trivial to detect the leakage. the packets have to go over the lan... Or are they reconfiguring the chips to become a quantum entangled radio?
Re: (Score:2)
Of course, as to your question - if you have physical access (and a black hat), then game over anyway.
Re: (Score:2)
Oh no, secure boot, remember. It isn't yours.
Ironically (Score:1, Interesting)
The one company that got suckered into doing Superfish is also pretty much the one company that has an immune UEFI: Lenovo.
Lenovo system x development actually writes their own firmware rather than going to AMI or someone. They also take directions from a very strict security team that has made them harden against this class of attack for years now (it wasn't a live vulnerability, but the general attack vector has been theorized for a long time).
Of course, this is the system x team specifically (Servers th
Re: (Score:2)
And here is a link to the BIOS simulators (in Flash) for just about every Lenovo BIOS.
http://service.lenovo.partner-management.com/et.cfm?eid=1437 [partner-management.com]
Here you can see BIOS settings and get familiar with the layouts. Not sure how helpful it is for security, but it is very informative.
Better link (Score:5, Informative)
http://conference.hitb.org/hit... [hitb.org]
Better apart from being a damn slideshow
Re: (Score:1)
Not new (Score:2)
Seeing how the the article is so dense with real content and references, what makes this different from CIH http://en.wikipedia.org/wiki/CIH_computer_virus [wikipedia.org] ?
This infection was sometimes a real bitch to fix as you had to hunt for the exact bios for the device (which wasn't an easy task), remove the eeprom and flash it. An real PITA and one that Joe Sixpack couldn't fix. A real nasty infection.
Re: (Score:2)
I have repaired a CIH long time ago. I installed an UV EPROM instead of Flash. There was a problem: Each time the computer booted up, it checked the saved config, reported an error and rebuilt the config. It took time but at least it worked. I believe the modern config is too big for this hack.
as always... (Score:2)
physical access = game over. when this can be spread remotely, then I'll start freaking out.
Re: (Score:2)
Was that supposed to be "manual levers"?
Complete list of affected manufacturers/vendors? (Score:2)
Has anyone gotten a hold of a complete list of the manfacturers/vendors whose products are affected by this? The way this has been worded there are more than the five mentioned in the summary text. Have products from any vendors been found to be "safe". (At least, so far?) And what versions of BIOS have been found to be vulnerable?
The slides are finally posted (Score:1)