Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security IT Technology

Discovery of New UEFI Rootkit Exposes an Ugly Truth: The Attacks Are Invisible To Us (arstechnica.com) 118

Posted by msmash from the security-woes dept.
joshuark writes: Dan Goodin of Ars Technica reports that security researchers have found that rootkits for Unified Extensible Firmware Interface (UEFI) are not rare, and difficult to detect. Kaspersky researchers profiled CosmicStrand, the security firm's name for a sophisticated UEFI rootkit that the company detected and obtained through its antivirus software. They state: "The most striking aspect of this report is that this UEFI implant seems to have been used in the wild since the end of 2016 -- long before UEFI attacks started being publicly described." The researchers warned that "the multiple rootkits discovered so far evidence a blind spot in our industry that needs to be addressed sooner rather than later."
This discussion has been archived. No new comments can be posted.

Discovery of New UEFI Rootkit Exposes an Ugly Truth: The Attacks Are Invisible To Us More

Discovery of New UEFI Rootkit Exposes an Ugly Truth: The Attacks Are Invisible To Us

Comments Filter:

  • We need physical switches to flash firmware (Score:5, Insightful)

    by Anonymous Coward on Thursday July 28, 2022 @01:50PM (#62742264)
    Boom! Problem solved. Why is this not common sense and standard?

    • Re:We need physical switches to flash firmware (Score:4, Interesting)

      by Anonymous Coward on Thursday July 28, 2022 @01:55PM (#62742296)
      Part of the answer is that such machines would be excluded from purchase by large enterprises that rely on remote management.

      The computers at my first tech job required a jumper on the MOBO to be moved, to write to the BIOS.

      • Re:We need physical switches to flash firmware (Score:4, Informative)

        by Z00L00K ( 682162 ) on Thursday July 28, 2022 @02:07PM (#62742348) Homepage Journal

        Even in large enterprises the BIOS or UEFI rarely plays a role in remote management.

        Primary reason I have seen for doing an upgrade of the BIOS or UEFI is the ability to install latest version of the OS image over the net. In other cases such updates have resulted in headache - like dropping support for a third monitor for no reason that worked fine in previous version.

        But I do understand that especially the UEFI offers a whole new set of attack vectors that can be very hard to identify by the OS, even to the level of doing a Blue Pill [wikipedia.org].

      • Yep it was a common feature on mainboards until the early 2000s, and would still be useful today. It could even be a large thumb switch on the mainboard's back panel rather than a jumper for easy access. Instead we've taken the first step on the "6,000 hulls" approach to the problem.

        • Re: (Score:1)

          by davidwr ( 791652 )

          Yep it was a common feature on mainboards until the early 2000s, and would still be useful today.

          In theory, signed firmware updates make this a non-issue.

          In reality, signed firmware updates plus authentication by an administrator for non-physical-access-required firmware update plus no bugs in the hardware or software plus no compromises to firmware-signing keys are a safe substitution for requiring a hardware switch.

          In practice, well, in practice it's not an adequate substitute. But it is a necessary one if you need to remotely install firmware updates.

          • All of which should be an extra addon for enterprise customers. Most of these problems come from the enterprise crowd wanting an OS baked into ROM so their "management" is easier. The vast majority of end-users (read: non-enterprise customers) don't even know this crap is. Let alone that it exists on their devices waiting to be exploited by some malware.

            Also, the signed updates crap means jack shit. If you're an enterprise, you're not pushing out a random firmware blob to every device on your network with

      • Re: (Score:1)

        by Anonymous Coward

        The computers at my first tech job required a jumper on the MOBO to be moved, to write to the BIOS.

        You must be young. At my first tech job, upgrading the BIOS required replacing a chip. That's if you were lucky. Otherwise, it wasn't possible.

        • Re: (Score:1)

          by weirdow ( 9298 )

          desoldering and replacing the otp prom or maskrom was always possible.

          These days it is becoming more and more im-probable/possible due to the integration into the main soc.

        • Re:We need physical switches to flash firmware (Score:5, Funny)

          by taustin ( 171655 ) on Thursday July 28, 2022 @03:15PM (#62742576) Homepage Journal

          Kids these days, In my day, we had to manually input each one and zero with a tiny pair of tweezers.

          • Re: (Score:3, Funny)

            by Anonymous Coward

            You could do it with tweezers? You lucky bastard! We had to un-pot the core rope memory and rewire the cores.

          • All joking aside, I did toggle switches to enter a program. The biggest problem is that once entered you weren't sure what you had entered. There was no way to dump the program to see if you got it right.

            • I entered programs with toggle switches in community college (electronics course) back in 1991-1993. I think it was an 8088.

          • Re: (Score:1)

            by Tablizer ( 95088 )

            Well, I had to make my own tweezers first.

          • Wait, you had zeroes? Such a luxury. In my days, we had to do it with just 1s.

        • Re: (Score:2)

          by HiThere ( 15173 )

          Well, that puts you either before 1970, or stuck with a really bad board design. (I'm not sure how much before 1970, because I seem to remember jumpers from sometime in the 1960's, and I always tried to stay at a distance from hardware. (I mean, the EAM machines had jumpers!)

          • Re: (Score:2)

            by jnork ( 1307843 )

            Yes, jumpers existed long before electrically reprogrammable non-volatile memory was commercially available.

        • Re: (Score:1)

          by SumDog ( 466607 )

          The BIOS on my 286 was socketed. I remember installing a replacement my dad ordered from Computer Shopper magazine to get support for larger hard drives ... no wait .. I think that was the 486.

      • Re:We need physical switches to flash firmware (Score:4, Interesting)

        by Joce640k ( 829181 ) on Thursday July 28, 2022 @02:50PM (#62742510) Homepage

        Part of the answer is that such machines would be excluded from purchase by large enterprises that rely on remote management.

        They're free to flip the switch to "enable" when they install the machines.

        They probably order in the hundreds anyway so they can order them pre-flipped.

        • Re: (Score:2)

          by Holi ( 250190 )
          Why would you update firmware remotely? Changing the firmware requires us to recertify the hardware.

      • Re: (Score:2)

        by Askmum ( 1038780 )
        I have never ever had a need to update my BIOS. Is this such a huge problem in a corporate environment, do they need to update BIOSes so often that it invalidates the security concerns?

        And if it does, why would it be a problem for them to have their MOBOs on R/W all the time while I put mine on RO?

    • Comment removed based on user account deletion

      • Organizations don't want to pay people to visit each workstation to flip a switch so they update the firmware.

        "Organizations" can order machines with the switch pre-flipped.

        They probably don't update the firmware much anyway.

        • Some of them may not, if they don't care about security, or reliability.

          In practice, when you manage a large fleet of servers, firmware updates ought to be at least a quarterly thing, if nothing else because it makes your test efforts possible. Do you have any idea how hard it is to do adequate testing of a new version of an OS/kernel if you have 20,000 possible permutations of system firmware? It's not just BIOS one has to be concerned with... it's BIOS, NIC(s), CPLD, storage controller(s), storage devic

          • In practice, when you manage a large fleet of servers, firmware updates ought to be at least a quarterly thing,

            What the hell. You literally should never need to update your firmware. Why would you do that?

            • What the hell. You literally should never need to update your operating system. Why would you do that?

              Oh wait.. because updates are released to fix bugs, including security issues, and compatibility issues, and sometimes even bring features you want to make use of. In the case of firmware, also because some firmware can't be downgraded, and you don't want 20 different versions of firmware running on the same type of component spread across your datacenter, each with its own peculiarities.

              • What the hell. You literally should never need to update your operating system. Why would you do that?

                I hope someday you wake up and realize there is a difference between an operating system and a firmware. Until you realize that, your point is invalid (to be more specific it's a strawman, and a perfect example of why arguing by analogy is always an incomplete argument. To make it complete, you need to show why the analogy applies in this particular case, which you did not)

          • 20,000 possible permutations of system firmware? It's not just BIOS one has to be concerned with... it's BIOS, NIC(s), CPLD, storage controller(s), storage device(s) (possibly some mix of SATA and NVMe, even SAS still for those edge cases), BMC, CPU microcode, even power supplies

            Well, that's an exaggerated number. Either said companies don't actually care about the testing and gleefully count their savings when ordering hardware, or they have a very small number of vetted hardware / firmware combinations and only allow updates to the specific versions they've whitelisted via testing. (Which if they are testing all of that crap, I'd imagine they have their own testing division.)

            If an "organization" orders several thousand of the same server config, over the course of 2 years or so, and they all come in with different firmware and aren't normalized, it creates endless system management and compatibility headaches.

            Which means the "organization" has much bigger problems. I.e. Their "solution" is garbage and so fragil

            • You're right, 20,000 is far too low. The actual number if you assume 10 different types of components with 5 potential firmware versions each would be 9,765,625 permutations. Thanks for catching that.

              You seem to be wanting to make the same point I made, I think. If a company doesn't test firmware, and simply accepts what the mfg sends them, instead of normalizing to a known set of firmware, their solution is garbage. I've known people who wouldn't update disk firmware even after the manufacturer said "t

    • Re: (Score:2)

      by taustin ( 171655 )

      Now compute how many additional employees Google would have to hire to update their 900,000 (yes, really) servers for a critical security update.

      • As the bios firmware was defective and was/can be overwritten, then Google or whoever could use the same flaw to correct infected hardware. In fact their buy power would also get them a digital signature. One administrator to sort this out. Now you average consumer has NO hope or correcting, much less than even detecting the issue. The correct decision is a dip switch or shorting points, so there is at least a worst case solution - as clearly UEFI and TPM etc have failed from design assumptions. You notice

      • Re: (Score:2)

        by clovis ( 4684 )

        Presently that's about 6 servers per existing employee, so if what we're talking about is flipping a r/w switch it would take a few minutes with some pre-planning. Write a script to send evey employee a customized message saying:
        "Report to at UTC 3:00 on September 20"
        "Enter building and walk to and wait for further instructions".

        • Or click the "enable firmware upload jumper" on the whiteglove order form and be done with it....Not sure why everyone is complaining about the suggestion of a jumper, it's not like the machines will be free from needing setup / reimaging / etc from factory specs before the end users get them. Someone has to do that. Either the whiteglove service, or your own IT staff upon receiving the pallet from shipping.

    • We do not know how the machines were infected in the first place. Maybe they came with the problem and a physical switch wouldn't help.

    • It makes more sense if you assume the systems were *designed* to be backdoored.

    • You can make changes permanent and lock it which is the same thing

  • UEFI: was it worth it? (Score:5, Insightful)

    by whoever57 ( 658626 ) on Thursday July 28, 2022 @01:50PM (#62742266) Journal

    So all the extra complexity brought about by UEFI hasn't actually resulted in increased security.

    Cynically, this tends to confirm that the point of UEFI was never about the user's security, but the security of Microsoft's business model.

    • Guessing your not on windows 11 because all the security enforcements were to big of a pain?

      • Even under Windows 10 I have used MFA with TPM on a PIN to sign in since 2017. So much easier and much secure. I don't understand the fuss as you do the same with your phones everyday.

        That is not UEFI by the way but something that was added to it just like our mobile devices have chips to store tokens so they are not on the storage where a hacker can crack it.

    • To lock you in to your subscription, you know the one you will soon need to use "your" own property. Now get back to work you fucking serf, the company store has your soul and you owe back payments.

      • Couldn't a destructive virus just zero out your TPM, then Windows 11 won't boot and can't be reinstalled?

        • Why would Windows 11 not boot if the TPM is zeroed out or even removed? The TPM just stores the disk decryption key. In order to boot, you just have to type it in manually.
          • ah yes, all we have to do is to type in some random 256-bit key that we don't know. No biggie.
            • If you haven't printed out your 256-bit key, you don't need anything malicious to happen to be locked out of your data. The TPM uses hardware measurement as a means to avoid producing the key in the case of tampering. Have a component go bad and the TPM won't provide the key to boot your system anymore. You need to have that key backed up!
              • Which the vast majority of non-enterprise customers will never do. Coming soon to a scam hotline near you: "We'll need to disable the TPM to disinfect your Windows." "Our super secure TPM backup solution will ensure access to your data if the machine goes bad!" "If you back up your key with your Microsoft account...."
                • Non-enterprise customers *should* backup their Bitlocker key to their Microsoft account. I believe that if you buy a Surface or similar device and login using a Microsoft account this actually happens automatically. For my corporate device I print it out hoping that I'll never need to pass such a rigorous typing test one day. But better than losing all of my data.
                  • Non-enterprise customers should do a lot of things. They should backup the data itself instead of just the encryption key made by some hardware vendor. They should encrypt their data themselves if they feel a need to, instead of having to have someone else do it for them. They should use something other than a five-eyes (or whatever equivalent group applies to them) participant to backup such a valuable encryption key. Sadly they often don't.

                    None of that avoids the scammer / social engineering potential t

        • You are much more likely for a cracker to get it from your PC through malware than through the TPM chip. This increases security. FYI if you disable TPM in your bios on your Windows 11 PC you will simply get a message that your pin can't be activated and to sign in with your usual password instead.

          No re-installation.

    • We all knew this but were mocked and ignored.

      • Re: (Score:1)

        by davidwr ( 791652 )

        We all knew this but were mocked and ignored.

        That's also what the Monkeypox researcher in Nigeria said [nature.com] about his repeated warnings for the past few years. Well, maybe not the "mocked" part, but definitely the "ignored" part.

    • Re: (Score:1)

      by Tablizer ( 95088 )

      It will only get solved when Nadella's chub-porn collection is exposed to the world.

    • So all the extra complexity brought about by UEFI hasn't actually resulted in increased security.

      Cynically, this tends to confirm that the point of UEFI was never about the user's security, but the security of Microsoft's business model.

      EFI/UEFI was a replacement for BIOS, and the first EFI system many of you would have laid hands on were the first generation Intel Macs, because Apple wouldn't touch your legacy BIOS with someone else's dick and they required it for fancy stuff like target disk, target display modes, etc. Or maybe you got to play with an Itanium server, but let's agree Macs are more likely. PC servers started shipping with UEFI to support 2TB+ disks sometime after that, and eventually Windows PCs started shipping with UEF

      • Re: (Score:3)

        by HiThere ( 15173 )

        It may have addressed that problem, but that clearly wasn't the REASON. There were lots of simpler ways to address the problem.

        I can see it being so that businesses could to a "mass simultaneous upgrade". I can see it being so that MS could lock out people it didn't like. There are other plausible reasons. It wasn't for the purpose of allowing larger disks anymore than we switched to 64 bit cpus to avoid a 2038 problem.

      • It has fuck all to do with security or Microsoft, and everything to do with about every other PC architecture on the planet having a more capable firmware environment than 16-bit BIOS.

        If it has "fuck all" to do with security, what is Secure Boot doing in the spec and a requirement for Windows?

      • No EFI was not due to Apple, it was Intel needing something without the BIOS limitations for their new "fancy" Itaniums.

    • > Cynically, this tends to confirm that the point of UEFI was never about the user's security, but the security of Microsoft's business model.

      And Hollywood's.

      Remember when all the stories here were about MPAA and RIAA. They wanted to control the computer industry?

      The current approach to boot-layer code signing enforcement was born from that.

      It's not inherently evil - I use an open source UEFI to rehab old chromebooks and it works great there. But complex boot code that can be flashed from inside it's g

      • The difference there is that the jumper (a physical screw on the mobo) exists on a chromebook. You can update certain portions of the firmware without touching the screw, but to completely reflash it, that screw must be turned to the enable position. Also, that screw establishes physical presence. So no signatures are required on the firmware update when the screw is enabled.

        Funny that the globally hailed corporate panopticon is the one to implement firmware updates in a sane way that doesn't lock out the

    • So all the extra complexity brought about by UEFI hasn't actually resulted in increased security.

      Cynically, this tends to confirm that the point of UEFI was never about the user's security, but the security of Microsoft's business model.

      Yes it was worth and no it wasn't an evil conspiracy theory by MS to force out Linux. It was Intel/HP who write UEFI for their failed Itanium line.

      Firmware and eproms have been used in Unix workstations and servers since the 1980s and are FAARR more advanced than the 1981 pc bios which takes 1 minute to boot up and still has hard coded cylinders and boot sector flags to load an OS ... it's 2022 we don't even use hard drives anymore!

      UEFI enables the user or admin to lock down a system, pxe boot, manage many

  • Color me surprised. I still use BIOS and hope to continue as long as possible. Boot process should be small and compact and needed only to bring up the OS. Let the OS to all the heavy lifting.

    • ... The Bios boot code is way more susceptible to vulnerabilities and allows your OS kernel to be root-kitted, exposing every piece of data in memory to the hacker.

      • No it isnt. A BIOS is a much smaller binary with a far smaller attack surface that does 1 main job, not a mini OS cum security arbitrator. If you think complexity mitigates against attacks I've got a bridge for sale you might like.

        • Re: (Score:1)

          by davidwr ( 791652 )

          that does 1 main job

          Well, maybe now it's main job is just to load some code from a boot device, but back in the days of 16-bit DOS running in a 16-bit mode or even on 16-bit chips it did a lot more.

    • BIOS viruses were rare back when you needed a chip puller and a UV source to modify the code...

  • Groundhog day? This is a dupe or I am crazy.
  • Muh Unix booted just fine before EFI. Multiboot worked great. Grub1 and LILO were easy-peasy. Then came EFI to make things "better". Okay, fair enough, my favorite hardware Unix platforms use firmware and eschew the PC-esque BIOS (except maybe the ARC firmware on MIPS & Alpha). So, I was game and all. However, I'm not really seeing the benefits (like.... at all) outweighing the extra complexity and security problems it's created.

    • The boot prom in a Sparc 1 from 1989 was miles ahead of anything in the pc world until the late 1990s. You could boot from ethernet, scsi cdrom, any device, you name it. Hell it was a complete forth interpreter. Grub just made everything way more complicated than it needs to be. Open up grub.conf and what do you see at the very top? DO NOT EDIT.

      • Re: (Score:2)

        by jd ( 1658 )

        OpenBIOS also had a Forth interpreter. Suspect it's based off the Sun SPARC approach.

      • Re: (Score:2)

        by vbdasc ( 146051 )

        I edit my Grub1 and GRUB4DOS config files with impunity. For Grub2 you're right, though.

    • I used to be able to call a random grandma and talk her through booting a linux CD.

      UEFI was there to make sure each system had different menus and no universal hotkeys like BIOSes did.

      The goal was to place very scary menu options all in the same area with warnings to scare casuals from trying out linux.

      Prior to UEFI I could without looking anything up, get into the bios of a machine or use the F8 tricks to boot 3rd party installers.

      UEFI disables the F8 thing until deep menu-diving is done that is not the sa

      • Re: (Score:1)

        by davidwr ( 791652 )

        UEFI was there to make sure each system had different menus and no universal hotkeys like BIOSes did.

        Different BIOSes had different menus and different hotkeys. Yes, probably 90% of the x86 "it runs DOS and/or Windows" computers sold in any given 5-year stretch in the United States used one of a small number of makes/models of BIOS, and within a given make/model, there was consistency, there was inconsistency between BIOS vendors: They had different hotkeys and sometimes radically-different-looking screens/menus.

        I used to be able to call a random grandma and talk her through booting a linux CD.

        Point taken - 90% of the time, it wasn't hard. However, if Grandma is one of those rare bird

      • Windows is already installed. UEFI actually makes this easier. Go to Windows Settings, choose Advanced Startup under Recovery. From there, you can choose to boot from a device. If secure boot is enabled and the installer you have doesn't have a signed bootloader, you might have to use this same menu to get to the EFI settings to turn off secure boot or enroll a key.

        The instructions have become more universal with this change. And fully graphical point and click.

        • Point taken, you can select a new boot device from your OS rather than from the BIOS boot screens. In fairness, you can easily do that with a boot selector like Grub or LILO, too, and not need any UEFI to do it. That assumes you :want: a multiboot system which most people do not. So, I'm not sure how much that feature buys you in the face of the security issues having UEFI might cause.

          • In fairness, you can easily do that with a boot selector like Grub or LILO, too, and not need any UEFI to do it. That assumes you :want: a multiboot system which most people do not.

            Considering the context was an existing system and multiboot wasn't desired, something like Grub would be more complex.

            I'm not sure how UEFI is causing security issues here. The fact that it's vulnerable in the same ways as BIOS?

            • I'm not sure how UEFI is causing security issues here.

              Then you simply aren't reading the articles. The added complexity in UEFI versus BIOS is the reason. Add more features and you increase the attack surface. The functionality being exploited is specific not present on BIOS systems, making them immune. BIOS hacks exist, but not in the volume or severity of UEFI hacks. Considering BIOS is older, that's not a good sign of quality for UEFI.

              The fact that it's vulnerable in the same ways as BIOS?

              The fact is that it's not the same. Just like in this situation, most hacks involve a scenario where BIOS is fine, UEFI is

              • They are both just flashed with modified versions. The main difference is really just simplicity of compatibility - that the same code can run on more systems with less modification. That's actually mostly a plus for UEFI. Making sure it doesn't get maliciously flashed is the same end goal for either.

  • A physical-access-required way to factory-reset a device to a known-good-state is a must unless there is a good reason not to allow it.

    High-theft and high-risk-of-evil-maid-problem situations are obvious exceptions (laptops, phones, etc.). Logging data like "odometers" and other "wear/usage indicators" may need to be stored in a part of the device that is not be reset-able. But when it comes to anything that's physically secure against hostile access, I should be able to open up the case, press a button o

    • A physical-access-required way to factory-reset a device to a known-good-state

      That used to exist. It was called a Recovery Disc, and as a bonus it also survived a malware infection through the virtue of being non-writable and detached from the rest of the system when not in use. Sadly it went the way of the dodo because of profits.

      A physical-access-required way to factory-reset a device to a known-good-state is a must unless there is a good reason not to allow it.

      As for phones, laptops, etc. - there's a huge risk in allowing a factory reset,

      It's safer just to shred the device and buy a new one.

      So which is it? A must have feature or something that should be banned to encourage the filling of garbage dumps worldwide?

      I should be able to open up the case, press a button or enable a jumper or flip a switch, and be back to a known-good state. I might lose all my data, but at least I still have hardware I can trust.

      So only authorized and "trusted" personnel should be able to do such things. Tell me who gets to decide who is worthy of "trust"?

      Also, I would recommend a tamper-evident seal of some sort on devices, so you know if you are dealing with a device that has been reset after it left the factory.

      I

      • Re: (Score:1)

        by davidwr ( 791652 )

        A physical-access-required way to factory-reset a device to a known-good-state

        That used to exist. It was called a Recovery Disc

        We are talking about firmware compromises. Reset disks by themselves don't do anything for firmware compromises. Now, a reset disk plus a way to force the firmware to go back to a known-good-state (say, a very simple state that does nothing more than read and authenticate a firmware image that is on the reset disk) would be very useful. It would also make the "factory reset boot sequence" much simpler and therefore easier to check for bugs.

        A physical-access-required way to factory-reset a device to a known-good-state is a must unless there is a good reason not to allow it.

        As for phones, laptops, etc. - there's a huge risk in allowing a factory reset,

        It's safer just to shred the device and buy a new one.

        So which is it? A must have feature or something that should be banned to encourage the filling of garbage dumps worldwide?

        It depends, and that is my point. It's a must-have except in cas

        • We are talking about firmware compromises. Reset disks by themselves don't do anything for firmware compromises. Now, a reset disk plus a way to force the firmware to go back to a known-good-state (say, a very simple state that does nothing more than read and authenticate a firmware image that is on the reset disk) would be very useful. It would also make the "factory reset boot sequence" much simpler and therefore easier to check for bugs.

          Originally, most systems that came with recovery discs didn't have firmware that could be easily upgraded by the system itself. Yes, my point was there should be some non-writable emergency mode that can be used to safely reset the device even if the OS is compromised. That includes the firmware. If the firmware is compromised, there should be a way to disable it, or reset it to a known good state. Ideally the firmware shouldn't be updatable short of a physical chip replacement / JTAG out of band upgrade.

  • That is why it is called a rootkit.

  • Initial vector?? (Score:5, Interesting)

    by bradgoodman ( 964302 ) on Thursday July 28, 2022 @06:36PM (#62743096) Homepage
    What this article never disclosed was - what was the initial attack vector here? How was any of this stuff installed in the first place? Where did the vulnerability exist, and what methods were immune to this? (Secure boot? Boot guard?) etc..???

    • You need an exploit in UEFI. You also need some kind of access to the computer, so either a remote exploit or phishing attack or something. Secure boot does nothing to prevent this.

Slashdot Top Deals

Single tasking: Just Say No.

Close