Unkillable UEFI Malware Bypassing Secure Boot Enabled By Unpatchable Windows Flaw (arstechnica.com) 115
Researchers have announced a major cybersecurity find -- the world's first-known instance of real-world malware that can hijack a computer's boot process even when Secure Boot and other advanced protections are enabled and running on fully updated versions of Windows. From a report: Dubbed BlackLotus, the malware is what's known as a UEFI bootkit. These sophisticated pieces of malware hijack the UEFI -- short for Unified Extensible Firmware Interface -- the low-level and complex chain of firmware responsible for booting up virtually every modern computer. As the mechanism that bridges a PC's device firmware with its operating system, the UEFI is an OS in its own right. It's located in an SPI-connected flash storage chip soldered onto the computer motherboard, making it difficult to inspect or patch. Because the UEFI is the first thing to run when a computer is turned on, it influences the OS, security apps, and all other software that follows. These traits make the UEFI the perfect place to run malware. When successful, UEFI bootkits disable OS security mechanisms and ensure that a computer remains infected with stealthy malware that runs at the kernel mode or user mode, even after the operating system is reinstalled or a hard drive is replaced.
As appealing as it is to threat actors to install nearly invisible and unremovable malware that has kernel-level access, there are a few formidable hurdles standing in their way. One is the requirement that they first hack the device and gain administrator system rights, either by exploiting one or more vulnerabilities in the OS or apps or by tricking a user into installing trojanized software. Only after this high bar is cleared can the threat actor attempt an installation of the bootkit. The second thing standing in the way of UEFI attacks is UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that each piece of software used during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that will prevent attackers from replacing the intended bootup firmware with malicious firmware. If a single firmware link in that chain isn't recognized, Secure Boot will prevent the device from starting.
As appealing as it is to threat actors to install nearly invisible and unremovable malware that has kernel-level access, there are a few formidable hurdles standing in their way. One is the requirement that they first hack the device and gain administrator system rights, either by exploiting one or more vulnerabilities in the OS or apps or by tricking a user into installing trojanized software. Only after this high bar is cleared can the threat actor attempt an installation of the bootkit. The second thing standing in the way of UEFI attacks is UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that each piece of software used during startup is trusted by a computer's manufacturer. Secure Boot is designed to create a chain of trust that will prevent attackers from replacing the intended bootup firmware with malicious firmware. If a single firmware link in that chain isn't recognized, Secure Boot will prevent the device from starting.
read-only jumper (Score:5, Informative)
Back in the old days you had to physically move a jumper to flash your firmware. Because it turns out you didn't want some remote actor doing it for you when you aren't around.
Re: (Score:2)
Back in the old days you had to physically move a jumper to flash your firmware. Because it turns out you didn't want some remote actor doing it for you when you aren't around.
That's fine for your home PC; it's not so convenient when you're trying to update the hundreds or thousands of desktops being used by your company.
Comment removed (Score:5, Insightful)
Comment removed (Score:4, Insightful)
Re: (Score:2)
Exact diametric opposite. Ergonomics are critical. Good hardware is critical. Conveniently placed restroom facilities are critical.
Heck, even convenient ways to clock in are critical.
Re: (Score:2)
Re: (Score:2)
Ironically, convenience is a subsection of efficiency, and efficiency is a method on how to generate more output with less work.
Re: (Score:2)
Re: (Score:2)
And this mindset is why we can't have good things. Because there will always be those idiots who will react to your "we should have more stringent controls on police brutality" with both "we should defund the police" and "they're trying to defund the police".
Re: (Score:2)
NIST no longer recommends scheduled password changes, because it is bad for security. It is also bad for convenience. So when you get rid of it, you are going left and right at the same time.
Re: (Score:3, Insightful)
Re:read-only jumper (Score:5, Insightful)
Back in the old days you had to physically move a jumper to flash your firmware. Because it turns out you didn't want some remote actor doing it for you when you aren't around.
That's fine for your home PC; it's not so convenient when you're trying to update the hundreds or thousands of desktops being used by your company.
Are you kidding? That's exactly how you prevent your entire company falling victim to a ransomware infection all at once. And if you're referring to server hardware, the cost of paying a DC Ops guy to manually verify and coordinate firmware updates via physical button press with your Sustained Operations team initiating it is trivial compared to the cost of a mass attack -- especially one that results in hardware you're really not sure you can trust again.
Re:read-only jumper (Score:4, Interesting)
That's exactly how you get ransomware. None if it writes to the UEFI flash memory, but some of it does take advantage of flaws in UEFI to infect machines.
If you have to manually open thousands of machines, install an update, and then close them back up, it's not going to get done in a timely manner, or maybe not at all.
Because you probably don't want to be doing that every month, you will be trying to figure out from the release notes if you really need it for security reasons, or if it's just performance related. Naturally, patches that fix security flaws tend to be rather vague about what they are doing, so as not to help bad actors develop exploits.
Re:read-only jumper (Score:4, Insightful)
Because you probably don't want to be doing that every month.
That's proof of bad design. The entire point of a secure IPL is to load the basic security components of the OS. (Trusted public keys, encryption algs, and binary loader.) It shouldn't require monthly updates.
If anything it should be small enough that a sane group can do a through security review, and only do what is absolutely necessary to get the security system started. Everything else should be validated by the started security system. Using it's own keys that are embedded in the security system binary. And if you're wondering, No Windows doesn't follow this practice at all.
if you really need it for security reasons, or if it's just performance related
Again, a performance related patch shouldn't be allowed in the basic security components. That's something that would require complete re-validation testing / certification from any compliance tester / regulator worth their salt. I.e. Something that happens during a major OS upgrade, not a bugfix patch on Tuesday.
If you have to manually open thousands of machines, install an update, and then close them back up, it's not going to get done in a timely manner, or maybe not at all.
That is something that should only need to be done once. If it's happening multiple times without having a major OS replacement / redeploy, then once again, it's proof of a bad security design.
This is purely Microsoft's fault, not UEFI's and Microsoft should be held accountable for this crap.
Re: (Score:2)
Nvidia made that mistake. The Nintendo Switch was hacked because a flaw was found in the very early loader code that is stored in ROM and cannot be updated, so Nvidia and Nintendo can't do anything about it.
In any case, on a PC the UEFI has to be somewhat complex to boot the machine. The boot device has to be set up and read, the display has to work for diagnostic info. On a laptop that might require Thunderbolt to be working too. USB has to work for the keyboard.
Often they do segment the flash memory so th
Re: (Score:2)
Nvidia made that mistake. The Nintendo Switch was hacked because a flaw was found in the very early loader code that is stored in ROM and cannot be updated
The mistake was to not use formal verification for a crucial security component.
Re: (Score:2)
Formal verification is not a guarantee.
Re: (Score:3)
Re:read-only jumper (Score:4, Insightful)
A nice thing about jumpers is that you can connect a switch. So you don't need to open it up, but you do need to be physically present.
For a lights out situation, you can even make that switch remotely operated by a machine that is far less accessible over the net than the servers it helps manage. Not quite as secure, but better by far than a machine with no firmware write disable at all.
Re: (Score:2)
Is there any company anywhere that has actually implemented this for their desktop and laptop computers? I mean back in the day when there were physical jumpers.
Re: (Score:2)
I never needed it for firmware, but I rigged several machines so I could reset them remotely. I wired the jumpers for the reset button to an admin machine's parallel port. Something like that could easily connect to write enable jumpers instead, though today when nobody has a parallel port where the individual pins can be addressed for DIO, I would use an Arduino connected to an admin machine's USB, or use a RaspberryPI or clone.
Re: read-only jumper (Score:2)
Every time a server needs to be patched it had to be rebooted.
With operation 24/7 the window for patching might come once per year.
Even worse for virtualization hosts. Patching Bios/Uefi and the hostong OS might never be possible until the server hardware is replaced.
Re: (Score:2)
HA allows for patching anytime.
Re: (Score:2)
Nobody would dare to do that in a process automation system for a large manufacturing plant because even a small glitch or delay could lead to serious consequences in the process.
Re: (Score:2)
But wouldn't it be swell if I could buy a computer where I can actually HAVE that because I just know that tomorrow is going to be a really, really unpleasant day at work when our management wants to know how we can mitigate that?
Re: (Score:2)
It would be swell. That's why you can't have it.
Hardware manufacturers want to maintain control over that hardware after we buy it. That's why they won't let us flash these things or otherwise access them to protect ourselves from attacks like this. They just tell us to trust them, and of course they immediately let us down.
And there are too few competitors in this domain for us to just switch. They all do this. And this [sysjolt.com]. And probably others that they have kept so secret only they, and a few criminal
Re: (Score:2)
What might be workable is a compromise, by reducing what is flashed, so only something affecting UEFI or the boot process, as well as the BIOS validation engine would require a physical presence to do a BIOS flash. In a company, it may be expensive, but doing this will ensure the hardware isn't in a compromised state if a rogue package jumps out of the hypervisor and decides to do a ninja firmware upgrade.
It would be only a few packages, so that something that patches other parts of the system wouldn't hav
Re: (Score:2)
That's fine for your home PC; it's not so convenient when you're trying to update the hundreds or thousands of desktops being used by your company.
Desktops? Who cares? Servers, worth it. They should have a switch, though, so you don't have to open the case. Preferably a key lock switch, just to raise the bar however slightly.
Re: (Score:2)
That's fine for your home PC; it's not so convenient when you're trying to update the hundreds or thousands of desktops being used by your company.
Yes, it's inconvenient as hell, but the risk/disaster ratio is something to consider.
Having hundreds or thousands of your company's desktops compromised might very well cripple the company to the point of failure. In that case, manually fiddling with thousands of PC jumpers would probably be worth it.
It's a huge pain in the ass for sure, but when failure is not an option sometimes you have to go the extra distance.
Re: (Score:2)
That's fine for your home PC; it's not so convenient when you're trying to update the hundreds or thousands of desktops being used by your company.
The mere fact that updating motherboard's firmware has become one of the corporate "best practices" is one of the biggest fails of the whole UEFI/secure boot/etc idea. Maybe the single biggest one, a truly epic fail.
Re: (Score:2)
Back in the old days you had to physically move a jumper to flash your firmware. Because it turns out you didn't want some remote actor doing it for you when you aren't around.
the UEFI is an OS in its own right.
Back in the day, BIOS wasn't so damn powerful, and could still be limited as you've stated.
Re: (Score:3)
Back in the day bootloader malware existed just as it did now with even more power (since there was nothing to prevent it from happening what so ever). It's the reason secure boot was developed in the first place.
Re: (Score:2)
But as we can see now, secure boot isn't that secure, is it?
Re: (Score:2)
But as we can see now, secure boot isn't that secure, is it?
Indeed. I heard someone died while wearing a seatbelt which shows that seatbelts are useless. /s
Please do a bit of research. You'll find that secure boot is perfectly fine. This is not a secure boot bug. They exploited a *windows* bug, and went to incredible pains to do so unlike the bootload malware of the past for which there was literally nothing hindering it making it so incredibly prevalent that every anti-virus scan specifically included a reboot loop and a check of your boot system in attempts to fin
Re: (Score:3)
Please do a bit of research. You'll find that secure boot is perfectly fine. This is not a secure boot bug. They exploited a *windows* bug
Nonsense. The whole point of existence of secure boot is that bugs in their payloads (operating systems) are expected and anticipated, and by design it should be immune from compromising originating from the exploited payload. Especially persistent compromising as in this case. Unfortunately, this design goal has failed.
If Windows had no bugs, nobody would need secure boot in the first place.
Re: (Score:2)
Secure boot is supposed to let you know the boot files have been tampered with. If it doesn't do that, it's broken, and you can't blame that on Windows.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
> a very tedious and expensive chore
More or less expensive than dealing with ransomware?
=Smidge=
Re: (Score:2)
I agree that moving a jumper, or better yet, a push-button as part of the MB back panel, is way more secure, but then flashing servers in a data center becomes a very tedious and expensive chore.
Nothing says poor security like giving someone a button to make them feel immortal while not actually protecting the user. This malware doesn't modify UEFI. It would not be protected by making the firmware read-only. There's a reason it exploits a *windows flaw* to boot the system.
Re: (Score:3)
The exploit sets a (new) Machine Owner Key. That is a very sensitive operation that should require physical presence.
Re: (Score:2)
Re: (Score:3)
I agree that moving a jumper, or better yet, a push-button as part of the MB back panel, is way more secure, but then flashing servers in a data center becomes a very tedious and expensive chore.
It wouldn't be so tedious nor expensive if the folks who pushed this onto the computing world had thought it through. All that's required is a connector on the PC which, via a relay or properly buffered direct connection, "pushes the button". Then there's a secondary cable or fiber loop running from server to server, connecting all the modules which plug into that connector. The physical layer, protocol, module design, etc. may be standard or custom, the only caveat being that they are not connected to any
Re: (Score:3)
Serial console servers are still a good idea.
They could be cheap today - any SoC with USB multiplexers would do fine.
Your devops can write the config files.
IPMI saves a few bucks by putting all that on a more expensive chip in every device to save wiring costs and decrease security.
Those IPMI stacks usually can't do 802.1x, VLANs, or anything sensible and they almost never get audits or updates.
OpenBoot wins here.
Re: (Score:2)
Serial console servers are still a good idea.
They could be cheap today - any SoC with USB multiplexers would do fine.
If you didn't care about reliability, you could build them out of arduino megas or something. They have four hard ports, plus you could add a bunch of soft ports too. But I think you'd rapidly get to the point where you'd want something like IPMI, just for cabling reasons. It's a lot easier to add another network wire to each server than to now have to dick with serial wiring as well.
What we need instead of specifically IPMI, though, is a standard internal connector where we can connect whatever management
Re: (Score:3)
Back in the old days you had to physically move a jumper to flash your firmware.
This wouldn't have been stopped by that and it didn't prevent bootsector malware from existing back then either. This UEFI Bootkit is installed on the bootable portion of the drive. It has nothing to do with the UEFI other than using a specific flaw to bypass the secure boot check. It's essentially an additional bootloader sitting between the UEFI and the windows bootloader, precisely the kind of thing secureboot was intended to protect against.
What the read only jumper prevents is UEFI firmware implants, b
Re: (Score:2)
Back in the old days you had to physically move a jumper to flash your firmware. Because it turns out you didn't want some remote actor doing it for you when you aren't around.
Back in my day you had to pry a EPROM out of its socket, remove the tape covering over the window and put it in a UV eraser. Only then could you write to it using a dedicated EPROM programmer. Now THAT'S security.
Re: (Score:1)
Re: (Score:2)
Re:read-only jumper (Score:4, Funny)
Back in my day, we had to invent fire to melt the solder for the point-to-point wiring!
Re:read-only jumper (Score:5, Funny)
Back in my day we had to throw rocks at each other to communicate in binary. People were really pissed off when UTF-16 arrived.
Re: (Score:2)
Back in my day we had to throw rocks at each other to communicate in binary. People were really pissed off when UTF-16 arrived.
Wish I still had mod points. I was LMAO for 15 minutes.
Re: (Score:2)
Or hire women with small, steady hands to weave your program into rope memory [wikipedia.org].
Re: (Score:2)
Properly designed UEFI firmware shouldn't need such a jumper. The way it works is that the UEFI code is the only code that can write to flash. It locks the flash memory into read only mode at boot time, and the only way to make it writable again is a power cycle.
The UEFI does all the updating. It requires signed updates stored in a special partition on the boot drive. Malware would need to bypass the signature check, or obtain the private key.
If you are paranoid then a jumper is an option, but realistically
High bar (Score:2)
Only after this high bar is cleared...
Every virus infection in history has managed to clear that bar so maybe it's not quite so high or "formidable" as author thinks it is. Just sayin.
Re: (Score:3)
Every virus infection in history has managed to clear that bar so maybe it's not quite so high or "formidable" as author thinks it is. Just sayin.
That's nonsense. First, you can absolutely have a virus infection on a system which only affects your user profile and files, and still lose data. But beyond that, even many very popular operating systems of the past had no security whatsoever. There are no popular operating systems today which fit this description that I'm aware of, although DOS is still used a whole lot in antiquated-but-still-functional industrial systems.
The vast majority of the virus infections I've had on my own systems have been in D
The "High" Bar. (Score:1)
"One is the requirement that they first hack the device and gain administrator system rights, either by exploiting one or more vulnerabilities in the OS or apps or by tricking a user into installing trojanized software. Only after this high bar is cleared..."
Uh, given the number of exploits that define this process as basically Hacking 101, I'm just curious. How high up you think that bar is?
From Reality's angle, it looks to be about 2 clicks off the ground, with Ignorant and Gullible behind the keyboards as usual.
Que the UEFI World Apologists Tour (Score:2, Interesting)
Re:Que the UEFI World Apologists Tour (Score:5, Interesting)
Microsoft made it harder for everyone else to install linux, wasn't that the point?
Re: (Score:2)
Otherwise it's nice not having to hope you updated the MBR or didn't accidentally move the boot image to another sector within the filesystem without that MBR update.
Re: (Score:2)
And guess what, as we just found out, whether you disable secure boot means fuck all for your security.
Re: (Score:2)
Except that's not the case at all. Please go read up on the topic before you run your ignorant mouth. This isn't a secure boot bug.
Re: (Score:3)
In theory, it's a great approach to securing the platform. In practice, it suffers from Windows-ization: Feature bloat and attempts at lock-in leading to serious bugs all around. Apple has probably done the most effective job of securing the boot chain, but Apple's solution is very proprietary both in terms of the boot protocol and the hardware that implements it.
Re:Que the UEFI World Apologists Tour (Score:4, Insightful)
A basic input-output system should do just that: Boot the operating system, then shut the fuck up and vanish into thin air.
Re: (Score:2)
When you control both the hardware and software production it is a lot easier to secure things. Microsoft needs to accommodate literally dozens of different hardware configurations and many (most?) they don't even have access to until after the software is developed.
Re: (Score:2)
Re: (Score:2)
If you are "not a fan of UEFI", it's probably because you've eaten the FUD you've been fed about SecureBoot (one optional feature of UEFI). The old BIOS was such a pile of hacks built on extensions built on compromises based on a 1981 design for booting 8088s in 16-bit mode. It should have been left in the dustbin years ago; at least Intel FINALLY stopped supporting it a couple of years ago.
And complaining that SecureBoot isn't 100% secure is like saying you shouldn't put a lock on your door because somebod
Re: (Score:3)
If you think that a lock in your door helps, you need to watch this video that shows how long it takes to "break" into your house. https://www.youtube.com/watch?... [youtube.com]
Well obviously it requires skill to be that fast, but if you watch more of his videos, it should become obvious that some locks are so bad that they open just by slapping them with a hand.( https://www.youtube.com/watch?... [youtube.com] )
And if you watch 20 videos or so, you won't trust any lock ever again. The maker of the videos has said that he is making
Re: (Score:2)
because normal people don't know about these issues.
This is the reason that locks still make sense. Locks aren't 100% effective (is anything?) but it keeps the vast majority of people out of your stuff.
Re: (Score:2)
That moment when you don't realize that the same old booting process still exists. It's just moved from BIOS to CPU itself. Search for IME and PSP for Intel and AMD respectively.
And those things are far more awful than old bioses. They're highly secretive nowadays, but hacks we've seen utilize things like web servers built into them by default.
Re: (Score:3)
Is this the "better" we were promised with UEFI? Just curious.
Better in the way of features you didn't really ask for? Fuck Yes. Global leaders. Dunno about you, but I know of no one who asked for most of the features in the $1000 smartphone that used to be half that cost.
Making an 8K 5" screen is enough to make Hollywood directors go blind, but I'll be damned if we won't eventually see 32K screens with consumers that swear they can tell the difference. Much like the audiophiles that insist they need 100,000Hz headphones.
Re: (Score:2, Insightful)
Is this the "better" we were promised with UEFI? Just curious.
Yes very much so. Whereas in the past boot process was a free for all for any software to tamper with, it now requires exploiting specific bugs in OS code.
That is by every definition of the word better. If you're after "perfect" security then I have some really sad news for you...
Re: (Score:2)
About 25 years ago the local computer repair shop had a huge stack of motherboards with BIOS chips wiped by malware.
Back then a lot of manufacturers didn't put BIOS images on their websites. Not that they had a programmer for the chips anyway.
New UEFI acronym (Score:4, Insightful)
How Do You Pronounce UEFI (Score:2)
Re: (Score:2)
NOT exploiting UEFI (Score:2)
A lot of the posts on this story so far are about write protecting UEFI or UEFI being too complex etc etc. This is not exploiting UEFI. It's exploiting the *Windows* boot process and sitting itself as a form of bootloader between UEFI and Windows. It is precisely what Secure Boot was designed to protect against, but (as usual) the weak chain in the link (Windows) broke.
And for all those kneejerkers who are saying "see secure boot doesn't work". I highly recommend you only drive cars without airbags or seatb
Re: (Score:3)
I think the real issues is MICROSOFT, they essentially set themselves up as the authority that gets to decide who is responsible enough, who has enough process in place, who has deep enough pockets to get a get - then they f'up and open the door to exploits....
Microsoft should have never been allowed to be come the entity that control the keys. Its highly anti-competitive. Some sort of IANA like organization should have been formed.
Re: (Score:2)
I think the real issues is MICROSOFT
No that's just a completely off topic anti-secure boot rant you made up in your head that has nothing to do with what is going on.
Microsoft should have never been allowed to be come the entity that control the keys. Its highly anti-competitive.
Microsoft doesn't control any keys. You do. Installing a key into UEFI is trivial and available to everyone for all but specific special purpose devices (reads: ARM, Chromebooks, and Apple (well they aren't even playing)). The only thing Microsoft has done is gotten their keys enabled by default.
They have also shown to be quite willing to cross-sign keys for other OSes, and as a
Re: (Score:2)
Damn dude you're post has some major spin. Here let me point out the important parts for you:
The only thing Microsoft has done is gotten their keys enabled by default.
So Microsoft can package up bootable media without talking to anyone else or getting users to do things that every security practitioner tells them not to do. Everyone else gets to wait for Microsoft to bless them.
willing to cross-sign keys for other OSes, and as a stipulation of Windows device certification that basically every manufacturer gets they require the keys to be customisable by the user.
Right again you're options are get microsoft's blessing, ask user's do things that will confuse and scare them. As to Microsoft's willingness, sure if you PAY them!
Re:NOT exploiting UEFI (Score:4, Interesting)
Re: (Score:3)
It seems to be down to two bugs in the Windows boot process. First, by specifying particular parameters for loading the fake boot application, you can convince the bootloader to throw away the security policy it loaded earlier. The more fundamental bug is that it appears the bootloader treats the fact that there are no policies loaded as meaning "allow everything" when a secure application should default to "deny everything".
And it's not unpatchable as such, though fixing it is a headache. Fixing the bootlo
Re:NOT exploiting UEFI (Score:4, Informative)
But the bootkit could just reinstall the earlier bootloader with the bugs in, which would pass validation unless Microsoft revokes it.
Not just "could" the bootkit actively does this. It ships with a vulnerable version of bootmgfw.efi and bootload.efi (the shim it uses to execute its own custom code) and uses them both. In short this exploit will continue to work until the keys for both are added to the revocation list, which won't happen for the reasons you stated.
This attack vector was incredibly clever, real props to the hackers here. They are exploiting a vulnerability that was patched well over a year ago knowing that MS would screw itself if they blacklisted the vulnerable binaries.
Re: (Score:2)
For those wondering, the reason this attack is viable in the first place is because Microsoft dropped the ball on updating their revocation list against CVE-2022-21894.
"High Bar" to install. (Score:1)
oh, how many escalation privilege 'bugs' have historically existed in Windows...
LOTS.
Which just reveals UEFI's true purpose (Score:3)
Re: (Score:2)
Yep that's its true purpose. Just like the seatbelt's true purpose is to get people to actively engage in a bit of BDSM self-bondage. That's the real reason.
Re: (Score:2)
"secure{ boot is DRM (Score:5, Insightful)
It does serve a security function, but but not one that is for the user. In fact, Digital Restriction Management is specifically targeted at restricting what the user can do. It is no surprise that malware can now bypass this in a way that cannot be stopped. It was never designed to stop malware in the first place.
Re: (Score:2)
Oh come on. From a technical standpoint they may be separate ideas, but they are based on similar technologies and marketed the same way. Most companies try to tell us DRM is essential for security and force it upon us whether it's in our interest or not. After all, nobody will ever argue against more security, right?
I don't trust most of the things people tell me are "essential" for my safety. For example, if you try to force me to use 2FA, I will say FU. In theory, 2FA is a good thing, but in practic
Re: (Score:2)
From Wikipedie: "Computer security, cybersecurity (cyber security), or information technology security (IT security) is the protection of computer systems and networks from attack by malicious actors that may result in unauthorized information disclosure, theft of, or damage to hardware, software, or data, as well as from the disruption or misdirection of the services they provide."
Now, "malicious actor" = "user" and "unauthorised information disclosure" respectively "theft of data", "disruption" and "misdi
Re: (Score:2)
but they are based on similar technologies and marketed the same way.
Indeed we should throw out all encryptions since it's used in DRM. Passwords too. You don't need them. Everything is just DRM and DRM = evil. /s
Re: (Score:2)
As usual, you have no clue. DRM is a security mechanism, quite obviously. It is just not one that works for you, it is one that works for the content mafia. Or would you claim that if you stand before a locked door and do not have the key, that the lock is not a security mechanism?
Re: (Score:2)
Well you've gone and punked yourself. Considering you as the end user are 100% in control of Secureboot's running status, and any keys, and have the ability load custom keys, and even use existing keys along with Moklists (which is what is exploited here) to run custom code of *YOUR* choice, you've demonstrated that you either don't have a clue how DRM works or don't have a clue how secure boot works.
Or would you claim that if you stand before a locked door and do not have the key, that the lock is not a security mechanism?
Secure boot is a locked door, to which you have the key, to which you have the ability to change the barrel
The article is BS (Score:2)
First of all, EFI (now UEFI) was invented by Intel in 1999, not Microsoft. In fact, the first manufacturer to use it was Apple when they switched from PowerPC to Intel. The bug is in Microsoft's boot code, it's not an issue with UEFI. Based on the article, the exploit can be removed by simply wiping the ESP. It's not in SPI memory or anything like that.
Of course if the code that installed the exploit is executed again (with admin privs) you have the same problem - but that's the same as many other explo
Re:The article is BS (Score:5, Informative)
the exploit can be removed by simply wiping the ESP
Nope it's far more complicated than that. Only the initial exploit itself saves itself to ESP. To actually undo everything you need to:
a) wipe ESP.
b) reinstate the correct one since you want a bootable system (which is ironically easy since the malware backs it up for easy uninstallation).
c) remove their entry from the MokList.
d) remove their kernel level driver from windows.
e) fix everything that the malware broke (Fix Defender, fix bit-locker, reenabling HVCI and VBS)
f) do all of the above without triggering a reboot since the kernel level driver in windows will reinstall the malware on boot.
Now that in itself would be easy enough and doable with an appropriate tool except that part of the payload's kernel level driver actively opens handles to all important ESP files so even with system level privileges you can't actually delete them or overwrite them once the windows kernel has loaded, and forcefully closing the handles or otherwise nuking the files triggers a BSOD with (INVALID_KERNEL_HANDLE)
The article is a very simplified view. This is an incredibly advanced piece of malware.
Re: (Score:2)
Dumb question maybe, but can you disable Secure Boot and then boot up to a thumb drive, ostensibly with tools to do the above? This would at least give access to the ESP files.
Obviously not an ideal solution, but perhaps the easiest in light of the fact that booting up the infected Windows will prevent proper disinfection?
Re: (Score:2)
Yes you can. The ESP is the easy part, I think the hardest part would be uninstalling the driver from windows. But as with all malware I'm sure an automated removal tool would will hit the market soon enough if not already.
UEFI joke finally exposed (Score:5, Insightful)
Like so many "breakthroughs", "reforms", "advancements" (pick yer term) the modern "better way" of doing something is often just some jerk's preferred way, and its often actually inferior.
The original boot scheme of the PC was completely secure. The boot code was solid, and worked every time. It was in ROMs on the actual IBM machines, and PROMS or EPROMS on clones, all of which could not be overwritten on-the-fly within a running PC. There was no way somebody could insert malware into such a PC and get it to patch the machine's boot code. When PCs came along with EEPROMS, most had physical jumpers that had to be manually set in order to enable writing to the chip containing the boot code - so it WAS possible to corrupt the boot code, but the person with physical control of the machine had to be an active participant.
Ahhh but Microsoft and friends decided we all needed a "secure" boot system...
All sorts of crap was added to the basic boot function of a PC, making it more of a pain to install whatever OS the owner of the machine wants, and all under the banner of "more secure". Ha. Perhaps "more secure" in the sense that you're more likely to run Windows or a Microsoft approved flavor of Linux running with Windows (more secure for Microsoft). Like so many other security scams, this is not actually more secure in any absolute sense - the old EPROMs achieved that by virtue of not being in-circuit programmable. It seems some people refuse to learn an old lesson: Adding complexity to add security is often actually likely to add vulnerabilities - vulnerabilities that are probably harder to detect and fix.
Some network admin is likely to complain that the old boot ROMs were not remotely patchable - but [A] boot code should be properly tested before being deployed and then NEVER be patched, and [B] it's a poor network admin who would willingly make an invulnerable system vulnerable in exchange for convenience.
Re: (Score:2)
The ROMs on the IBM PC 5150 wouldn't even support a HDD. You had to order new ROMs (or burn patched ones) if you wanted to use one. When total numbers of machines were small and machine prices were very high this was feasible, you could sell customers new ROMs and if they didn't have someone to install them they would reasonably pay the fee to have someone else do it. When we got into large numbers of PCs that simply wasn't feasible any more, there weren't enough techs. We literally had to move to flash BIO