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.

45 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 Anonymous Coward · · 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.

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

    3. 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
    4. 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
    5. 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)
    6. 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.
    7. Re:Hardware is trusted by gl4ss · · Score: 1

      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?

      --
      world was created 5 seconds before this post as it is.
    8. 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.

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

    10. Re:Hardware is trusted by dog77 · · Score: 1

      Or make the bios completely independant of the operating system, where it runs in its own flash and memory so that it can update itself, but can not be updated by an external component. Do the same for the kernel, security key and password manager, and virus protection. Trully isolate the sensitive components in the system.

    11. Re:Hardware is trusted by NJRoadfan · · Score: 1

      UEFI uses a FAT32 partition with a special GUID on the hard drive to store boot loaders. Firmware settings have been stored in a battery backed CMOS for decades. There is no need for flash to store any of these settings.

    12. 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
    13. 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!
    14. Re:Hardware is trusted by Mryll · · 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.

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

    16. Re:Hardware is trusted by Anonymous Coward · · 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.

    17. Re:Hardware is trusted by Lumpy · · Score: 1

      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.

      --
      Do not look at laser with remaining good eye.
    18. Re:Hardware is trusted by lsatenstein · · Score: 1

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

      --
      Leslie Satenstein Montreal Quebec Canada
    19. Re:Hardware is trusted by sjames · · Score: 1

      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 simple bootstrap with a well-defined handoff to stage two which would reside in a seperately re-writable segment of the flash rom.

      That, in turn could do the rest of EFI or could be a more conventional bios or be replaced with SeaBIOS, bits of Coreboot, or whatever the user wants. I would expect the factory installed default to be a simple boot menu that can read MBR and GPT in order to load the disk based boot loader.

      That would both improve reliability where needed and make sure that you could always replace the offending EFI if it wanted to insist on SecureBoot or other potentially harmful scheme.

      Failing that, just go with the simplest possible bootstrap and let the OS or bootloader deal with the rest.

  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 drinkypoo · · Score: 1

      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 when I imagine vendors rolling their own. I'll live with the disease, thanks.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. 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).

    1. Re:In Soviet Russia... by crunchy_one · · Score: 1

      An interesting article about Intel virtualization and the author's attempt to write a hypervisor.

  5. Right by Skiron · · Score: 1

    So you need admin and be able to install a dodgy kernel module to trash the machine. Then again, if you got that far, a 2lb hammer would suffice without needing to know anything about computers/kernels/modules.

    1. Re:Right by Skiron · · Score: 1

      Well first you need to compromise a machine. Game over there and then, let alone starting to re-flash BOIS or whatever - this is just another *thing* that can be changed once you own the machine. No big surprise there.

      Of course, as to your question - if you have physical access (and a black hat), then game over anyway.

    2. Re:Right by Skiron · · Score: 1

      "...but can instead just reinstall the operating system."

      Oh no, secure boot, remember. It isn't yours.

  6. Re:Your missing the point of this article by crunchy_one · · 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.

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

  8. In Soviet Russia, the Party can always find YOU! by Thor+Ablestar · · Score: 1

    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.

  9. Ironically by Anonymous Coward · · 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 that begin with x, Flex, BladeCenter, Nextscale) and not necessarily anything else (the part recently purchased from IBM). Although the aforementioned teams came along with the purchase and are starting to call the shots across all enterprise server development (though not necessarily business or consumer pcs/laptops).

    1. Re:Ironically by chill · · Score: 1

      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

      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.

      --
      Learning HOW to think is more important than learning WHAT to think.
  10. Better link by Psychotria · · Score: 4, Informative

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

    Better apart from being a damn slideshow

    1. Re:Better link by crunchy_one · · Score: 1

      Bah to that. I prefer to have stories filtered through at least two poorly informed sources and then commented on by the clueless masses.

  11. Re:In Soviet Russia, the Party can always find YOU by Lumpy · · Score: 1

    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?

    --
    Do not look at laser with remaining good eye.
  12. Re:Hardware is trusted by us at the NSA ... by BoRegardless · · Score: 1

    To allow us to hack your system, so don't change UEFI/EFI.

  13. Not new by fred911 · · Score: 1

    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 ?

      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.

    --
    09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    1. Re:Not new by Thor+Ablestar · · Score: 1

      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.

  14. as always... by steak · · Score: 1

    physical access = game over. when this can be spread remotely, then I'll start freaking out.

    --
    lose != loose
  15. Re:Not physical access.. by Skiron · · Score: 1

    "that can do the appropriate manuevers"

    Was that supposed to be "manual levers"?

  16. UEFI or UFIA by goombah99 · · Score: 1

    Somehow I always get these two mixed up.

    http://www.urbandictionary.com...

    --
    Some drink at the fountain of knowledge. Others just gargle.
  17. Complete list of affected manufacturers/vendors? by rnturn · · Score: 1

    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?

    --
    CUR ALLOC 20195.....5804M
  18. The slides are finally posted by BIOS4breakfast · · Score: 1

    Maybe now people can have *informed* opinions? Slides here: http://legbacore.com/Research....