BlackLotus Becomes First UEFI Bootkit Malware to Bypass Secure Boot on Windows 11

[jagdtigger]

Summary

 

Pretty bad, it carries unpatched binaries to replace the patched ones so it can exploit (old binary signature not in exclusion list according to the article) and a http downloader to communicate with c2 servers. To make matters worse it can disable several protections (defender, bitlocker, hvci).

 

Quotes

Quote

A stealthy Unified Extensible Firmware Interface (UEFI) bootkit called BlackLotus has become the first publicly known malware capable of bypassing Secure Boot defenses, making it a potent threat in the cyber landscape.

"This bootkit can run even on fully up-to-date Windows 11 systems with UEFI Secure Boot enabled," Slovak cybersecurity company ESET said in a report shared with The Hacker News.

 

My thoughts

So now we are back at square one with rootkits wreaking havoc again... Pretty bad look for MS after they talked up their security and pissed off a bunch off ppl with w11 limitations, just to be proven how meaningless all of that is IRL.

 

Sources

 https://thehackernews.com/2023/03/blacklotus-becomes-first-uefi-bootkit.html

[Blqckqut]

i quite like the ui windows 11 brings

but thats all it bascicaly brings imo

it adds a lot of feateres 99.9% of users wont use, and prioritises it over actualy making it a good system sadly

[manikyath]

boy yee, i sure am happy microsoft protects my security by not allowing me to install on my 4790k.

 

Spoiler

this needs an /s so big it might need to be ascii art.

 

[GoodBytes]

You forgot to mention from the article that:

Doesn't work anymore:

Quote

BlackLotus, in a nutshell, exploits a security flaw tracked as CVE-2022-21894 (aka Baton Drop) to get around UEFI Secure Boot protections and set up persistence. The vulnerability was addressed by Microsoft as part of its January 2022 Patch Tuesday update.

 

In other words, keep Windows up-to-date, be careful what you allow as admin, let alone download. Keep you AV up-to-date, and keep your BIOS/UEFI up-to-date.

 

Or move to Russia or any Russian speaking country, as apparently it's geofenced to not do anything in those area based on the article.

Quote

It also features geofencing capabilities to avoid infecting computers in Armenia, Belarus, Kazakhstan, Moldova, Romania, Russia, and Ukraine.

 

[Isuck Assimov]

"Ze TPMs ! Zey do nothing!"

 

[GoodBytes]

12 minutes ago, Assimov said:

"Ze TPMs ! Zey do nothing!"

It has nothing to do with TPM.

Secure Boot is to block rootkits by only accepting bootloaders that is trusted (using digital signature).

 

What is unclear on the article is if you lock Secure Boot to Windows, does it still work? Or it relies on the user to leave it to "Other", which you now fall under how good the UEFI maker cares about security. Like MSI which by-pass Secure Boot, so might as well not exist.

https://arstechnica.com/information-technology/2023/01/300-models-of-msi-motherboards-have-secure-boot-turned-off-is-yours-affected/

[Isuck Assimov]

5 minutes ago, GoodBytes said:

Like MSI which by-pass Secure Boot, so might as well not exist.

*sideeyes my MSI mainboard*

[Radium_Angel]

Laughs in non-MS OS.

[captain_to_fire]

Quote

Pretty bad look for MS after they talked up their security and pissed off a bunch off ppl with w11 limitations, just to be proven how meaningless all of that is IRL.

Eh? Do people really think like this when a new vulnerability is discovered? With this kind of mindset, you might as well just stop using anything because any piece of software/hardware will have vulnerabilities in it.

[wanderingfool2]

2 hours ago, GoodBytes said:

In other words, keep Windows up-to-date, be careful what you allow as admin, let alone download. Keep you AV up-to-date, and keep your BIOS/UEFI up-to-date.

That's actually what has been bothering me about the article, bypassing the UEFI is bad and I think that this might just be the first kind of warning shot for seeing these kinds of things (especially when older hardware no longer receives patches)...but at the same time, the exploit was patched by Windows yet the article clearly quotes that it remains vulnerable (but in the same article mentions delivered by a CVE that was patched).

 

They pretty much offer up contrary information in their article, which is quite important.  If you believe the quote, then they must have found a new delivery method, but then again I am more inclined to believe that it was patched at the moment, and maybe they got a stale quote (or it being the news where they clip out important context of the quote, like if the guy said something to clarify date like back in xyz).  I don't know though, something doesn't sit right, it seems like there might be a bit of information that is still being left out.

[StDragon]

7 hours ago, GoodBytes said:

Or move to Russia or any Russian speaking country, as apparently it's geofenced to not do anything in those area based on the article.

Not geofenced in the public IP sense, but based on the following OS locals.

• Romanian (Moldova), ro-MD
• Russian (Moldova), ru-MD
• Russian (Russia), ru-RU
• Ukrainian (Ukraine) , uk-UA
• Belarusian (Belarus), be-BY
• Armenian (Armenia), hy-AM
• Kazakh (Kazakhstan), kk-KZ

[jagdtigger]

8 hours ago, GoodBytes said:

You forgot to mention from the article that:

Doesn't work anymore:

From the article:
 

Quote

"This is the first publicly known, in-the-wild abuse of this vulnerability," ESET researcher Martin Smolár said. "Its exploitation is still possible as the affected, validly signed binaries have still not been added to the UEFI revocation list."

"BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability," effectively paving the way for Bring Your Own Vulnerable Driver (BYOVD) attacks.

 

[da na]

13 hours ago, manikyath said:

boy yee, i sure am happy microsoft protects my security by not allowing me to install on my 4790k.

 

  Hide contents

this needs an /s so big it might need to be ascii art.

 

I'm so glad my workstation's storage drivers didn't work on 11, so I went back to 10

[wanderingfool2]

15 minutes ago, jagdtigger said:

From the article:
 

 

Yea, the article isn't well written in that respect.  I have a feeling they dropped an important line in the quote or got a stale quote.  The link that they present after the quote brings you to the WeLiveSecurity by ESET website, which doesn't actually mention it still being vulnerable.

 

Instead it goes on about how the BlackLotus uses a specific CVE...which was patched in January.  So my guess is the person writing the article was confused or is misquoting...or has dropped the ball big time in not specifying they are using a new attack vector.

[GoodBytes]

33 minutes ago, jagdtigger said:

From the article:

To add to what @wanderingfool2 said, even if that was the case. The article doesn't state if you set your UEFI to use Windows, then that mean it will only work with Windows. The issue seems to be when set to "Others" (or whatever term the motherboard manufacture wants to use). So even if it was still active, good chance that if your UEFI is set to Windows/Standard or whatever the motherboard wants to call it, you are safe. That also, means that most OEM system is secured as by default, they seem to lock it to Windows support only.

 

Anyways, the article is of poor quality.

[jagdtigger]

6 minutes ago, GoodBytes said:

The article doesn't state if you set your UEFI to use Windows, then that mean it will only work with Windows.

Come on, its right in my quote:

Quote

"BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability,"

Meaning switching the UEFI to windows wont do a thing until MS finally cares enough to blacklist the outdated binaries signatures.

[leadeater]

47 minutes ago, jagdtigger said:

Meaning switching the UEFI to windows wont do a thing until MS finally cares enough to blacklist the outdated binaries signatures.

They have, that's what the patch is for.

 

I don't think you fully understand that this is.

 

All 3 of the affected UEFI boot loaders are from 3rd party companies that provide boot loaders for tools like data recovery etc. These are signed by Microsoft as part of supporting non-Microsoft UEFI secure boot, using Microsoft's 3rd party CA chain. Restricting your system to Microsoft only will only allow Windows to boot which is signed with a different Microsoft 1st party only CA chain only for Microsoft.

 

Quote

Eurosoft Boot Loader (CVE-2022-34301)
New Horizon Data Systems Inc Boot Loader (CVE-2022-34302), and
Crypto Pro Boot Loader (CVE-20220-34303)

https://thehackernews.com/2022/08/researchers-uncover-uefi-secure-boot.html

 

Quote

But until the revocation of the vulnerable bootloaders that BlackLotus depends on happens

https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

 

It's also important to point out the Microsoft does not control the UEFI revocation list, that is UEFI Forum which Microsoft is part of. Even then adding them to the list still requires BIOS and motherboard vendors to get this new list and issue firmware updates and people to actually install them. This also requires the 3 affect companies to get their boot loaders re-signed and distributed. Just outright blocking them will actually impede these companies unfairly which would result in severe criticism and claims that Microsoft could start blocking anyone else including Linux "because".

 

As far as I understand this yes setting the Secure Boot Mode/Policy to Windows only will prevent this along with having both monthly patches mentioned in these articles installed.

 

More supplementary information for the required vulnerability to do this (Baton Drop, CVE-2022-21894)

Quote

This issue was fixed by two different changes:

• After attempting to load a serialised Secure Boot policy, if no policy was loaded, and Secure Boot is enabled, and the boot application was not loaded directly by UEFI firmware, and the boot application is not bootmgr, boot application initialisation fails.
• When loading a boot application, if it has a VERSIONINFO resource containing an OriginalFilename, if that filename is included in a blocklist (containing bootmgr.exe and hvloader.exe; in Nickel, hvloader.efi was added but this did not get backported), the load fails.
  • In Windows 8 and Windows 8.1, hvloader.exe is not included in winload's blocklist - it originally was, which broke Hyper-V loading!
  • Since Windows 10 version 1809, if a certain flags bit is set (used with flightedbootmgr element to load bootmgr from disk), the OriginalFilename is required to be bootmgr.exe.

  https://github.com/Wack0/CVE-2022-21894

 

These issues are complicated because many different factors and companies are involved, and it's reliant on systems being updated which we all know very well does not happen and some go out of their way to not update.

 

Quote

"Many critical vulnerabilities affecting security of UEFI systems have been discovered in the last few years," Smolár said. "Unfortunately, due the complexity of the whole UEFI ecosystem and related supply-chain problems, many of these vulnerabilities have left many systems vulnerable even a long time after the vulnerabilities have been fixed – or at least after we were told they were fixed."

 

[jagdtigger]

13 minutes ago, leadeater said:

I don't think you fully understand that this is.

Yeah look whose talking, exactly waht part isnt clear about "BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability," ? Yes the loaders got patched, but you can stick that up your butt if the malware brings in the still trusted vulnerable variants.

/EDIT
Almost forgot about the FW update farce, yeah. Unless you have something recent you are screwed.

[leadeater]

5 minutes ago, jagdtigger said:

Yeah look whose talking, exactly waht part isnt clear about "BlackLotus takes advantage of this, bringing its own copies of legitimate – but vulnerable – binaries to the system in order to exploit the vulnerability," ? Yes the loaders got patched, but you can stick that up your butt if the malware brings in the still trusted vulnerable variants.

You didn't read the post at all did you, that's very sad that you are willing to stay ignorant to this issue. If you want to be informed read it, if you don't that is your choice. Commenting as if you know what is going on and who is to blame however will just make you look bad.

[Rairii]

In an ideal world, the UEFI Forum would indeed control the dbx signing keys. I too wish that were the case, as maybe there'd at least be a public timeline for the revocation of 10 years of vulnerable Windows bootloaders by now.

 

Unfortunately this is not an ideal world, and the dbx signing keys are controlled by Microsoft. Just look at https://uefi.org/revocationlistfile :

 

Quote

dbxupdate.bin already contains a Microsoft KEK signature (encoded as specified by the UEFI spec).

Quote

UEFI Download Page Terms of Use for Microsoft Corporation's UEFI Revocation List file ("UEFI Revocation List")

 

Meanwhile, you obviously did not read the baton drop writeup fully, leadeater:

Quote

No known vulnerable boot application has been revoked yet.

• Until revocation happens, an attacker can just bring their own vulnerable bootloader(s).
• Revocation would cause all existing Windows installation/recovery media, and old backups, to fail to boot.
  • Boot failure would occur even with Secure Boot disabled due to bootmgr checking its own signature.

 

[leadeater]

33 minutes ago, Rairii said:

Meanwhile, you obviously did not read the baton drop writeup fully, leadeater:

Yes I did. Look I get that people want to hate on Microsoft, that is easy. Microsoft is a key partner and provider of the key signing system and process for Secure Boot but the responsibility and authority to update the revocation list is the UEFI Forum not solely Microsoft, how something is added to list is the important part not who does it. The reason for that is to mitigate accusations of Microsoft trying to be a bad actor and having undue control over computer systems. Microsoft could have never offered 3rd party signing support and never added in a process to allow non Microsoft operating systems to secure boot but they did. Should this have fallen on Microsoft, no of course not however no one else was stepping up since it's a huge and complicated commitment.

 

The reason behind why revoking vulnerable boot loaders effects Windows/Microsoft is that would have to include ALL prior versions of the Microsoft ones with the vulnerabilities in them that have been patched. Baton Drop does not work on patched systems with patched Microsoft boot loaders. For this, Black Lotus, to be deployed and to exploit Baton Drop it is required that older vulnerable versions are obtained/deployed and the system rebooted causing these to be loaded in so Baton Drop can be exploited it.

 

This of course requires that either a user runs an application with administrative privileges or a privileged escalation attack is achieved.

 

This however does not change that if the system is set to Secure Boot mode of Windows only that custom MOK keys and the SHIM process for 3rd party operating systems is disabled/disallowed defeating Black Lotus entirely

[Rairii]

For many years dbx updates were only distributed in Windows update packages by MS. The rest of the UEFI Forum have exactly zero impact on what gets signed, MS control all the keys. The UEFI Forum just controls the specifications, to which UEFI firmware implementations are *supposed* to abide by.

 

Any secure boot bypass would require admin rights or physical access to set up in the first place (writing to EFIESP needs admin rights), an attacker bringing a vulnerable bootloader doesn't change that.

 

Yes, it's true that if the MS third party cert isn't trusted, BlackLotus' bootloader doesn't work. The initial exploit payload that sets up MokList, however, will have ran successfully.

 

The more hilarious issue with BlackLotus' use of shim, is that shim honours revocation lists - Microsoft could easily revoke the self-signed cert used, or the bootloader binaries!

 

This is a problem with BlackLotus in particular, but the next bootkit to show up could well do something different. I've already heard of people getting inspired by this...

[stribika]

30 minutes ago, leadeater said:

the responsibility and authority to update the revocation list is the UEFI Forum not solely Microsoft, how something is added to list is the important part not who does it. The reason for that is to mitigate accusations of Microsoft trying to be a bad actor and having undue control over computer systems.

 

 

Check the KEK. Until today, this was the only key on my machine. What is in yours?

SHA1 Fingerprint: 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30
Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           61:0a:d1:88:00:00:00:00:00:03
       Signature Algorithm: sha256WithRSAEncryption
       Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
       Validity
           Not Before: Jun 24 20:41:29 2011 GMT
           Not After : Jun 24 20:51:29 2026 GMT
       Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
               Public-Key: (2048 bit)
               Modulus:
                   00:c4:e8:b5:8a:bf:ad:57:26:b0:26:c3:ea:e7:fb:
                   57:7a:44:02:5d:07:0d:da:4a:e5:74:2a:e6:b0:0f:
                   ec:6d:eb:ec:7f:b9:e3:5a:63:32:7c:11:17:4f:0e:
                   e3:0b:a7:38:15:93:8e:c6:f5:e0:84:b1:9a:9b:2c:
                   e7:f5:b7:91:d6:09:e1:e2:c0:04:a8:ac:30:1c:df:
                   48:f3:06:50:9a:64:a7:51:7f:c8:85:4f:8f:20:86:
                   ce:fe:2f:e1:9f:ff:82:c0:ed:e9:cd:ce:f4:53:6a:
                   62:3a:0b:43:b9:e2:25:fd:fe:05:f9:d4:c4:14:ab:
                   11:e2:23:89:8d:70:b7:a4:1d:4d:ec:ae:e5:9c:fa:
                   16:c2:d7:c1:cb:d4:e8:c4:2f:e5:99:ee:24:8b:03:
                   ec:8d:f2:8b:ea:c3:4a:fb:43:11:12:0b:7e:b5:47:
                   92:6c:dc:e6:04:89:eb:f5:33:04:eb:10:01:2a:71:
                   e5:f9:83:13:3c:ff:25:09:2f:68:76:46:ff:ba:4f:
                   be:dc:ad:71:2a:58:aa:fb:0e:d2:79:3d:e4:9b:65:
                   3b:cc:29:2a:9f:fc:72:59:a2:eb:ae:92:ef:f6:35:
                   13:80:c6:02:ec:e4:5f:cc:9d:76:cd:ef:63:92:c1:
                   af:79:40:84:79:87:7f:e3:52:a8:e8:9d:7b:07:69:
                   8f:15
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           1.3.6.1.4.1.311.21.1:  
               ...
           X509v3 Subject Key Identifier:  
               62:FC:43:CD:A0:3E:A4:CB:67:12:D2:5B:D9:55:AC:7B:CC:B6:8A:5F
           1.3.6.1.4.1.311.20.2:  
               .
.S.u.b.C.A
           X509v3 Key Usage:  
               Digital Signature, Certificate Sign, CRL Sign
           X509v3 Basic Constraints: critical
               CA:TRUE
           X509v3 Authority Key Identifier:  
               45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8
           X509v3 CRL Distribution Points:  
               Full Name:
                 URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl
           Authority Information Access:  
               CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
   Signature Algorithm: sha256WithRSAEncryption
   Signature Value:
       d4:84:88:f5:14:94:18:02:ca:2a:3c:fb:2a:92:1c:0c:d7:a0:
       d1:f1:e8:52:66:a8:ee:a2:b5:75:7a:90:00:aa:2d:a4:76:5a:
       ea:79:b7:b9:37:6a:51:7b:10:64:f6:e1:64:f2:02:67:be:f7:
       a8:1b:78:bd:ba:ce:88:58:64:0c:d6:57:c8:19:a3:5f:05:d6:
       db:c6:d0:69:ce:48:4b:32:b7:eb:5d:d2:30:f5:c0:f5:b8:ba:
       78:07:a3:2b:fe:9b:db:34:56:84:ec:82:ca:ae:41:25:70:9c:
       6b:e9:fe:90:0f:d7:96:1f:e5:e7:94:1f:b2:2a:0c:8d:4b:ff:
       28:29:10:7b:f7:d7:7c:a5:d1:76:b9:05:c8:79:ed:0f:90:92:
       9c:c2:fe:df:6f:7e:6c:0f:7b:d4:c1:45:dd:34:51:96:39:0f:
       e5:5e:56:d8:18:05:96:f4:07:a6:42:b3:a0:77:fd:08:19:f2:
       71:56:cc:9f:86:23:a4:87:cb:a6:fd:58:7e:d4:69:67:15:91:
       7e:81:f2:7f:13:e5:0d:8b:8a:3c:87:84:eb:e3:ce:bd:43:e5:
       ad:2d:84:93:8e:6a:2b:5a:7c:44:fa:52:aa:81:c8:2d:1c:bb:
       e0:52:df:00:11:f8:9a:3d:c1:60:b0:e1:33:b5:a3:88:d1:65:
       19:0a:1a:e7:ac:7c:a4:c1:82:87:4e:38:b1:2f:0d:c5:14:87:
       6f:fd:8d:2e:bc:39:b6:e7:e6:c3:e0:e4:cd:27:84:ef:94:42:
       ef:29:8b:90:46:41:3b:81:1b:67:d8:f9:43:59:65:cb:0d:bc:
       fd:00:92:4f:f4:75:3b:a7:a9:24:fc:50:41:40:79:e0:2d:4f:
       0a:6a:27:76:6e:52:ed:96:69:7b:af:0f:f7:87:05:d0:45:c2:
       ad:53:14:81:1f:fb:30:04:aa:37:36:61:da:4a:69:1b:34:d8:
       68:ed:d6:02:cf:6c:94:0c:d3:cf:6c:22:79:ad:b1:f0:bc:03:
       a2:46:60:a9:c4:07:c2:21:82:f1:fd:f2:e8:79:32:60:bf:d8:
       ac:a5:22:14:4b:ca:c1:d8:4b:eb:7d:3f:57:35:b2:e6:4f:75:
       b4:b0:60:03:22:53:ae:91:79:1d:d6:9b:41:1f:15:86:54:70:
       b2:de:0d:35:0f:7c:b0:34:72:ba:97:60:3b:f0:79:eb:a2:b2:
       1c:5d:a2:16:b8:87:c5:e9:1b:f6:b5:97:25:6f:38:9f:e3:91:
       fa:8a:79:98:c3:69:0e:b7:a3:1c:20:05:97:f8:ca:14:ae:00:
       d7:c4:f3:c0:14:10:75:6b:34:a0:1b:b5:99:60:f3:5c:b0:c5:
       57:4e:36:d2:32:84:bf:9e

 

[leadeater]

15 minutes ago, stribika said:

Check the KEK. Until today, this was the only key on my machine. What is in yours?

I'll have to check my work computer, my home systems is old as hell and not running secure boot.

 

27 minutes ago, Rairii said:

For many years dbx updates were only distributed in Windows update packages by MS. The rest of the UEFI Forum have exactly zero impact on what gets signed, MS control all the keys. The UEFI Forum just controls the specifications, to which UEFI firmware implementations are *supposed* to abide by.

We aren't talking about the signing, we are talking about the revocation....

 

Anyone can submit to Microsoft to get signed, provided you pass the checks signing will happen.

 

Signing != revocation

 

edit:

27 minutes ago, Rairii said:

The more hilarious issue with BlackLotus' use of shim, is that shim honours revocation lists - Microsoft could easily revoke the self-signed cert used, or the bootloader binaries!

Revoking a self sign here will do nothing, what that key is does not matter and can be generated at any point since it's being loaded in as part of the deploy. Revoking all the old Microsoft ones has the issue pointed out in the article, I would prefer that all my Windows backups would remain bootable for my required retention period. It wouldn't be the end of the world however since a full system restore to a recovery point that old is rare but still not being able to do it is a problem.

 

Security is about balance, assessing risks, evaluating impacts. Microsoft likely sees revoking all their older bootloaders as too high impact for the potential risk of this.

[Rairii]

Revocation lists are themselves signed.