Did you manually update your Secure Boot Keys ?

Margarita said:

I am confused about those people who are taking the all steps and stopping at the revocation of the old cert “Windows Production CA 2011”, assuming that Microsoft will do so later.
Isn't Not doing revocation this certificate just as dangerous as doing nothing at all? Am I missing something?

Click to expand...

They're hedging against the possibility they'll need something that's still signed with the 2011 cert. Personally, I doubt that will happen, so I revoked it on my system. As for it only covering a single threat, we really don't know that. It's been around for over 14 years, so the likelihood that more then one person has taken a run at cracking it is certainly possible. I'm sure there are lots of people that have revoked the 2011 cert, I rate the likelihood of Microsoft "needing" it for an update as pretty small.

Another point is Microsoft has published instructions on how to revoke the certificate and precautions to observe, especially if you're using BitLocker.

Hi,

we are running servers using VMware VM, not sure if anyone can provide some help on the issue we are facing.

I have done some testing, and apparently, the certificates in the VM UEFI depends on the VM hardware version, regardless of the physical ESXi host UEFI has the 2023 certificates or not:
- VM deployed with latest VM hardware version 21 comes with the 3 new 2023 certificates, except the one for Option ROM
- VM deployed with older VM hardware version 13 comes only with the 3 x 2011 certificates

The problem we having now is that we have a whole bunch of Windows VMs deployed previously with older VM hardware version 13, and they only have the 2011 certs. I tested on one machine using the step 1 to 3 in How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support, and the output is not showing up the KEK 2023 certificate.



How then can we add in this KEK certificate then? I heard we can add in via the BIOS, but the VMware BIOS screen is very simplistic with only boot manager options and nothing on the secure boot keys (see attached screenshot). I also have concern over using Mosby tool as this is from 3rd party and we are dealing with. Any advise on how to deal with this? Thank you.

toskysea said:

Hi,

we are running servers using VMware VM, not sure if anyone can provide some help on the issue we are facing.

I have done some testing, and apparently, the certificates in the VM UEFI depends on the VM hardware version, regardless of the physical ESXi host UEFI has the 2023 certificates or not:
- VM deployed with latest VM hardware version 21 comes with the 3 new 2023 certificates, except the one for Option ROM
- VM deployed with older VM hardware version 13 comes only with the 3 x 2011 certificates

The problem we having now is that we have a whole bunch of Windows VMs deployed previously with older VM hardware version 13, and they only have the 2011 certs. I tested on one machine using the step 1 to 3 in How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support, and the output is not showing up the KEK 2023 certificate.

View attachment 148021

How then can we add in this KEK certificate then? I heard we can add in via the BIOS, but the VMware BIOS screen is very simplistic with only boot manager options and nothing on the secure boot keys (see attached screenshot). I also have concern over using Mosby tool as this is from 3rd party and we are dealing with. Any advise on how to deal with this? Thank you.

Click to expand...

Have you seen this? HERE there is a community discussion about doing this on the Broadcom site

Aramil said:

Have you seen this? HERE there is a community discussion about doing this on the Broadcom site

Click to expand...

Thanks for the link. Have tried setting uefi.allowAuthBypass = "TRUE" on the VM and able to see the secure boot configurations. I mounted the KEK certificate as an ISO to the VM and when choose to enroll, it wasn't able to detect the ISO for the cert selection for enroll. I have logged a case with Broadcom to see if they can advise.

KevTech said:

Revoking will happen automatically next year.

Did you manually update your Secure Boot Keys ?

You still have 9 months, Mosby takes less than 2 minutes flat and you will also learn something at the same time. I followed MS instructions and it took me maybe 2 minutes max without having to disable or put secure boot into setup mode. Everything you need can also be found in Microsoft github.

www.elevenforum.com

Click to expand...

That's speculation but not fact. As you know, there are no certainties or guarantees in life except for two things, death and taxes. You talk about next year which is basically the future, you could not even see next week as do you really know how long you will actually live and when and how you will die? If you did, you would not be here talking and people would pay big money while you are somewhere enjoying your life. And you are being too dependent on Microsoft, they do not owe you anything and they have made enough promises as I have been using Microsoft Windows since 1.0 and other than having a big software library which is the reason I am using it but it's neither stable and it will eventually run out of resources. Each and every day, it is what is helping me watch my almost $US22Million in assets as I do make 1/3rd of what Bill Gates makes daily so every minute of time is actually costly and yet I still like to help people for free everywhere because I enjoy participating in forums. I am also a Microsoft Corporation shareholder where the company is known as MSFT and not MSC as MSC is a completely different company which can either be a shipping company known as MSC (
Mediterranean Shipping Company) or Discover real-time MSC Industrial Direct Company, Inc. So bottom line is since it's your computer, you can decide what to do. You can spent 2 minutes of time and try different things just to learn and gain experience or you can increase risk by believing that Microsoft will "automatically" do things for you. Besides, a good example is this:

This is a big security hole since August 2024 which was over 13 months ago or 1 year and 1 month, do you see Microsoft "automatically" fixing it yet when what is said in the article should have been a temporary workaround and it should have been fixed in the monthly updates or future builds of the Windows Operating System software. I mean let me ask you, did you even know about that security issue in the first place even though it was also on the forums here posted by @Brink at KB5042562 Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates but there is no discussion except by a few people including myself.

The whole point of security fixes and notices including secure boot keys is so you can fix the problem before it happens as until you "automatically" get the fix from Microsoft which may or may never happen, there will be bad actors out there who will do whatever it takes to get into your system when you leave the door wide opened for someone to take over the system and also being a security risk, did you know your Internet Provider can shut your entire connection down if you were infected or something because you would be a carrier and infect others if you were still connected.

BrianInEngland said:

Same here, desktop PC (weighing in at 30kg!)
I'm the only user
BIOS updates come direct from MSI
Software updates come from MS/vendor only
I don't click on any iffy sites or illegally stream content

I NEVER click on an email link unless I know who's sent it (MS Safelinks covers that as well)

Click to expand...

One user or no users. If someone wanted to get control of your system, they will. They can make your HDD spin backwards and kill itself which I have personally experienced before. Unless your computer is not connected, everything except the kitchen sink will be a risk. That's almost like you saying, you don't need security software just because there is nothing on your computer.

Buddywh said:

I'm curious how MS will enforce the "...no option to be disabled." part (at the very end) if something as simple as deleting all keys (in BIOS settings, done to put it in SETUP mode) will delete the DBX variable too? It did when I wanted to back out of revoking the 2011 certificate as I was experimenting at first.

Afterwords, restoring default keys gets you right back where you were but without the revoked key in DBX any more.

Click to expand...

They can at the OS level only but the other part, Microsoft can't do anything as the UEFI specification is not written by Microsoft and it's what is in the latest UEFI specifications that matters as mentioned here:

Intel has weight on the specification but not Microsoft since Microsoft is only a Operating System vendor and needs to be in compliance and can only use what the UEFI specifications allow.

As for Mosby, I have personally used Mosky's generated unique PK to sign both shellx64.efi and PowerMonkey.efi with the Mosby provided key using the Microsoft signing tool so I can now boot with PowerMonkey with Secure Boot enabled and actually undervolt to get around Microsoft blocking the access the the MSR registers needed when Virtualization Based Security is enabled so that already is a benefit provided by Mosby.

toskysea said:

Thanks for the link. Have tried setting uefi.allowAuthBypass = "TRUE" on the VM and able to see the secure boot configurations. I mounted the KEK certificate as an ISO to the VM and when choose to enroll, it wasn't able to detect the ISO for the cert selection for enroll. I have logged a case with Broadcom to see if they can advise.

Click to expand...

Not sure if this will help but try reading this:

The .der files you need are located at secureboot_objects/PreSignedObjects at main · microsoft/secureboot_objects
which are the same 4 certificates needed:
1) Microsoft Corporation KEK 2K CA 2023 (KEK) secureboot_objects/PreSignedObjects/KEK/Certificates/microsoft corporation kek 2k ca 2023.der at main · microsoft/secureboot_objects

2) Microsoft Corporation UEFI CA 2023 (DB)

3) Microsoft Option ROM UEFI CA 2023 (DB)

4) Windows UEFI CA 2023 (DB)

Almighty1 said:

They can at the OS level only but the other part, Microsoft can't do anything as the UEFI specification is not written by Microsoft and it's what is in the latest UEFI specifications that matters as mentioned here:
...

Intel has weight on the specification but not Microsoft since Microsoft is only a Operating System vendor and needs to be in compliance and can only use what the UEFI specifications allow.

As for Mosby ....

Click to expand...

That all suggests to me that, absent BIOS updates, Microsoft's pushing the 2023 certificates into the secure boot variables might work but can still be very fragile if people do not also get BIOS updates that add them as defaults. I still see people doing a CMOS reset, restoring a saved profile, replacing battery, whatever, then loosing secure boot.

Not all that many average users know BIOS updates are even possible, or would prevent this. And of those who do so many think they're too risky unless given a very good reason to do it. This would be a good one but board mfr's don't provide release notes that tell you what the update does... mine didn't for either of my boards.

People who use MOSBY aren't very much at risk since we're aware of the situation and would be able to recover readily enough.

I have talked to a number of my friends who are not "computer savvy", and they have no idea what I'm talking about! If Microsoft is depending on the users to do anything with this update, they're living in a dream world for 98% of the users!

If the kind of guidance I see in the Microsoft documents is any guide to what they'd provide to "average users", it's hopelessly beyond them to help us at any rate!

I honestly think it's only the computer "press" that could help with alerting people to what's coming, how it affects them, and what they can do. But so much of what I've read suggests the approach is simply that Microsoft will handle it with updates so just be ready for them. I feel they should be very forthright and tell them that if they're lost about the whole thing, then take it to a computer repair shop and have them make sure their system is ready for it with necessary BIOS updates. And prepare us for the possibility their system may have been orphaned, with no BIOS updates coming, so the only way is a new system or run with the risk of not having Secure Boot. I haven't seen that sort of advice yet.

Buddywh said:

If the kind of guidance I see in the Microsoft documents is any guide to what they'd provide to "average users", it's hopelessly beyond them to help us at any rate!

I honestly think it's only the computer "press" that could help with alerting people to what's coming, how it affects them, and what they can do. But so much of what I've read suggests the approach is simply that Microsoft will handle it with updates so just be ready for them. I feel they should be very forthright and tell them that if they're lost about the whole thing, then take it to a computer repair shop and have them make sure their system is ready for it with necessary BIOS updates. I haven't seen that sort of advice yet.

Click to expand...

The problem is, what computer shop do you trust to actually do this properly? I know some of the so-called "experts" at various computer repair and/or sales venues couldn't find their butt with a ten man working party. I have seen some that are quite good, but sadly that's not typically the norm.

Buddywh said:

I still see people doing a CMOS reset, restoring a saved profile, replacing battery, whatever, then loosing secure boot.

Click to expand...

In which case they should be able to "simply" disable Secure Boot, boot Windows, which should reinstall the missing KEK and DB 2023 certs automatically for them, and then reboot to re-enable Secure Boot.

It's not that difficult for the OS to check the Secure Boot variables on every boot and reinstall the KEK and DB certs without the user having to do anything about it, since that uses the same process that Microsoft already uses to install DBX updates (though, AFAIK, those DBX updates tend to be accomplished as part of a visible OS update i.e. "Patch Tuesday", but there's really nothing preventing Microsoft from doing the same silently, as needed, every time Windows boots).

Outside of requiring the user to be savvy enough to understand that they need to disable Secure Boot, and figure out how to do so (which I agree could be a major hurdle to a lot of people) the only other hurdle is that Microsoft needs to have an installation package that was signed by the platform manufacturer for the KEK installation, which means that your platform's PK must be listed at secureboot_objects/PostSignedObjects/KEK/kek_update_map.json at main · microsoft/secureboot_objects). However, that list is fairly comprehensive, and should cover the vast majority of people.

Even as the purveyor of Mosby, my current view then is that it shouldn't be that difficult for Microsoft to get this "restore the 2023 certs in case they were erased" process right, and that, once a few people have run into the issue and posted their workaround online, folks should be able to figure out that they need to boot Windows once, with Secure Boot disabled, to sort themselves out. And I also expect that the vast majority of people, with some online guidance, should also be able to figure out how to toggle Secure Boot for their platform, so I am not that pessimistic about CMOS reset or clear keys operations, on out of support UEFI platforms.

My biggest worry is actually whether the people affected will bother re-enabling Secure Boot after they ran into the issue.
But then again, considering how many people either willingly (enrolling the Ventoy MOK basically disables Secure Boot) or unwillingly (MSI's defaults for Secure Boot pretty much equating disabled, even when Secure Boot is on) run their platform without a working Secure Boot, this may not change much of anything...

Akeo said:

My biggest worry is actually whether the people affected will bother re-enabling Secure Boot after they ran into the issue.
But then again, considering how many people either willingly (enrolling the Ventoy MOK basically disables Secure Boot) or unwillingly (MSI's defaults for Secure Boot pretty much equating disabled, even when Secure Boot is on) run their platform without a working Secure Boot, this may not change much of anything...

Click to expand...

If you're going to neuter the Secure Boot, it would seem pointless to bother with it at all!

gunrunnerjohn said:

If you're going to neuter the Secure Boot, it would seem pointless to bother with it at all!

Click to expand...

Well, for both the examples I highlighted, this happens mostly because the user does not understand what the default settings do, so I would say in both case, it's pretty much unintentional (even if, IMO, the Ventoy users should probably try to get a better grasp of what they are doing, and, more importantly, the Ventoy dev should really have fixed this security hole, though, of course, they do have a vested interest in keeping users, who mostly see Secure Boot as a hindrance, happy).

Can anyone tell me which keys I have by this pic?

man00 said:

Can anyone tell me which keys I have by this pic?
View attachment 148349

Click to expand...

Click on the "Authorized Signature" line (that's DB). A menu opens up (it does on my two modern motherboards)... click on the "details" line and it should list the keys that are in it. You can do the same with the others.

The lines that say FACTORY have only the default keys that come with the BIOS; at least that's what they are on my mobo's.

I'd be interested in the Forbidden Signatures, that's DBX. It says "mixed", which is a mix of the factory default keys and something that was added in later. By who, and what.

When I've run MOSBY, which completely populates all the variables when they are empty, PK, KEK and DB are listed as EXTERNAL, I've assumed meaning using only keys that were added in with none of the factory default keys left in which would be expected with MOSBY-ized system.

Buddywh said:

Click on the "Authorized Signature" line (that's DB). A menu opens up (it does on my two modern motherboards)... click on the "details" line and it should list the keys that are in it. You can do the same with the others.

The lines that say FACTORY have only the default keys that come with the BIOS; at least that's what they are on my mobo's.

I'd be interested in the Forbidden Signatures, that's DBX. It says "mixed", which is a mix of the factory default keys and something that was added in later. By who, and what.

When I've run MOSBY, which completely populates all the variables when they are empty, PK, KEK and DB are listed as EXTERNAL, I've assumed meaning using only keys that were added in with none of the factory default keys left in which would be expected with MOSBY-ized system.

Click to expand...

Here is what I found

Copy the attached script to the root of the C: drive and run this script in an admin command window. It will give you a clear indication of what you have.

powershell -nop -ep bypass -f "C:\Check_EFIBootFileUpdated.ps1"
Here's what the display should look like, post that here.

gunrunnerjohn said:

Copy the attached script to the root of the C: drive and run this script in an admin command window. It will give you a clear indication of what you have.

powershell -nop -ep bypass -f "C:\Check_EFIBootFileUpdated.ps1"
Here's what the display should look like, post that here.

...

Click to expand...

When I run it the script doesn't find the MOSBY key... should it? (Running MOSBY's script does find it.)

Whichever script I ran (after I updated BIOS) it didn't find the MSI keys either. But it did find and report all of Microsoft's keys, including the three 2023 keys. I only found the MSI keys by looking at the DETAILS in BIOS.

Are these scripts looking for specific keys and only reporting on them if they find them?