Alright, since Anthony posted his “Obsolete Security – Stop Setting These Policies!” I couldn’t stop thinking about one other topic that usually bothers me a lot: BitLocker pre-boot authentication aka startup PIN. So I asked on Twitter X: Martin Himken | MVP on X: “Give me your reasons to enable or disable BitLocker preboot PIN. I’ll wait.” / X and started writing the following blog.
“It’s more secure”
Yes. I don’t think anyone would argue that it it’s not1. And yes, it would have prevented many of the exploits that have been found over the past few years. The most famous one is probably CVE-2023-21563 – Security Update Guide – Microsoft – BitLocker Security Feature Bypass Vulnerability which can be exploited as shown on the 38C3. I’ve worked on this issue myself when Microsoft tried to patch WinRE for everyone. Or this video here, showing how to read the important bits from the board.
However, a BitLocker pre-boot PIN makes your OS more secure in the same way that AppLocker or App Control for Business makes your assets more secure. It comes at the expense of the user experience. For the next part, I’m going to pick up the latest “cybersecurity needs” infographic that Lewis pointed out earlier today and … add my own thoughts.
If you think about implementing this, you should also do your homework. Just look at this journey (and this is just an example) below. Remember from the picture above, this is a pyramid. It won’t hold if you don’t start at the base. So next, we’ll need to talk about a pretty beaten horse that is still very relevant.
The Zero Trust way
- Identities: Did you do a risk assessment for your company and identified high risk users? Have you automated this process? These should most likely include C-Suite.
- Identities: Have you enabled MFA for your users? All users? Especially those identified as high value assets?
- Identities: Are you already looking at cloud-native to make devices distrusted by default?
- Identities/Devices: Have you run the zero trust workshop yet and implemented measurements as recommended?
- Identities/Devices: What about Conditional Access, are you already incorporating device compliance into your policies? What about registering new MFA methods? Are you looking at passwordless authentication?
What additional considerations are relevant?
And those are just from that cloud journey. To counter some of the attacks that I mentioned above you can implement more things that aren’t as bad for the user experience.
- Why is data from high-risk targets (you did the risk assessment mentioned earlier, right?) like C-suite or developers on the device at all? For their convenience, what is the business value that provides? If they have an exclusion, question that decision. If the external risk is estimated to be that high, is it worth securing the device at the cost of UX instead of using a cloud/network share? If you’re building submarines contact me, I’d be curious how you secure endpoints. Which brings me to the next point
- Are you worth the effort? I don’t want to downplay the importance of any business, but in your risk assessment, consider the following: How much will an attack cost an attacker, and what would be the potential gain? If you can put numbers to that, it becomes a lot more tangible. If I can take over your developers account with an evilginx and a couple spear phising mails your secure fell flat way before the endpoint we’re talking about.
- You did remember to plan to enable enhanced PINs for at least the high-value assets? While we’re at that topic, also remember that special characters during the pre-boot phase are using en-us keyboard layout.
Things you can and should actively do
- Did you apply the manual fix that has been available for more than a year (don’t use that blog, it’s outdated) that literally fixes the bitpixie vulnerability among others? Pro tip: Use the updated method that isn’t as much pain to manage (working on that currently myself). Oh, and by the way, a much easier method would be to secure UEFI with a password, disable PXE in UEFI, and use Autopilot. Which, frankly, you should already be doing, or at least checking, all of this anyway. Remember, a lot of this is built on a foundation and assumptions about the configuration – just like the attacks.
- The YouTube video from earlier also make it seem easy to get the important bits from the TPM. The attack from my understanding of the related links on TPM 2.0 only works for TPMs that are on the LPC bus instead of SPI or I2C. Ask your hardware provider or OEM for this information.
- Even if the device as successfully unlocked remotely, there is currently no know exploit that would just allow someone access to the files on the disk through the network. Additional hardening around this should thus also already be applied. I don’t even mean network protection agents on the device – even settings might help with this (think SMBv1, NTLMv1/LM or the very powerful Access this computer from the network)
- If you need to have the data on the device: Have you also done Personal Data Encryption? The feature available since Windows 11 22H2, which literally does additional encryption, that can only be unlocked by the user signing in with Windows Hello for Business.
Drawbacks
Now, I’ve talked about the bad user experience, but what other drawbacks exist? Keep in mind that these may not be a problem for you, but they may be in other use cases.
- Cumulative, monthly updates might require more than one reboot. So the experience for the users is to enter the PIN more than once for that to complete.
- Higher ticket volume, because your users are also just human.
- The PIN will be on a sticky note below the device for some users and they’re usually not the ones that use the device daily.
- Implementation on Intune to set up the startup PIN is not possible natively. You still need scripts to get the user to set up a custom PIN. Granted, these have come a long way over the years, but they usually have no support at all.
- If you think of a stolen device, this means “prolonged physical access”. You need to disable standby (S1-S3), otherwise the keys could be stolen from RAM. See here for more information.
- The same article also points to protecting the DMA ports which makes it so new Thunderbolt devices can’t be used unless a user signs in. This is very use-case specific though.
Conclusion
Regardless, if you look at this from a management perspective or a technical one or both. There’s a lot more going into the decision to enable the BitLocker startup PIN than just “Compliance says this is a vulnerability”. By the way, Microsoft already removed this from their Microsoft Defender TVM recommendations. I personally think there are more important battles to fight and most of them are related to the identity of the user.
UPDATE: Someone pointed out that Defender TVM still recommends this (link to recommendation). Well, if you open the recommendation, you’ll notice that it doesn’t explicitly recommend using PIN. It just says to require an additional startup method – not which one. And the “potential risk” section points out that PIN is more secure, which we established earlier is true – but not required to comply with this advisory. See picture below in a tenant with TPM only, you can find this on this threat analytics page.
- Except for the fact users
mightwill re-use the PIN for their WHfB, but who is counting right? ↩︎