Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, June 27, 2018 8:30 AM | 4 votes
Hi,
I have a machine with Bitlocker enabled, no TPM, Windows 10 1803.
For the last month or so, whenever a Windows system update is applied, Bitlocker is automatically suspended upon first login after the machine restarts. Case in point: the latest Windows 10 cumulative update was applied this morning, only for the machine to restart with Bitlocker suspended on the OS drive. Interestingly, there is also some dubious behaviour in terms of the initial Bitlocker password entry screen. Not having a TPM, the user must enter a password to boot. On at least 2 occasions, after applying an update, the system does not present the Bitlocker password entry screen and progresses all the way to the user login screen. However, this morning the Bitlocker password entry screen was presented correctly but after entering the correct password and then logging in to Windows, Bitlocker was suspended.
This is the state of the OS drive after logging in:
Volume C: [System]
[OS Volume]
Size: 59.07 GB
BitLocker Version: 2.0
Conversion Status: Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method: XTS-AES 128
Protection Status: Protection Off (1 reboots left) <
Lock Status: Unlocked
Identification Field: Unknown
Key Protectors:
Password
Numerical Password
Now, I realise that Bitlocker is temporarily suspended - restarting the machine again will enable it without any action from the user. However, this is a security risk for the time between restarting after an update and the next restart and severely undermines our trust in Bitlocker. I would expect that Bitlocker should NEVER be suspended unless initiated by a user/admin.
Has anyone else experienced this / have any advice?
All replies (44)
Wednesday, June 27, 2018 8:16 PM
Am 27.06.2018 um 10:30 schrieb kingcr:
> I would expect that Bitlocker should NEVER be suspended unless initiated
> by a user/admin.
It´s necessary for rebooting the machine.
New in 1803, the Upgrade can be done while bitlokc erstill running.
Mark
--
Mark Heitbrink
Homepage: http://www.gruppenrichtlinien.de - deutsch
Aktuelles: https://www.facebook.com/Gruppenrichtlinien/
GET Privacy and DISABLE Telemetry on Windows 10
gp-pack PaT - http://www.gp-pack.com/
Thursday, June 28, 2018 6:44 AM
Look at this blog for a hint.
NEW: Upgrade to Windows 10 1803 without suspending BitLocker
Regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, June 28, 2018 12:27 PM | 1 vote
I'm still not sure the behaviour I’m seeing is expected. The article you linked to specifically states that the new functionality applies when: 1) doing a feature update from 1709 to 1803 (or future feature updates). My issue has occurred during various quality updates within 1803. 2) a TPM is used. The machine in question has no TPM. 3) only a TPM protector is used. This machine has a password protector. And so I don’t believe this is applicable. Not having tested this new functionality in depth on a machine with a TPM etc, I’m not sure at which point Bitlocker resumes if it is suspended, but if it requires a further user-initiated reboot after an upgrade in order to resume, this is definely a security failure.
Tuesday, July 3, 2018 7:49 AM
Some things are being mixed up here.
1st: Feature upgrades ("FU") vs normal cumulative updates ("CU"). CUs will never suspend bitlocker. FUs will always suspend bitlocker.
2nd: what was introduced with win10 v1803 is merely, that now you can prevent the future FUs to suspend bitlocker. That is only possible, when TPM is the only protector (no password, no USB-key, no PIN).
3rd: what you see is obviously caused by a script that you are not aware of.
"Protection Status: Protection Off (1 reboots left) "
->That reboot count gets reduced by 1 each reboot. So if, after an update installation a reboot occurs, and biitlocker is still suspended, claimng "1 reboot left", that means, it were 2 reboots before. Why do I emphasize this? Because the reboot count can only be set to 2 (or higher) using scripts, and not the GUI! So it has to be a script that you are not aware off, that goes manage-bde -protectors -disable c: -rc 2
Tuesday, July 3, 2018 9:13 AM
Thanks for your reply Ronald, but if things made sense I wouldn't be posting here.
1. Feature upgrades should only suspend Bitlocker on systems with a TPM. But that aside, the issue I'm having is definitely with cumulative updates. I can't post images here, but this is the correlation between the Windows Update history and the Bitlocker log, chronologically:
08/06/2018: Cumulative update KB1410043 installed; log shows bitlocker suspended by system account.
13/06/2018: Cumulative update KB428435 installed; log shows bitlocker suspended by system account.
27/06/2018: Cumulative update KB4284848 installed; log shows bitlocker suspended by system account.
2. Agree.
3. Not so obvious. There are no scripts running at all. This is a machine that is not joined to our domain and all the updates are user-managed.
So, what am I left with?
1. Bitlocker suspending automatically during CU's which you say is impossible, but the logs say otherwise.
2. Bitlocker suspending automatically during a CU on a system without TPM and only a password protector, so Microsoft's own article for the changes introduced during 1803+ upgrades does not apply.
3. No scripts running to manage the updates.
Perhaps I'll blow away the current install back to 1803 release and see if applying the current CU immediately replicates the behaviour.
Tuesday, July 3, 2018 9:46 AM
Without going into detail on your response: since we use BL (with TPM mostly, but some without) here and never saw that happen, could it be that you set the following GPO:
Sign-in last interactive user automatically after a system-initiated restart
?
Tuesday, July 3, 2018 11:39 AM
No, that isn’t set up. The user always has to log in to Windows after the updates. Incidentally, this behaviour is something I noticed by chance. It’s pretty transparent unless you look at the Bitlocker logs or happen to notice the warning icon next to the OS drive in Explorer when the system first restarts.
Friday, July 6, 2018 12:09 PM | 1 vote
An update. I’ve managed to replicate this on a fresh install. Formatted and installed 1803, and basic drivers. Did not join a domain, and only changed the group policy to allow Bitlocker to be used without a TPM. That’s it. Connected to WiFi and allowed the system to update, which applied a single cumulative update. Rebooted thereafter and found Bitlocker suspended on the OS drive, logs reflecting the same situation as before. Granted, this isn’t a huge security hole as Bitlocker will resume on next reboot, but presumably the machine is vulnerable if, for example, it was forcibly shutdown at this point and the drive accessed using a different system?
Friday, July 6, 2018 4:39 PM
So on your clean machines this happens and here, on any clean install, it does not? Take a Hyper-V vm and do that again, please.
Friday, July 6, 2018 8:06 PM
Why would I want to do that? I never claimed this is a widespread issue. I simply encountered it on this machine, so testing on a VM proves nothing. You were pretty adamant this is caused by a script of some kind, and so I decided to test it on a completely clean installation to eliminate any additional software issues. Would you have done anything differently if you encountered this? Simply stating that it can’t happen or doesn’t happen in your environment doesn’t change the fact that it IS happening in mine. And the fact that it happens at all is concerning to me, since I believe it should not happen under ANY circumstances (which we seem to agree on).
Saturday, July 7, 2018 8:15 AM
Ok, I wasn't aware that this happens only on one machine. If it happened on more than one, I would do additional tests in hardware-neutral (vm) environments, but right, not needed here, then.
No idea.
Sunday, July 8, 2018 9:18 PM
Ok, an additional update. Had some time this weekend, so I created a new installation USB drive using the media creation tool, using the Windows 10 Pro US English variant (just to be different to the normal Windows 10 Pro English Intl ISO I use). Installed, encrypted, updated - same result: Bitlocker suspended.
Then I went ahead and created a VirtualBox VM to try to abstract the hardware. Installed, encrypted, updated - and.... same result: Bitlocker suspended.
I'm at a loss here.
Monday, July 9, 2018 6:37 AM
Super, we are coming closer - here, it does not happen on clean VMs.
So what ISO are you using for installation? Did you modify it somehow? Then retry with a clean one.
Monday, July 9, 2018 7:45 AM
I've used the Win 10 Pro English International ISO, not modified. And I've used the media creation tool to create a bootable USB drive containing Win 10 Pro US English, also not modified.
Do you use Pro or Enterprise for your clients?
Monday, July 9, 2018 7:53 AM
Both. Pro created by the media creation tool as well.
Enterprise downloaded (unmodified) from the VLSC.
Any special procedures when updating? Or just using built-in windows update?
Monday, July 9, 2018 8:41 AM
Absolutely nothing special. Literally connect to the internet and allow Windows Update to complete.
Monday, July 9, 2018 12:14 PM
Take a clean VM, download and install only the latest patch: https://www.catalog.update.microsoft.com/Search.aspx?q=KB4284848
install and see.
Monday, July 9, 2018 4:36 PM
Just did that. Installed Windows without network connectivity, encrypted, created a snapshot and left the network adaptor disconnected to avoid any Windows Update interference. Created an ISO with some of the updates on and installed them offline from there.
Installed KB4284848: Bitlocker suspended on reboot.
Rolled back to snapshot.
Installed KB4100403 (the first CU that was installed when I noticed the issue): Bitlocker suspended on reboot.
Rolled back to snapshot.
Installed kb4103721 (the first CU for 1803, listed as a security update): Bitlocker suspended on reboot.
Not sure I can do anything more here. Perhaps the difference we're seeing in the VM's is because you're using a type 1 hypervisor and I'm using a type 2 (although the fact that it occurs on a type 2 where the hardware appears more generic is odd).
Monday, July 9, 2018 6:12 PM
So, to add one more piece to the puzzle.
My wife's work-issued laptop is an older Lenovo B series without TPM, but her company uses Bitlocker. Managed to have a quick look at it when she arrived home a few minutes ago. It's running Windows 10 Pro 1803 like my problematic machine. To date, it has been upgraded to 1803 (beginning June) and has one CU installed (mid June).
Now the interesting part: the Bitlocker logs in event viewer shows 3 events. The first is the resume event after 1803 was installed (date ties up to the install date in Settings). The second is a system-initiated Bitlocker suspend event (correlates to the CU install). And the third is an automatic resume event a week later. Why a week later? Because my wife does not shutdown her work machine each night, so she only rebooted it a week later. For that week, Bitlocker protection was off (suspended).
So, it appears I'm not looking at an isolated case here.
Wednesday, July 11, 2018 2:52 AM
Definitely not isolated. I'm getting the same behavior on my home PC using a password in lieu of TPM. After every cumulative update that has released for 1803, BitLocker is suspended once I get back in the OS, even after a successful unlock & bootup. I have to simply resume protection and it's good until the next cumulative update.
I'm assuming it's a bug with 1803 when BitLocker uses a startup password, and Microsoft hasn't found a cause/fix or just hasn't recognized it's an issue yet.
Wednesday, July 11, 2018 4:36 AM
I'm experiencing exactly the same thing. This first started with the June 2018 CU and happened again with today's July 2018 CU. After installing the CUs BitLocker is suspended on my OS volume and I have to manually resume it. This is on a machine without a TPM - I'm using BitLocker with a password.
Friday, July 13, 2018 12:43 AM
I would like to add that I am having the exact same issue after 1803.
Friday, July 13, 2018 12:44 AM
Same here!
Friday, July 20, 2018 6:08 AM
Same here, 1803. I've seen it now on two systems after install monthly CU. One is a Microsoft Surface Book (first gen) and another is a custom desktop build. Nothing particularly remarkable about these systems really, but they are both configured very differently. One is my work system and the other is my home gaming rig. The work system has a TPM, the home system is password based.
Sunday, July 29, 2018 9:17 AM
I'm affected too!
Tuesday, July 31, 2018 12:36 PM
I am also having this issue on a few machines that do not have a TPM.
Tuesday, July 31, 2018 7:36 PM
The obvious question is how to get Microsoft’s attention for this. If any of you have a suitable contact, please report the issue. Otherwise, at the very least please add your comments to the report I have open in the Feedback Hub (under Windows, security and then Bitlocker or something like that - should be easy to find, there are only a handful of reports in that section ). Not that I believe anyone useful actually looks at that, but you never know.
Friday, August 17, 2018 1:40 AM | 1 vote
I am seeing more and more people reporting the following:
1. since upgrading to 1803
2. machine with Bitlocker but NO TPM chip
3. Bitlocker is enabled with password/phrase
4. during updates the Bitlocker gets paused
Let me see if I can get eyeballs on this.
Friday, August 31, 2018 12:22 PM
~200 machines, ~100 has Bitlocker suspended. Every machine has TPM, no passwords or PINs. Intune cannot show machines that have Bitlocker Suspended or resume bitlocker. I've tracked few computers where bitlocker suspend has happened during Windows Update.
Did scheduled powershell script which runs daily basis and resume if suspended.
Thursday, September 6, 2018 2:03 PM
I have read the article that Mike created but am a bit foggy on this item:
It needs to be running Windows 10 1709 or higher, and needs to upgrade to Windows 10 1803 or higher. (So this is a “going forward” change, not one that goes back into the Windows 10 stone ages.)
What is 'It'? The OS you are upgrading from or the setup.exe you are using to run the upgrade?
Will this work when upgrading from WIN7 to WIN10? Also does this mean I no longer need to have a step to suspend bitlocker before I get to the upgrade step. I use ConfigMgr tasks to do the upgrades.
Thanks in advance!
Thursday, September 6, 2018 8:46 PM
This also happens to me, same story, no TPM, password protected BitLocker system drive.
Please add a policy option to disable this behavior. I don't want BitLocker to ever be suspended without my explicit permission. I'd much rather have to wait on the next reboot until the updates finish installing than leave my data unprotected for a while.
Friday, September 7, 2018 9:20 AM | 1 vote
I have no TPM password protected system drive as well. I have had this bitlocker suspended problem for quite long time now.
The biggest problem is that "illegal suspending" happens "after" the reboot and "after" the update is already fully installed. Exactly this happened with the latest "August 30, 2018—KB4346783 (OS Build 17134.254) Applies to: Windows 10, version 1803".
When rebooting after prompt the bitlocker was not suspended and the password was asked correctly. When the update had finished without any further reboot request the bitlocker was left suspended without any prompt.
The only wrong, but somehow understandable place for suspending to happen should be immediately before forcibly rebooting at update time to get system to running state again. But even then when restart fails for some reason the system should be in unprotected state so this is illegal as well.
As workaround I have added shutdown script in group policy with "manage-bde.exe -protectors -enable C:" that seems to fix it.
Friday, September 14, 2018 12:43 PM
Same here. My PC rebooted overnight following a Cumulative Update and the Bitlocker with password (no TPM) C: drive was suspended after the reboot. This has been happening for some months now.
Saturday, September 15, 2018 11:28 AM
Yes! Very sad to say it happened again with "September 11, 2018—KB4457128 (OS Build 17134.285)" update. When rebooting the password was asked correctly. But "after" the reboot when the update was fully installed and no reboot was needed the bitlocker was suspended with no reason at all. It's "so" wrong and nobody fixes it after so long time!
This extremely serious security error is not even listed under "Known issues in this update" at https://support.microsoft.com/en-us/help/4457128/windows-10-update-kb4457128.
Saturday, September 15, 2018 11:59 AM
Conclusion: disable bitlocker driveprotection temporarely before major system-updates. Since we all now about when they are appearing.
Mabye the postpone updates feature could help a bit(locker).
Saturday, September 15, 2018 2:03 PM | 3 votes
Bitlocker should "never" suspend itself without explicit interactive permission from the administrator. That is the whole point of protection.
Now it's suspended silently "after" finished "normal/monthly" cumulative update. This silent suspension "feature" is "undocumented" so nobody knows when it may happen. The bitlocker event log has no mention of suspending application and reason.
So the most important security feature for physical protection of computer is just leaving the computer wide-open "sometimes".
To be "almost" sure we now on have to always "restart" the computer instead of "shutting it down" so we "can see" that the password is really asked and then switch it off.
Tuesday, September 18, 2018 11:18 AM
Conclusion: disable bitlocker driveprotection temporarely before major system-updates. Since we all now about when they are appearing.
I leave my PC on standby. Cumulative Updates install themselves and reboot the PC with no prior warning overnight, so there's no opportunity for me to manually reboot the PC instead to avoid Bitlocker being suspended.
But in any case, it should not be necessary for me to manually reboot the PC because of a bug in Bitlocker which leaves PCs unprotected.
Looking at my Bitlocker logs it appears the issue started in early May, with every monthly Cumulative Update after that suspending Bitlocker.
Tuesday, September 18, 2018 4:00 PM
I'm in the same situation, same parameters as everyone here is reporting but on an Asus laptop. I first saw the problem after the Creative update, I believe. It's been over a month anyway. At first, I thought I was under attack!
I blew away the system and later learned that it was occurring after Windows updates. However, the big question is, "if Microsoft needs Bitlocker suspended, and they have the ability to turn off my PASSWORD PROTECTED bitlocker drive, why wouldn't they make sure protection was resumed after the final boot?"
Apparently, this problem is persistent as my machine updated last night, I was looking for it this morning. Sure enough, my C drive bitlocker password protection was suspended and I had to resume protection manually.
This brings up a concern. How long is it going to be before the hackers learn how to look for this condition and exploit it?
Thursday, September 20, 2018 12:01 PM
@redeyedog, as I stated in my initial posts, this isn’t a major security risk (but still a worrisome problem that we shouldn’t be faced with). The reason it isn’t a major risk is because it would require time-limited physical access to an affected machine. It’s not a remote exploit, so “hackers” aren’t a real concern. The affected data also isn’t decrypted when Bitlocker is suspended. What happens is that when Bitlocker is suspended, the encryption key is available in the clear, so presumably if an attacker had physical access to a machine in this condition, they could use (or store for later) the encryption key to access your data. So it’s a risk. But not a huge risk for “most people”. What I don’t understand is how this hasn’t been noticed by Microsoft (but then again, bugs in MS software seem be to be increasing in my experience).
Thursday, September 20, 2018 2:00 PM
Interesting thread. I'm looking to put together a story on this issue and, having failed so far, I'm hoping participants in the thread such as @kingcr might be able to help me understand where things are at.
You write: "This isn't a remote exploit but... when Bitlocker is suspended, the encryption key is available in the clear."
Would it be apt to compare what's happening here to a cold boot attack, @kingcr?
Reply to thiis thread or (preferably) @jleyden on Twitter.
Thursday, September 20, 2018 7:37 PM
@kingcr you say "The affected data also isn’t decrypted when Bitlocker is suspended".
Let's say a Cumulative Update reboots my PC, and after reboot Bitlocker is left in a suspended state. Then someone steals my PC by powering it off at mains without shutting it down first. Can the hard drive not be removed from the PC and connected to another PC for data extraction?
If the data can't be extracted in this way then that's good.
I suppose the next question would be whether the encryption key can be extracted in this scenario somehow and used to decrypt the data.
Thursday, September 20, 2018 8:06 PM
What I am seeing is exactly what would happen if this command was performed after the Cumulative Update and before the restart:
Suspend-BitLocker -MountPoint "C:" -RebootCount 2
Could it be as simple as Windows Update incorrectly issuing "-RebootCount 2" instead of "-RebootCount 1"?
Thursday, September 20, 2018 8:44 PM
@hac_overflow: while this would be exploited in a somewhat similar way to a cold boot attack, I don’t think it’s technically correct to characterise it in this way.
Thursday, September 20, 2018 8:57 PM
@Donny Murgatroyd: that is the sort of physical access where this condition can probably be exploited. But whether or not it’s as simple as plugging the drive into another machine running Windows, I’m not sure. I suppose whether it’s that trivial to exploit depends on whether automatically resuming actually happens on reboot (as the naming implies) or on mount. I haven’t tested this. In either case, I expect once you use forensic tools, the drive is vulnerable if removed while protection is suspended - full stop. Also, for those directing questions to me: I’m not a security expert, just a security enthusiast which is why I noticed in the first place and started this thread.