Slashdot Mirror

← Back to Stories (view on slashdot.org)

LightEater Malware Attack Places Millions of Unpatched BIOSes At Risk

Posted by timothy on from the nothing's-perfect dept.

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.

17 of 83 comments (clear)

  1. Hardware is trusted by Anonymous Coward · · Score: 3, Interesting

    This was expected. A PC has many devices ready to accept new firmware at any moment. All you need is administrator access and you can start uploading new code. BIOS, HDD, DVD, even CPU microcode updates. Previously not that many have bothered, as it has been far more simple to just use some low-hanging Windows exploit. Now that Windows security has improved, blackhats have to up their game.

    1. Re:Hardware is trusted by aaaaaaargh! · · Score: 4, 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.

    2. Re:Hardware is trusted by DarkOx · · Score: 4, 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.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    3. Re:Hardware is trusted by DarkOx · · Score: 3, 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.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    4. Re:Hardware is trusted by Jesus_666 · · Score: 4, Insightful

      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.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    5. Re:Hardware is trusted by Lumpy · · Score: 4, 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.

      --
      Do not look at laser with remaining good eye.
    6. Re:Hardware is trusted by CrackerJackz · · Score: 2

      I would also settle for something that several of my (way old) Compaq servers had ... a second BIOS, SoftPAQ screw up your servers BIOS? Set a jump and boot from the factory fresh second BIOS (then re-flash the primary BIOS with a known good copy.) In modern systems just leave the default BIOS upgradeable (or a least require a PIN to update / trusted CA cert for enterprise deployments) and have a hardware button inside that can write the v1.0 BIOS code over the current chip. In this example the v1.0 BIOS can be hardware read-only (ROM-BIOS) as well.

    7. Re:Hardware is trusted by IamTheRealMike · · Score: 2

      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 there is one.

      How do they know the message comes from their PC manufacturer and not a virus? They don't.

      So will a virus just ask the user to press the button? Yes.

      And will the user comply? Yes.

      A physical switch will not stop BIOS malware.

    8. Re:Hardware is trusted by Kjella · · Score: 3, 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.

      --
      Live today, because you never know what tomorrow brings
    9. Re:Hardware is trusted by Whiteox · · Score: 2

      (picking teeth) Ain't that what we called a bootstrap loader in my day?

      --
      Don't be apathetic. Procrastinate!
    10. Re:Hardware is trusted by sumdumass · · Score: 2

      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.

  2. Code reuse exacerbates the problem? by LazLong · · 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.

    1. Re:Code reuse exacerbates the problem? by LazLong · · Score: 2

      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 security.

      I do disagree that a greater number of targets being more burdensome for the black hats outweighs the security benefits of supporting a smaller code base. The former is merely supposed security through obscurity. A basic rule of thumb of security is to minimize the attack surface. One of the primary strategies to accomplish this with regard to information security in a software environment is to reduce the amount of code running.

  3. Terrible "Article" by txoof · · Score: 4, 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.

    --
    This one's tricky. You have to use imaginary numbers, like eleventeen... --Hobbes
  4. In Soviet Russia... by Thor+Ablestar · · Score: 2

    Soviet hackers have known something VERY similar for some time:
      https://xakep.ru/2011/12/26/58... (In Russian but you can try Google translation).

  5. Re:Your missing the point of this article by Thor+Ablestar · · Score: 2

    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).

  6. Better link by Psychotria · · Score: 4, Informative

    http://conference.hitb.org/hit...

    Better apart from being a damn slideshow