New MoonBounce UEFI Bootkit Can't Be Removed by Replacing the Hard Drive (therecord.media) 105
Security researchers from Kaspersky said they have discovered a novel bootkit that can infect a computer's UEFI firmware. From a report: What makes MoonBounce -- the name they gave the bootkit -- special is the fact that the malware doesn't burrow and hide inside a section of the hard drive named ESP (EFI System Partition), where some UEFI code typically resides, but instead it infects the SPI flaws memory that is found on the motherboard. This means that, unlike similar bootkits, defenders can't reinstall the operating system and replace the hard drive, as the bootkit will continue to remain on the infected device until the SPI memory is re-flashed (a very complex process) or the motherboard is replaced. According to Kaspersky, MoonBounce marks the third UEFI bootkit they have seen so far that can infect and live inside the SPI memory, following previous cases such as LoJax and MosaicRegressor. Furthermore, MoonBounce's discovery also comes after researchers have also found additional UEFI bootkits in recent months, such as ESPectre, FinSpy's UEFI bootkit, and others, which has led the Kaspersky team to conclude that what was once considered unachievable following the rollout of the UEFI standard has gradually become the norm.
There should be a physical switch (Score:5, Insightful)
Re: (Score:2)
yes... but then how would you automate Firmware updates inside an entreprise?
Re:There should be a physical switch (Score:5, Insightful)
Security or convenience. Pick one.
Re: (Score:2)
Or both. Just not with a write enable switch.
For example, the processor having a mechanism to measure the ROM code and verify signature before jumping to it. The downside is that this has the side effect of vendor locking a processor (a processor installed into a board suddenly becomes unable to boot any firmware that isn't signed by the vendor of the firmware it was set to trust.
AMD PSB for example.
Re: (Score:2)
Re:There should be a physical switch (Score:5, Informative)
The flash is updated all the time through various updates and drivers.
You have microcode updates that are loaded on boot. You have various bits of firmware for various devices on board - ethernet, wifi, trackpads and pointing devices, system controllers, etc. All of that is stored in the one chip these days. Then things like vPro for Intel or the Intel ME firmware as well.
It's just a laptop, but it needed about 5 separate reboots to get each piece updated - the BIOS was updated first as a whole, then the Intel ME, the Thunderbolt firmware, the trackpad firmware, the processor microcode, etc. Heck, in the end, it technically rendered my computer unbootable as Windows detected everything it knew about the computer was wrong and it wiped the TPM, requiring me to enter the unlock key of the storage.
A lot of these updates do apply themselves and the update often happens within Windows, where it's stored away in a safe location and the system rebooted in order to apply the updated firmware.
Re: (Score:2)
Or...super innovative idea here...instead of a switch we use a little physical jumper to short a couple of pins on the board!
Re: (Score:3)
Leave the switches flipped to Write?
Which, of course, defeats the entire purpose.
The response to which would be to configure the motherboard such that you can either write to that memory, or you can boot to an operating system, but not both.
Which still comes down to security or convenience, but not both.
Re: (Score:3)
Yes, for those who prefer convenience, they can choose that over security. For everyone else, a physical jumper is the best option, especially considering how rare it is to re-flash firmware on most PCs.
Re: (Score:2)
Which, of course, defeats the entire purpose.
Yes, that is my point. If an someone wants to automate firmware updates they can choose to leave the switch on Write, or they can choose the more secure but less convenient moving the switch every time.
Hardware switches (jumpers as I recall) used to be standard on every mobo I worked with and at least the above option was possible. As things stand now it isn't.
Re: (Score:3)
Re: (Score:3, Informative)
There are a whole lot of reasons to update BIOS/UEFI/BMC/etc. that don't involve security - often memory timings, etc. need to be tweaked to improve compatibility and reduce instances of false failure (things like too high of an "correctable ECC error" rate, etc.). Some of them can also dramatically affect overall system performance, cooling (adjusting fan speeds based on certain PCIe cards installed, etc.), and so on.
So, while a physical switch/jumper sounds like a grand idea, it doesn't scale well at all
Re:There should be a physical switch (Score:5, Insightful)
I foresee that secure root of trust will be checked by 10000s of lines of C code which will need to be updatable, rinse repeat.
How about in addition to that giving some control back to the user, give me a factory reset switch on the motherboard.
Re: (Score:3)
For reference the two main ones that people would note currently are AMD PSB and Intel Boot Guard (the former puts the non-writable area in the processor, Intel puts it in the PCH). At least those two implementations as far as I know are simple and I don't see a way to find vulnerabilities.
Re: (Score:2)
Fan speeds, memory timings, and such do not require re-writing the flash, just changes to NVRAM (AKA CMOS).
Most PCs NEVER actually have changes made to the flash firmware. Where they do, it tends to be when they are being set up for the first time, so there will be hands on anyway.
Re: (Score:1)
I'm not simply talking about changing the fan speed, I'm talking about updating the tables that are responsible for automatically adjusting fan speeds based on installed components. I believe that piece is mostly controlled by the BMC on the servers I'm most familiar with, but may be in BIOS on some machines.
Similarly, I'm not talking about merely tweaking memory settings, but lower level adjustments to algorithms that help detect when memory has failed, etc. Some of that may be timing, but some isn't.
Add
Re: (Score:1)
I should add that another reason for updates is consistency at scale - if you deploy 4,000 servers across a span of 18 months, you don't want 12+ different firmware versions sitting out there. It makes correlation in the event of hardware issues nearly impossible. At the same time, downgrading newer systems is often either not recommended, or in some cases not possible. So, you pull the older systems up to the level of the newer systems. Otherwise... chaos.
Re: (Score:2)
>So, you pull the older systems up to the level of the newer systems. Otherwise... chaos.
Dear god, NO!
That will just cause more chaos.
For so many reasons just no.
1: unless it was extensively tested on test case hardware, new ROMs aren't just going to be slapped on my network infrastructure introducing who knows how many new bugs needing new workarounds.
2: Unless it brings in significant and necessary improvements / fixes there is no reason to risk updating. If it's working, and working well, just leave i
Re: (Score:2)
2: Unless it brings in significant and necessary improvements / fixes there is no reason to risk updating. If it's working, and working well, just leave it the fuck alone. No need to "Fix" it until it breaks.
I live by that. I am running Windows 7 at home. Until very recently I was using Office 2003. I "had" to upgrade because the sumif function is really neat and now I needed it.
At work, we now get a mandatory update to Office 365. Half of my automations with VBA and VBS don't work anymore. And for what? There is 0 functionality of Office 365 that is worth the update.
Re: (Score:2)
Re: (Score:1)
Exactly: you live by that... at home. It doesn't scale though. When you practice "if it ain't broke don't fix it" at scale, you run into MASSIVE problems (I know, having had to clean up the mess other people have created in such environments).
My personal laptop? Sure... I don't take every FW update that comes along on a whim. Managing 10,000+ servers? I also don't take updates on a whim, but I take updates. There's a test/standardize/update process that goes with it, that goes something like this:
1) R
Re: (Score:2)
If you have to adjust the firmware to handle new installed hardware, there will already be hands on to install the hardware.
If you mess with an already deployed system just because, you get to keep both pieces when it breaks. If updates are to be done at all, why not do them when the dust is being blown out? If you're NOT blowing the dust out from time to time, why are you then nit-picking the firmware version?
I'll bet the headaches and losses from a whole department getting infected by a rootkit that alte
Re: (Score:2)
then how would you automate Firmware updates inside an entreprise?
Make a kit to be sold to enterprises for $200 to $300 per workstation to support the automation feature, which replaces the physical switch with a small single-board computer that plugs into an otherwise unused dedicated header and have access to flash the chips but verifies a digital signature first.
When they realize the cost... Enterprises will begin to recognize the stupidity of wanting to get and mass-deploy every single new firmware, a
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: There should be a physical switch (Score:2)
It is called the write enable pin on the SPI flaw. (Flash? I think a virus infected the Slashdot summary and replaced flash with flaw.)
Re: (Score:2)
Didn't there used to be DIP switches for this very reason? I could swear I used to flip DIP switches on my MoBo for various reasons back in the 90s. Maybe it was for something else; but I want to say it was to enable flashing the BIOS.
Re: (Score:2)
Re: (Score:2)
beginning of an era (Score:1)
Thus begin the era of UEFI bootkits... not to be confused with the era of bios bootkits...
Re: (Score:2)
If you build a stronger fort ... (Score:5, Insightful)
Yeah, UFEI makes it a lot harder to recover it seems.
If you build a stronger fort - and then the enemy gets in and takes over, it's harder to kick him out than from a weaker fort.
If you make a secret entrance to kick out an enemy once he's taken over, an enemy who finds it and figures out how to open it can use it to take over.
Security isn't simple.
So much ingenuity, so little profit? (Score:3, Insightful)
Seriously, is this just some kind of an intellectual exercise or are the criminals making an actual profit from such esoteric exploits?
If they are climbing these mountains just because they are there, it's hard for me to imagine what can be done. Build a bigger and better mountain, and the world may not beat a path to your door, but some idiot mountain climber is likely to show up.
But if they are real criminals, then they must be doing it for profit. In that case I do think there is a solution approach worth considering: Find the profits and remove them. As it applies to this story, I'm rather hard pressed to imagine where the current profits are. So the obvious question is "How many target machines are we talking about here?" Next question is "How long before the targets are discarded as old tech?"
Re: (Score:1)
Seriously, is this just some kind of an intellectual exercise or are the criminals making an actual profit from such esoteric exploits?
Advanced persistent threat actors. One can argue about the profit involved in nation state or sponsored espionage data collection, but it is done all the time by everybody because they believe there is an advantage in doing so.
Re: (Score:2)
I'm rather hard pressed to imagine where the current profits are.
With micro-transactions across millions of hosts it can add up fast to real money. Have you never poked around in ~/.mozilla/firefox/blah/datareporting? The entire internet is just an enormous logical driftnet.
Re: (Score:3)
What micro-transactions? You seem to be assuming large numbers of target machines, but even granting your assumption, then I don't see any profits. But two constraints on my ignorance here:
(1) As far as I know, I am not involved in any micro-transactions, but perhaps I am just being unusually cautious? I certainly am not about to give any of my credit card information to the increasingly evil google and "friendly" fiends like Amazon and Facebook... (But even if there are so many micro-transactions, they nee
Re: (Score:2)
Seriously, is this just some kind of an intellectual exercise or are the criminals making an actual profit from such esoteric exploits?
If they are climbing these mountains just because they are there, it's hard for me to imagine what can be done. Build a bigger and better mountain, and the world may not beat a path to your door, but some idiot mountain climber is likely to show up.
But if they are real criminals, then they must be doing it for profit. In that case I do think there is a solution approach worth considering: Find the profits and remove them. As it applies to this story, I'm rather hard pressed to imagine where the current profits are. So the obvious question is "How many target machines are we talking about here?" Next question is "How long before the targets are discarded as old tech?"
Controversial moderation calls for a prophylactic requoting against censorship? But seriously folks, can anyone explain the basis of a "Flamebait" mod. I can understand the "Insightful" mod and would even thank the moderator if I could, and I wouldn't have minded a "Provocative" or "Thought provoking" mod if Slashdot had that, but I was mostly going for Funny with the mountain-climbing mouse. But as I've noted before, I couldn't write Funny if it was tattooed on my arse. (Well, I didn't note it exactly that
Re: (Score:2)
It's not just an intellectual exercise, these are real criminals developing these tools. Typically they're aiming at major targets, industrial espionage against major corporations and/or governments/militaries (at this level there tends to be a lot of overlap). If you're say a country that wants to become a major oil/gas exporter, the value of having inside information on what the other oil/gas exporters are going to do next year is mind-boggling. Or if you're a military wanting information on what your ene
Re: (Score:2)
Mostly the ACK, though you are introducing several new aspects. I suppose the main source of discouragement is something along the lines of "The bigger the criminal, the less likely they are to be punished for any crime." Or probably better to use the joke about owning the bank?
what was once considered unachievable (Score:3, Insightful)
Pretty foolish to think that, beyond the advertising realm anyway.
Trusted computing... designed to protect Microsoft from competition
Ironically... (Score:3)
Reflashing your BIOS used to be a simple process, it's only a trouble because they built-in protection against malware...
Re:Ironically... (Score:4, Informative)
Reflashing your BIOS used to be a simple process, it's only a trouble because they built-in protection against malware...
No it's not. Trouble that is. Reflashing your BIOS is easier now than it ever has been in the past. Download the program from the motherboard vendor. Push the button. Done. Or download the file onto a USB stick, insert into the USB drive and reboot. Done.
Kids these days are so spoilt they don't remember a world where you had to scrunge in your parts bin looking for a floppy drive to boot into DOS so you could reflash your BIOS.
Now get off my astroturf.
There ain't no ROM (Score:4, Insightful)
So reflashing the BIOS is dead easy provided that you do not need to reflash the BIOS, e.g. because it has a virus in it.
There needs to a small amount of factory installed and unchangeable ROM that provides and emergency reflash. Probably involving opening the box.
Re: (Score:2)
So reflashing the BIOS is dead easy provided that you do not need to reflash the BIOS, e.g. because it has a virus in it.
You're begging the question. Does there exist a virus which also blocks the ability to flash the BIOS on the motherboard? The reality is this process is dumb, very dumb, almost too dumb to block level of dumb. The BIOS doesn't control how it gets flashed, it just gets flashed by another mechanism, always has. That's why the recovery method we used back in the 486 days of booting the PC and then swapping BIOS chips while it was running and running the BIOS update software on a blank / broken BIOS chip still
SPI flaws? (Score:3)
I don't know that technology, just SPI flash
Re: SPI flaws? (Score:3)
Speaking of which, SPI is an interface, not a type of flash memory. And any slashdotter worth their salt should be able to figure out how to.rewrite it. Not trivial unless they left a connector for the purpose, though. An Arduino can do the job once you find the chip and connect to it.
Re: (Score:3)
Function 15 of PCI device 31 has a 4K MMIO register IIRC, allowing writes to the SPI flash.
If there were safeguards, Cozybear seems to have worked around them.
Gimme a damn EEPROM again I was erasing them with UV boxes and programming them when I was 15 and barely competent at a keyboard. It's not that hard.
UEFI (Score:2)
EFI is more secure than Bios/MBR (Score:1)
Re: (Score:1)
Wasn't that what secure boot was for? To prevent changing the BIOS?
Re: (Score:1)
No, The purpose of UEFI and secure boot was to create obsolescence. The standard BIOS boot method was far more secure than so-called secure boot and UEFI.
Re: (Score:2)
No, The purpose of UEFI and secure boot was to create obsolescence. The standard BIOS boot method was far more secure than so-called secure boot and UEFI.
In fairness, UEFI adds some functionality where BIOS hit the limits. BIOS requires MBR boot volumes, while UEFI allows booting from GPT. In practice, this means that BIOS boot volumes can only be 2TB in size. It's simple enough to do multi-volume booting, but in practice, this is a requirement of BIOS due to its limits, while for UEFI, it's merely optional.
UEFI also supports booting from PCIe storage. Sure, it's possible to configure a PCIe add-in to emulate SATA, but that becomes a performance bottleneck f
Re: (Score:2)
Nope, SecureBoot is a scheme by which the UEFI could measure and opt not to boot EFI executable from disk if not blessed by Microsoft. It doesn't protect UEFI itself.
UEFI is protected by Intel Boot Guard or AMD PSB, where either the PCH or the CPU gets 'fused' to the vendor's firmware signing keys and before jumping to a single instruction from writeable flash totally verifies the content and refuses to do so if the contents don't pass the signature.
Re: (Score:2)
Weird, I have set up secure boot on thousands of devices, zero of which have been 'blessed by Microsoft'.
Re: (Score:3)
The default shim from RedHat, CentOS, Rocky, Alma, SuSE, Ubuntu are all blessed by microsoft.
If you went and extended the MOK with your own keys, then yes, MS has nothing to do with it. But in the general case, every distro has had their shim signed ultimately at microsoft's discretion. If you have had to compile your own kernel modules you had to go through this, but this is a fairly tedious process, generally automation hostile (the mokmanager demands interaction on reboot to confirm the staged mok change
Re: (Score:2)
Re: (Score:2)
Mask ROMs are pretty rare these days. Some OTP-ROM (one-time programmable) are flawed in that additional bits can be flipped, which seems very limited but being able to steer a jump instruction and append new data on the end is pretty much beginner level stuff. If there is a fuse that can be blown to stop programming, then any kind of OTP or Flash can be acceptable.
As long as you're OK with throwing away hardware when a critical flaw exists. Ideally you boot flow should be so simple that it is unlikely to h
Re: (Score:2)
Re: (Score:2)
Thinks that can get in the way are incompatibilities with new equipment or new standards. Reliabilitiy issues where perhaps it boots correctly 99% of the time, but on a busy network or with through a deep layering of fabric for your iSCSI you start to have problems. If you have 1000 nodes maybe you have 10 that you need to chase down and fix every day. This sort of thing can be tolerated usually, but a fix is also nice. And less negotiable are security vulnerabilities, such as there being a chain of trust s
Sounds like someone found a really convenient (Score:2)
and transparent way to flash SPI memory. Cut Lex Luthor a cheque!
Flashing SPI memory is not complex (Score:2)
It requires some specific skills and an potentially an SPI interface, but the process itself is dead simple.
Re:Flashing SPI memory is not complex (Score:4, Informative)
It's kind of like operating a jumbo jet. It requires some specific skills and appropriate gear, but process itself is dead simple.
Re: (Score:2)
It's kind of like operating a jumbo jet. It requires some specific skills and appropriate gear, but process itself is dead simple.
Nope, operating a Jumbo Jet is actually complex. SPI flasing is not. The first time I wrote to SPI flash in-circuit took me about 2 hours because I was extra careful and unfamiliar with the interface (bus pirate) I used.
Re: (Score:2)
Operating jumbo jet is also simple. The first time a trained pilot typically flies one, it takes about two hours, because they're extra careful and supervised by the captain.
Re: (Score:2)
Operating jumbo jet is also simple. The first time a trained pilot typically flies one, it takes about two hours, because they're extra careful and supervised by the captain.
Count the steps and feedback paths and failure modes. No, flying a Jumbo is not "easy".
Re: (Score:2)
Count the steps and feedback paths and failure modes. No, flashing SPI is not "easy".
Re: (Score:2)
Count the steps and feedback paths and failure modes. No, flashing SPI is not "easy".
Only if you cannot count. That may be accurate in your case. So you may actually not be capable to understand how stupid what you just claimed is.
Re: (Score:2)
I believe we already established your ignorance many posts ago, and it is ironic that it is only now that you notice it in my mirroring your point.
Re: (Score:2)
According to Kaspersky they have only found a single instance of this bootkit. Perhaps that was done in person and this requires physical access to deploy.
source: https://usa.kaspersky.com/abou... [kaspersky.com]
Re: (Score:3)
If MoonBeam can be installed remotely then wouldn't it seem possible to flash the SPLI remotely? I am asking because I don't know anything about SPI.
According to Kaspersky they have only found a single instance of this bootkit. Perhaps that was done in person and this requires physical access to deploy.
source: https://usa.kaspersky.com/abou... [kaspersky.com]
In principle there are two approaches
a) Write it in software. That is basically a BIOS update.
b) Write it directly to hardware, e.g. using a Bus Pirate or other SPI interface. Usually you can do that without desoldering the chip as it initially gets copied to RAM and then its I/O is idle and you can just take control by injecting the signals. Requires 5 connections, counting GND. There should be in-circuit adapters for the standard SO cases these are usually in.
In principle, a) is easy. It just needs to be
Working as Designed (Score:1)
It is working as designed. The fact that it was designed by a moron is why it works as if designed by a moron -- it was!
Re: (Score:2)
What was designed poorly? This isn't a new threat to UEFI, this is basically installing a malicious firmware, which could have been a malicious BIOS back in the day.
The protections against this has been available for some time from Intel and AMD.
Re: (Score:2)
Re: (Score:2)
BIOS updates were generally allowed, very very few had a write-enable jumper/dip switch.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Remember when they introduced UEFI? (Score:5, Interesting)
Does anyone else remember the discussion around EFI and the introduction of UEFI? I specifically remember a lot of people calling UEFI dangerously complex and that it would be infected by a sophisticated virus in the future. Seems like that day has come.
For those not keeping track of "this is a bad idea" instances:
* DMCA - check
* Clippy - check
* UEFI - check
* Intel Management Engine - check
* AMD PSP - check
* Intel SGX - check
* Bringing Back Clippy - pending
Re: (Score:3)
You say a lot of check check check but you don't justify any of them. UEFI is complex because systems are getting complex. Fuck man you can't even support a complete range of current CPUs and what's needed to enable their features without exceeding the memory limits UEFI has these days (which is why some BIOS updates depreciate support for older CPUs).
Computers aren't as simple as read a partition table, execute a file and hope to fucking god the OS knows how to do the rest anymore.
Same for some of the othe
Re: (Score:2, Informative)
UEFI is complex because systems are getting complex.
Bullshit. UEFI is complex because it was designed to be, not because it strictly needs to be for the function it nominally serves. So the extra complexity in its design is to serve extra complexity in the rest of the system that is not strictly needed for its proper core function.
Notice that the parties designing the thing include parties that design the CPUs and so bloody well can engineer their CPUs to require less hand-holding at boot-up. They just choose not to, for reasons good to them. Those are not
Re:Remember when they introduced UEFI? (Score:5, Insightful)
UEFI is complex because systems are getting complex.
The systems are needlessly overly complicated... which is what got us in the mess of UEFI in the first place.
Computers aren't as simple as read a partition table, execute a file and hope to fucking god the OS knows how to do the rest anymore.
You speak as if that is a good thing.
Re: (Score:2)
You speak as if that is a good thing.
It is. An abacas is about as simple as it gets as far as calculators go, but there's a reason we don't use them to solve maxwell's equation. Computers are complex because the world is complex and what we demand of them is complex. That complexity in itself breeds complexity down to the hardware level.
Simplicity in itself is not an end goal, meeting functional requirements is. If that requires complexity so be it. You may lament the days of not being able to boot a 2TB HDD, or not being able to use a Bluetoo
Re: (Score:2)
Actually, what I lament is that they didn't simply replace BIOS with a better design while keeping it extremely small. In a proper design, components would be self-contained. This means CPUs hold their own microcode/initial boot instruction, HDDs/SSDs provide access information in a sane matter, expansion cards provide information without requiring executable code be run. It doesn't take a doctorate in computer engineering to design a sane boot process.
BTW, a bluetooth keyboard is stupid in the first pla
Re: (Score:3)
Re: (Score:2)
My AMD CPU stutters because it's so old it doesn't even have a PSP, you insensitive clod! Piledriver is among the last architectures to lack one. It's also slow AF by modern standards ofc, but I still enjoy it.
Re: (Score:2)
Disabling it fixes the stutter.
Citation required. It better be a good one as well since the PSP is ultimately responsible for initializing the memory controller on Zen systems I've never heard of anyone who has been able to disable it.
Now what you can do is use a UEFI option to disable the processor from allowing the OS to access the TrustZone of the PSP. But that doesn't actually disable PSP in the slightest, it just prevents the OS from accessing things like the fTPM or the hardware random number generator. A few stupid BIOSes call thi
Re: (Score:2)
Re: (Score:2)
* Log4j2 being able to pull in executable code from a remote server - check
(That counts because it was added from an actual feature request.)
Re: (Score:2)
I was thinking more of "things mentioned on Slashdot" but yeah, that was a really bad idea.
If the MoonBounce developers ... (Score:2)
Isn't Kaperski Russian Intelligence? (Score:2)
Re: (Score:1)
Why TPM/UEFI are nonsense (Score:2)
Re: (Score:2)
You're right. We should just forget modern computers. The 486 was the pinnacle and we don't need anything better.
Or maybe you think computers just got fast without changing in complexity? LOL.
Only truly secure way is an offline device (Score:2)
At this point, if one is paranoid about untrusted layers below the OS, it would be best to use something that isn't Intel/AMD or even any of the larger ARM family, with a simple dedicated, wired USB or even RS-232 interface (ideally an old VT220 terminal or something -- remember to shield properly against TEMPEST attacks).
A Raspberry Pi Pico has no Broadcom or other vendor subsidiary blobs in it, so one could run a bare-metal or simple RTOS that takes input, encrypts using modern strong standards, and spits
Re: (Score:2)
Isn't that the whole idea of UEFI? (Score:2)
I mean why else make the BIOS so complex the memory chip on it needs to be writeable from the OS-level? Increasing complexity at such a scale will _always_ lead to more security problems.
Re: (Score:1)
Why not just relax? If you're not a criminal, you have nothing to hide!