Borrowing a Microsoft-signed shim to abuse Secure Boot on corporate hardware | Hacker News Reader

Borrowing a Microsoft-signed shim to abuse Secure Boot on corporate hardware

leosmith.wtf

48 pointsp4p113 comments

This was always intended. If you don't want Microsoft keys sitting at the root of the trust chain, you can also enroll your own keys (with UEFI access). And Microsoft literally forced vendors to allow this by making it a requirement to be able to call a device Windows-ready or whatever it's called. Yes: MSFT explicitly wanted it to be possible to remove MSFT keys from your device.

There's many things that Microsoft deserves a lot of criticism for, but Secure Boot is not one of those things in my eyes.

It isn't. And UEFI is not a Microsoft invention. They are literally just one of many members of the UEFI consortium, that just happen to have offered managing the signing certificates.

The hate towards Microsoft or UEFI prevalently comes from people that are I'll informed, ignorant or worse, are just having foaming mouths about everything Microsoft.

Right. They just happened to offer a solution to Linux proliferation after netbooks with Linux were on shelves at electronics stores. How nice of them.

This is a good point and I agree with you, the fact that the specific 3rd party key can be opt out is good and the fact that you can enroll your own keys if you just want something controlled by yourself is also good. I've seen in the wild either sysadmins forcing these keys enabled for "specific software needs them" applied to a whole computer fleet disregarding wich one needs them or not and that might defeats it's purpose. I also beleive like mentioned in the post regarding secure boot there might be some misconceptions on the security side as well where some professionals do think secure boot locks the boot to one OS where if misconfigured it clearly does not because thats not really what it was designed for, I also discovered that by default those keys are just enabled on some vendors which is mainly why i made this post a bit "clickbait" because on this topic I personally beleive that dissabled by default similar to what I saw with HP secure wolf is clearly the right thing to do for this specific setting.

What I do is seal the disk encryption key against PCR 7 (among others) so even if it secure boots up, unless it boots with grub verified with a specific key, it won’t be able to decrypt the disk.

PCR 7 tends to get changed with firmware updates, for example when Microsoft rotated its secure boot certificate (which is still a work in progress, depending on if you've installed a certain Windows Update or not).

Not a huge problem if you keep your recovery key ready when doing firmware updates (which you probably should be doing anyway) so you can re-enroll the key afterwards, but I believe this is the reason default configurations tend not to include PCR 7.

But indeed: the article describes secure boot working as intended and PCR 7 is one of the ways you prevent providing access to a drive in these circumstances.

Yeah we have break glass recovery keys and a process for resealing on firmware updates

You at least have a PIN on top of thatm right? Right?

This is not a hack. It's working as designed.

Secure Boot’s MOK enrollment lets you enroll arbitrary keys without a BIOS password. By borrowing a Microsoft-signed shim from a package like ubuntu’s shim-signed, you can boot any OS on a corporate machine that has 3rd party certificates installed — which most do.

This allows you to boot a different OS, but will still not allow you to hack the existing one, the PCR registers will be different if you try chain-loading it.

Also, if you store part of the full disk encryption key in the TPM, you are also safe, the TPM will not release it. But there is a risk of the user entering their password (if they have one) in a fake login screen. But the OS will fail booting after that screen, so you need some plausible story to trick the user into not reporting the incident to IT.

If you have a laptop where you can install Ubuntu on it, this attack allows you to install a modified (unsigned) Ubuntu on it. So not much has changed.

> so you need some plausible story to trick the user into not reporting the incident to IT.

Give them an authentic-looking "updating windows" screen after login, and reboot. 95% of users will bitch about Microsoft, instead of calling IT.

"If you can mess around in the BIOS you can just enroll your own keys"

... and if your corporation has locked down the UEFI controls to prevent this, you can't. Forex: corporate Microsoft Surface, locked down with Intune (and Autopilot), you won't be getting far enough to do that.

Reply on news.ycombinator.com