Updating Microsoft Secure Boot keys

great reference: 
https://nbviewer.org/github/microsoft/MSRC-Security-Research/blob/master/presentations/2024_05_OffensiveCon/OffensiveCon24_Booting_With_Caution_BDemirkapi.pdf
Thank you SusanBradleyGeek !

This article appears to have a follow-up and more insights on this matter.
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/revoking-vulnerable-windows-boot-managers/ba-p/4121735?wt.mc_id=MVP_338345

No, I absolutely will not be applying this fix.

Microsoft - you need to do an urgent audit check to be carried out only by your oldest and most trusted high level employees on the integrity of your current staff, especially the ones that are in charge of your Windows software updates and frankly just all round across your organization.

I suspect your workforce is compromised by bad actors who have infiltrated your organization as ordinary employees.

The entire team who worked on this and all related updates occuring prior that have led to the rollout of this update as if it is an ordinary course logical step (including the May 2023 whatever fix that didn't manage to prevent the rollback or whatever garbage explanation provided that made absolutely no sense too), and anyone who vetted, glanced, had any eyes over this - so long as this has passed their desk - needs to be fired asap and blacklisted as threat actors - regardless of their intentions or incompetence.

First - I cannot ever recall Microsoft ever asking its users to update our SecureBoot this way EVER - and yet several of your own inhouse articles along with other tech articles - a major explosion of them over the last few years online which I find very funny - everytime I have a problem with your software update and I try to look online - your own forums never provide a good answer but outside third party new tech articles and forums have more to say about it than you.

There is some mention that this new style fix is because there are so many previously vulnerable boot managers already in database and there is no more space - alright then - so how did Microsoft add those to the DBX previously? It didn't ask me to do it - that's for sure.

There is definitely something incredibly wrong here when a non-tech savvy end-user like me is refusing to install an update fix issued by Microsoft directly.

I don't trust Microsoft anymore than I trust its employees - cuz Microsoft is just a corporate entity. And my alertness is frankly in part trained simply from my recollection of how MS has acted with regards to its software updates over the years and this is completely at odds with how they have normally done things so - no I do not think this is a very deliberate and cautious approach to rolling out this update.

Isn't the normal approach - usually just Microsoft working with the OEM and firmware on this and if there is any problems booting up, we get told to update our firmware version and we go off to the website of whichever brand computer we are using to find it?

What possible good reason can there be for Microsoft basically asking us to manually override the very protection that was put in place - ie the firmware checks the software which is coordinated between Microsoft and the manufacturers.  The only way to override this security feature, ie excluding end-user participation is actually exactly what the guidance and advice this very update fix said upfront - only local and admin privileges get to override this and you're asking us to do that for you.

You are asking us to be the very security loophole you need to install the malware and rootkit.

What you said here - Revoking vulnerable Windows boot managers | Windows IT Pro blog (microsoft.com)

DO NOT apply the DBX to a device without DB update through manual update, using set-securebootuefi, as the system will not boot. Specifically, this will bypass the safety checks included in our servicing tool (Windows Updates) to guard against breaking issues. Update your device by relying on our published mitigations.

Specifically this will bypass the safety checks included in our Windows update service tool to guard against break issues?

What are you talking about - that's not where the safeguard is. The safeguard is exactly this - someone who has gotten physical access of your device and trying to mess aound with your trusted software provider credentials by manually altering the secure boot aspects gets locked out and the system shuts off - will not boot cuz it doesn't tally with the credentials given by the software provider - ie Microsoft. 

It's breaking precisely cuz these are unauthorized updates - that's why it breaks?

And you're asking the users themselves to do this for you, not to use the standard set-securebootuefi but instead to rely on the published guidance that is totally at odds with safe tech update fix rollout?? Are you out of your mind?

What exactly are you people trying to do here?

I cannot understand why would Microsoft be asking its end-users to do that when it can perfectly update this itself by coordinating with the OEM manufacturers or whoever it is - as how it has always done so - all to combat some malware Blacklotus threat I have never heard of and that your own Microsoft blog that talks about this guidance is a page that is no longer available?

Without telling users to check whether they have hypervisor enabled or giving us any details of which versions of Boot Manager is vulnerable - so that those who don't have those versions can just ignore this - you didn't tell us the most obvious fixes and things to check for end-users but pages and links to more links of word vomit that says you didn't enable the feature that was in previous updates cuz it depends on the users' system bla bla bla - and you want us to do it for you basically?

This makes ZERO sense.

Combined with the fact that Microsoft's approach to its update system over recent years has only been strange to say the least - I frankly find it very worrying that you would have someone internally within Microsoft suggest to you, as a OS software provider,  as a business decision that your updates should depart from the previously fixed schedules with clear-cut concise bullet points of what the update is - and instead go with more detail - pages and pages of explaining the flaws and exploits that it serves to fix - almost as if it is to highlight all its security flaws that frankly users aren't interested in - if you found a weakness and can fix it, just fix it, we click the update - done. 

Your feature of offering to save users passwords for them and offering to check them against hacked databases - where are you getting these databases from - shouldn't you be calling the cops to shut down them instead of asking us if we want to switch on the option of letting you check?

Is there anyone in Microsoft that isn't compromised or are people just stupid? You have enabled a feature that allows your staff to collect and collate passwords as part of a very legitimate work process - something that never existed before and would have to be retrieved specially, which again is something you won't usually do - not even if a regulator tries to force you to disclose it because you wanna maintain user confidentiality and again, you have someone in your ranks suggesting this as a feature as if it is a Edge browser convenience - and somehow creating the backoor for this info to be collated by your own hands in a nice handy package that will probably get lost, stolen, hacked or copied without your knowledge - something that would have been TOTALLY impossible to achieve before the introduction of that strange feature because that would have alerted your system immediately as unauthorized employee access and theft..

And your latest email recovery steps are inexplicable - your set of recovery questions include us to provide details of

1. Our previous passwords we might have used before

2. Email contacts we have emailed recently

3. Email subject topics of emails we sent recently 

4. Things we might have bought recently

5. And you actually suggest in those very same steps - that if we can't remember, we can ask our friends family and business associates about emails we might have exchanged with them previously so they can help?

That's basically a textbook manual for someone to use to scam and impersonate or hack a person's account and you have in-house Microsoft employees suggesting these as recovery steps??

Your employees are either acting against your interests on purpose or innocently out of sheer incompetence and both of that needs firing asap because we as end-users expect Tech talent to not be mediocre.  

SOMEBODY should have noticed how odd this update structure is and how unsafe those recovery questions are - whether through employee leaks or potential hacks - and if no one in your relevant ranks said anything about it - that entire structure needs to be fired and replaced asap. 

I am confused, what exactly is to be done here?

First of all this update is mentioned here: February 13, 2024—KB5034768 (OS Build 17763.5458) - Microsoft Support

What does opt for this change exactly mean in that article? Opt-in, opt-out? Is it only adding a certificate to the UEFI DB but doesn't use it? Can we safely deploy this update and nothing in the UEFI process changes and breaks things?

Then when clicking on the link in the article we get to this: KB5036210: Deploying Windows UEFI CA 2023 certificate to Secure Boot Allowed Signature Database (DB) - Microsoft Support

Why do we need to take action? Why is this not an automatic process and why do we need to test, didn't you guys test? If you have tested can you provide us with a list of all devices that will be giving us issues, and which are ok? You expect us to perform said action (changing registry) on all of our machines, including servers, and ask our users to reboot, twice? What if two reboots are needed and only one is performed, what might break, what are the symptoms? Will this setting be enforced in a future update? Which update and what timeframe are we talking about here exactly?

Then we come to this article and same questions applies as the previous point. Also here, you expect us to perform inventories on our total environments, on prem as well as Azure and/or Intune? Do you guys have pointers and or scripts to do inventories using SCCM, Intune, etc.?

Hello

Can I create a capture image with MCM where the Secure Boot DB is already populated with the current certificate?

I created the registry key using PowerShell in the Task Sequence. Unfortunately the DB has not been updated.

if(!([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match "Windows UEFI CA 2023")){
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
}

Thanks

Thank you for this article.

Why are manual steps necessary in the first place? When the old CA expires, I am forseeing a lot of troubles, especially on old devices, internet isolated devices (manufacturing, medical).

Hello, which OSes are affected by this change ? Windows client, Windows Server ? What about unsupported OSes, like Windows Server 2012 R2, or deprecated OSes like Windows Server 2016 or Windows 10 ?

How, if at all, is this related to or affected by the changes in KB5025885 which also concerns Secure Boot? I note that to pre-emptively apply those changes the AvailableUpdates registry key has to be set to 0x30 rather than 0x40 here. Is it possible to apply both updates (0x70?), and is there a recommended order to do so, etc. Please advise.

Will this have an impact on the restore of backups? Like the other UEFI-update where we had to redo the image after the update to be able to boot from it.

So, in simple words, we just need to install all monthly updates and Dell BIOS updates regularly to be prepared for 2026?