When facing a malware situation, the usual “guaranteed solution” is to reinstall your OS. The new developments in malware world will also require you to have a CH341 programmer handy. In an arguably inevitable development, [Kaspersky Labs] researchers have found an active piece of malware, out in the wild, that would persist itself by writing its bootstrap code into the BIOS chip. It doesn’t matter if you shred the HDD and replace it with a new one. In fact, so-called MoonBounce never really touches the disk at all, being careful to only store itself in RAM, oh, and the SPI flash that stores the BIOS code, of course.
MoonBounce is Microsoft-tailored, and able to hook into a chain of components starting from the UEFI’s DXE environment, through the Windows Loader, and finishing as a part of svchost.exe, a process we all know and love.
This approach doesn’t seem to be widespread – yet, but it’s not inconceivable that we’ll eventually encounter a ransomware strain using this to, ahem, earn a bit of extra cash on the side. What will happen then – BIOS reflashing service trucks by our curbsides? After all, your motherboard built-in BIOS flasher UI is built into the same BIOS image that gets compromised, and at best, could be disabled effortlessly – at worst, subverted and used for further sneaky persistence, fooling repairpeople into comfort, only to be presented with one more Monero address a week later.
Will our hardware hacker skills suddenly go up in demand, with all the test clip fiddling and SOIC-8 desoldering being second nature to a good portion of us? Should we stock up on CH341 dongles? So many questions!
This week’s installment of “threat vectors that might soon become prevalent” is fun to speculate about! Want to read about other vectors we might not be paying enough attention to? Can’t go wrong with supply-chain attacks on our repositories! As for other auxiliary storage-based persistence methods – check out this HDD firmware-embedded proof-of-concept rootkit. Of course, we might not always need the newfangled ways to do things, the old ways still work pretty often – you might only need to disguise your malicious hardware as a cool laptop accessory to trick an average journalist, even in a hostile environment.
Thanks to Brendan Dolan-Gavitt on Twitter for highlighting this to us!
Main image courtesy Kaspersky Labs.
I have *ALWAYS* wondered why we don’t have a hardware BIOS Write Disable jumper on system boards. I have lost a couple of systems to BIOS problems. Indeed, my better systems at home have dual BIOS – a ROM and a FlashROM version.
This seems to me to be the time we should forget about infinite convenience in favour opening the case and moving a jumper from the open to the closed position – that way, only BIOS updates that we authorise are able to be written.
I wouldn’t mind such a jumper, would be rather handy at a lot of times. (Since nothing should really modify the BIOS after one has set up a system. And after actually Booting, there is even less reasons to meddle with it. Other than like overclocking, but that is a different can of worms that isn’t typical for the more “security” minded people that don’t push their CPU to the knife edge of stability.)
Same for a “Go into BIOS” jumper, I know some motherboards have such a jumper, but it doesn’t seem well documented.
If only we lived in a world where BIOSs weren’t buggy messes, and didn’t have runtime components that persisted after the OS had started. Sadly, I don’t see Coreboot or their way of thinking becoming popular anytime soon.
Not only that, but until they’re done transitioning entirely into MEs and PSPs and other computer-in-your-computer secondary cores, the system firmware will continue to be a big source of “value-add.”
I remember hearing somebody who works on the boot process saying (in a fosdem presentation) that a modern computer is just 30 processors in a trenchcoat, which is quite a memorable expression.
Once upon a time we had such jumpers, I think it was back in the late Pentium 1 era, I recall having to change a jumper to allow BIOS flashing. That’s something they should have kept.
Pretty sure my old 486 had it as well
Even for simple things like “Save Profile” in EFI *requires* writing to a section of the FLASH chip. So a simple write protect doesn’t work. Also the Write Protect pin is shared with Data pin for Quad (bit) operation.
There are sector/block level protection bits in those FLASH chips that could have been used similar to a bootstrap. Unfortunately they can be reset in full chip erase. BIOS makers don’t seem to use them for some reasons. That’s why some motherboard vendors have to engineer their own dual BIOS or USB BIOS solutions.
To save the profile, put in the jumper, save it, take out the jumper. And what is the problem? A bit more fiddly it sure is. but the jumper can be in “non protected” as default, and the security minded people can move it to the “protected” setting when desired.
In regards to sharing pins.
That can be fixed.
If AMD or Intel states “We want a separate write protect pin on the EEPROM chips for our systems, and it should be accessible by a jumper on the motherboard,” then most motherboard vendors will follow it, and EEPROM manufacturers will make a chip compatible with that standard. Since the PC market is moving many hundreds millions of units a year.
Though, having a non write protected area on that chip for non security related BIOS settings wouldn’t be a bad idea. Like fan curves is one thing that isn’t a security threat to change. (Changing the boot device however is a bit more of a threat.)
In the end.
I personally think having an actual write protect jumper is bringing forth more security advantages than it makes for inconveniences. (Like how often do people poke about in BIOS? Some don’t even know it exists…)
Many hundreds of millions of units a year is about 0.02% of the total volume of that class of part. Not enough leverage to ‘force’ a change.
Additionally, based on the prior instances of parts respecifications in the PC industry, any change like this would take several hardware generations to trickle into general availability, with board designers being required to support both kinds of chips until supply stabilized at some point > 5 years later.
The goal is a good one, but there’s just no easy way to shortcut the difficult parts of getting it done.
Isn’t there a pin that can be tied to ground to prevent writing?
I would argue fan curves and other ‘non-critical’ areas are still a security concern, and a bigger one than it seems till you really think about it. All depends on just how such things are implemented, as much as what it is.
But even assuming a perfect implementation with zero bugs being able to set the fans to never ever start basically kills the system, It probably won’t take any physical harm as thermal throttling is good and responsive (assuming its not also futzed with) but it will turn your modern PC into the Z80, BBC micro level of usefulness in the modern world – and on any computer handling security related bits – like network processing, backups etc that is unacceptable too, and quite possibly opens up more exploitable security flaws.
To be fair, implementing a simple array of data point storing the fan curve in a way that opens the door for actual attacks would be impressive in itself.
And with a decent enough cooler, passive cooling isn’t actually that bad and wouldn’t kill a chip. Thermal throttling has been a thing for the last 15 years. (and turning that feature off should obviously be under the protected part of our BIOS settings, like the majority of settings.)
But technically, one could go the simple route of just having a write protect for the whole EEPROM, that is likely the easiest. And then just have a jumper for it that by standard is in “non protected” mode for off the shelf motherboards. While the system builders most likely will set it to “protected” when shipping out their final product to the customer. (maybe even make it a switch)
Simple write protection would go a long way towards solving a lot of illicit BIOS/Firmware fiddling in a running system.
You say that, but what happens when the array provided is rather too large etc, simple and shouldn’t happen vulnerabilities are remarkably stupidly common, like the programmer are under ridiculous time constraints or have never done anything remotely about security in programming and just bodge the stuff together so it works…
‘Passive cooling isn’t actually that bad’… hugely varied based on usecase – a server will cook under even minor load if the fans ever turn off, and as the server is quite possibly responsible for other security aspects for the network (which you have to hope a timeout from extreme throttling means a service outage, rather than just failing off the system leaving the door open) its a big deal there, even if its just a service outage. But your home media computer, most gaming rigs – anything set up where noise of the machine cooling is an issue likely have enough cooler to not be crash or be damn nearly stopped dead level thermal throttle under the modest-medium loads – you might not even notice at all most of the time – heck your water cooled loop has so much thermal mass in it that even unpumped it will run full tilt alot longer than any macbook air – my old rig had hard copper tubes throughout as well as the single triple radiator and the fans could actually be turned off most of the time despite the loop cooling two fairly hefty CPU and the primary GPU even under high but not sustained loads – it just wouldn’t spike fast as the convection in the setup and all that ‘radiator’ that is the pipes plus the several L of coolant…
I’d agree a simple write protection would basically solve the problem, just have it default to protected as for 99% of computers that is where it will stay I expect. But it must be a real hardware write protect, actually making it impossible to write at all, rather than some hardware generated status flag that could potentially be bypassed – like the ‘write protect’ slide on the big SD cards – utterly pointless as all it does is if the socket has a switch to detect it is in ‘protected’ position tell the computer ‘oh I’m write protected’ you can still just write to it, only well behaving ‘smart’ software tools should ‘see’ the protection and tell you bugger off…
One thing that the COVID related silicon shortages is teaching us not to build stuff with your own thing without a good reason. e.g. DDR5 DIMM shortage. It has nothing to do with DDR5 chips production, but the shiny new PMIC that it introduces that isn’t based on commodity parts (yet). Yes, it sound sexy on paper, but it doesn’t add anything worth while.
Intel briefly had their LPC based firmware hub as a standard for BIOS. Where is it now? AMD just doesn’t have the volume. FPGA used to have their serial FLASH interface for bitstream, but they have given up.
Asking for a simple “write protect” pin isn’t much to ask for in regards to any SPI EEPROM. There is plenty of situations outside the PC industry where that is an actually useful feature.
Making a chip that however only write protects a certain portion of the chip. Then yes that is a fair bit more niche.
Just bring that jumper out to a front panel switch, or heck even a back panel switch. Could use a key switch but it doesn’t have to be a key switch. The point is that only someone with physical access to the system gets to decide when to ‘update’ the BIOS. The switch gives the convenience of not needing to open the case.
Some will posit the “evil maid” attack as a reason this idea would not work. Such arguments may be confidently dismissed until such time as reports of unexpected maids popping up outpace reports of remote malware installations.
But what about laptops? It may be better to ALWAYS get interaction from the PC “operator” before going to a new bios. I know on my HP and Dell PCs, they always do their BIOS flash updates “after the boot” (so they must set some kind of flag that can be subverted). If the PC manufacturer does something that requires a “trigger” from an operator, they then set some “internal flag” and that can then be subverted. Maybe a shorting block (aka jumper) that puts a PC into update mode and it has to be there to work (but then someone might patch over that part of the code to let happen “whenever”). “Some” of that might be preventable with a latch that once set, it can only be cleared by a special BIOS startup process (multi-byte unlock?) and then THAT requires an operator to “accept” the update of it won’t happen (but then again, that acceptance code could be hijacked).
Old PC BIOSs used one or more UVEPROM chips that had to be physically replaced to update (the old chips could be erased with a UV lamp). Can’t hijack that remotely, but you an infiltrate the supply chain, which I think has happened in some of the sleazier hobby markets.
I know, use quantum entanglement locks (but even those seem to be susceptible to “man in the middle” attacks)!
Why not use one of the switches already available, like the power or the reset since their functions are run through the BIOS these days anyway?
Just pop up a prompt: “To continue with flashing the BIOS, press the power or reset switch once. If you didn’t initiate a BIOS flash, you may be the victim of malware. This prompt will disappear in 60 seconds.”
Good trolling.
Power On/Off actually goes into Super I/O and can trigger a force down down bypassing software if pressed for 4-6+ sec. A Reset doesn’t give software/firmware a chance as it by design can reboot a PC even when the CPU goes into lala land. Those are the last thing you want to press while rewriting a new BIOS.
A couple of things. First, BIOS writer’s guides will detail a bit to set in a register that will set the flash part as read only in a register that itself becomes read only after it is written to. This effectively disables writes to the flash part at runtime.
So how does BIOS updating from the OS work then? That locked register has a condition where the register can be unlocked, in system management mode which is triggered via a special system management interrupt.
SMM has a lot of capabilities that people have know about for a while and there have been many attempts to create malware that can utilize it. With legacy BIOS, it was mostly security through obscurity and that any attacks would have to be very specific int eh hardware it targeted. With UEFI, its C code based on an open source project and there have been a couple close calls. Fortunately security researchers have been beating on that code for a little while, updates to the project have been made, and the IBVs have been pretty good at pushing changes out. OEMs are another story but it seems that is hasn’t been a huge CF so far.
So the short answer is that your BIOS chip is effectively read only in a modern system at the point where malware could be an issue. Coupled with other mechanisms like signed UEFI DXE drivers, and signed BIOS updates, things on that front are fairly secure.
There could easily be a button on the PC backplate that triggered bios write enable, put it in a pinhole like a reset button.
It could also act as the bios boot key, instead of having to check which one the OEM decided to use instead of the delete key
Talking about EEPROM programmers.
Anyone have any good suggestions for Linux (preferably Ubuntu) compatible universal programmers? And decent HEX editing software. Similar story for JTAG, etc.
I have mostly used Windows for the electronics workbench, so haven’t explored the options over in Linux land. (I have been eyeing Symbiflow for FPGAs, and have used Linux for servers for years, and Windows is going too far towards Software as a Service, not to mention the forced updates throwing a wrench into things… So Linux seems like the logical new OS for the electronics workstation)
In short, what does all you Linux only folks use for editing and programming EEPROMs?
You should post it to the stack on hackaday.io
The obvious tool that does everything: Emacs.
3.3v modified CH341a, Flashrom, wxhexeditor and uefitool
Some ch341a boards come with a jumper 3.3V/5V, no need to do a mod.
And some flash chips can be reflashed live from a running OS, depending on the hardware, on laptops it is harder because of an embedded controller, but on desktops and servers, those chips are detected.
Both laptops, desktops and servers have an EC, so you probably meant something else.
You might have to update your programmer in the future. FYI AMD Ryzen Flash chips are 1.8V.
On Linux my gotos are a generic ch341a USB programmer and flashrom. Both work on practically everything, from run-of-the-mill destkop distributions, to esoteric Gentoo setups.
As far as editing goes, I use neovim with xxd. You can check it out with “:help using-xxd”
TL866II programmer is what I use. It is officially Windows-run, but there’s also Linux support. It can program GALs and PALs, and test RAM too. Make sure you get an authentic one, as there are inferior counterfeits out there.
Manufacturers could store the factory BIOS on a read only chip, with a button or jumper to re-flash the current BIOS with what is on the read only chip. You’d have to update your BIOS and everything else, but it would give you a clean system to (re)start from.
They could… but that could cost more money. They prefer to keep their money even if you suffer.
Some do, but the board usually leaves the factory before a stable usable firmware has been written. The emergency recovery bioses rarely can do much more than accept an updated bios… if you’re lucky enough to have a CPU that was designed before the board was fabricated. If you’ve upgraded to the newest-and-latest cpu? Good luck, it often won’t even power up on a day-one bios.
the fancier motherboards are able to flash the bios without a CPU, you just have to insert a flash drive into a port specified for this feature
that would add the cost of an extra chip, as well as custom programming to support it. plus many amd mobos will only boot with ancient processors until they get a bios update, so you could be dead in the water if you reset to the default bios with a cutting edge cpu.
That extra $3.00 of parts would become a $2000.00 upsell to the three letter agencies.
Every new cutting edge mobo I’ve bought with a cpu being released a week or so after the mono the last 10 years already has a way of updating bios without cpu installed. The last 3 top shelf mobo’s also had a button or switch you have to manually press to write the bios. Also they have 2 bios chips so if I need up one I can boot from the other, it was intended for overclocking but would also make this malware a non-issue. Virus on bios? Run other bios, flash new bios from manufacture on corrupted bios, problem solved in a minute or two. The cost of doing this for any mobo is pennies, once this malware is mainstream every diy mobo over $100 will include it… not that big of a deal unless you buy pre-built oem computers or run old hardware. These motherboards are already available from msi, asus, and gigabyte for sure, so most likely from the others as well.
I was thinking exactly the same thing.
Well, at least it has windows dependencies, so I am safe and can happily roll over and go back to sleep.
Get busy with those BIOS write protect jumpers though, that is a good plan.
TPM help in any of this?
“Help”? As in help make more ways to compromise your system? Absolutely.
As much as people claim it’s for vendor lock in, this is what “locking” a cpu to your motherboard (OTP fused signature key like bootguard) is meant to solve. I still don’t know how it makes recovery any easier, but it should give you detection at least.
Quite a lot of bios flash chips actually have a physical write protect pin. It wouldn’t take much to solder on a little bit of enameled wire and hold it high or low with a switch.
i predicted something like this 10 years ago. they told me i was paranoid. vindicated.
A$$holes some times take a while to catch up with technology.
This kind of exploit seems to happen about every 10-15 years. It’s probably related to institutional memory with PC manufacturers. They burn their fingers, fix the problems, and then forget why they did what they did. Then some “super smart” suit decides that it’s time to cut out “extra fluff” from the design and presto, the problem is back.
“What will happen then – BIOS reflashing service trucks by our curbsides?”
Not a bad guess, but my motorcycle uses less fuel, and I charge extra for housecalls.
what is old is new again. in the pentium 2, 3 days we had jumpers and also dual bios motherboards because of these threats.
I always thought that the write-protect screw used on Chromebooks was a very clever idea.
You can’t overwrite the BIOS unless you actually intend to do that.
Is there a dedicated pin the flashing happens over that we could physically solder a bit of magnet wire to? Not just pull down, but short right to ground or vcc so even if there were a write it would be lost. If it is a standard thing across at least x86/AMD64 we need to be looking at data sheets.
So here’s a question – two years since this thread got started, but looking for answers to a serious problem – from a Joe Average user, ie, someone oblivious to pretty much everything more involved than OS installation.
Like a lot of people disgusted with the bizarre fact that a good quarter-century after the internet and computers-in-every-home really took off there remains only three (3) options for operating systems, I’m striving mightily to transition from the Microsoft Borg to Linux. Which means that Step One is: Determine which type of BIOS your system uses, via bcduser /enum in command prompt. I discovered that mine is: Legacy. Ok, groovy.
So I install a Linux distro, get it running and actually try a little surfing, then shut it down. A couple days later I try to start it up and get encryption password errors and can’t get in. So I think “Ok, ‘must’ve written something down wrong, ‘gotta reinstall. No problem, nothing saved anyway.”
But when I try to reinstall I get that rip-out-your-hair Linux feature called the “grub error.” Which generally means there’s a BIOS type mismatch. But wait a minute, I’m using the exact same disc with the exact same iso as before, so what gives?
So I switch over to the drive with Windows on it and do the bcduser /enum thing again, and… WTH, it no longer says “winload.exe,” now it says “winload.efi” – which means my BIOS magically transformed itself? How is that even possible?
So the big question would be: Is this some quirk written into the code of the distro I used, or was that brief foray into using the successfully-installed Linux OS sufficient for someone to hack my BIOS and hose it up?
If it’s the latter, will doing a BIOS re-flash even work to clear up this mess? The lead article gets a bit over my head with “…your motherboard built-in BIOS flasher UI is built into the same BIOS image that gets compromised.” Does this mean the only fix is to physically replace a chip? ‘Been a long time since I’ve done SMD soldering but I could probably get it done – but finding the right chip and alll of the hassling around means it’s likely cheaper just to go scorched-Earth and buy a new MB.
Any suggestions would be appreciated – and again, apologies for resurrecting an old thread but… looking for answers to something I didn’t think was possible.
And yeah, someone should’ve engineered a BIOS write-disable a long, long time ago. What are these people thinking?