I am not a hacker, but what I gathered from the article is that this is due to shims with vulnerabilities being left as trusted instead of being revoked. If that’s the case, wouldn’t the hacker be using a modified version of a compromised shim? It shouldn’t have to be a shim that you actually use right? Or does the signed shim have to correspond to thr correct OS that signed it?
There exists shims that are signed by Microsoft and were not revoked. Normally this would be fine but these shims had weaknesses that allowes hackers to load any code using them. Normally the shims should only run other signed/trusted code. These vulnerable shims can be used to bypass secure boot by replacing your existing bootloader with the shim and then running rootkits/hackerOS/whatever and bypass bitlocker using TPM or just running a level 0 virus that can’t be detected by the OS on any PC which trusts Microsoft’s keys (99% of all PCs)
To prevent this you’d have to not trust the vulnerable shims by either adding them manually to the exclusions list or using your own secure boot keys which would only trust the few bootloader files your pc uses and no other files.
Worst case: it behaves as if secure boot wasn’t on. Without secure boot you wouldn’t need this exploit cause then you can replace the bootloader with whatever you want anyways. With or without secure boot you need administrative permission to replace the bootloader so this is only an issue after your PC is already compromised or if someone had physical access to your PC.
PieFed
Share on Mastodon
Share on Reddit
Share on WhatsApp
I am not a hacker, but what I gathered from the article is that this is due to shims with vulnerabilities being left as trusted instead of being revoked. If that’s the case, wouldn’t the hacker be using a modified version of a compromised shim? It shouldn’t have to be a shim that you actually use right? Or does the signed shim have to correspond to thr correct OS that signed it?
There exists shims that are signed by Microsoft and were not revoked. Normally this would be fine but these shims had weaknesses that allowes hackers to load any code using them. Normally the shims should only run other signed/trusted code. These vulnerable shims can be used to bypass secure boot by replacing your existing bootloader with the shim and then running rootkits/hackerOS/whatever and bypass bitlocker using TPM or just running a level 0 virus that can’t be detected by the OS on any PC which trusts Microsoft’s keys (99% of all PCs)
To prevent this you’d have to not trust the vulnerable shims by either adding them manually to the exclusions list or using your own secure boot keys which would only trust the few bootloader files your pc uses and no other files.
Worst case: it behaves as if secure boot wasn’t on. Without secure boot you wouldn’t need this exploit cause then you can replace the bootloader with whatever you want anyways. With or without secure boot you need administrative permission to replace the bootloader so this is only an issue after your PC is already compromised or if someone had physical access to your PC.
For anyone that hate microslop more than themself and enjoy pain i will provide this to aide in making your own pki, with blackjack and hookers:
https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys
https://blastrock.github.io/posts/fde-tpm-sb-ng/