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.
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.
"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.
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.
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.