As always in the IT world, it is difficult to find a good and refined standard. Linux has LUKS, Apple uses FileVault and Windows has BitLocker.
In fact, each of these solutions do the same thing: they provide full disk encryption (FDE). Thanks to this, even if our device or disk is physically taken over by unauthorized persons, we can be sure that the data stored on it will remain confidential.
Well, at least if we used a strong enough password.
Encryption we can trust?
BitLocker has been with us for a long time, so long that it even remembers the Windows Vista days. Some individuals and organizations for which disk encryption of Windows devices has become a necessity have resisted the use of Microsoft’s solution.
BitLocker is a closed solution. While the algorithm used, i.e. AES (Advanced Encryption Standard) and its block encryption modes – CBC and XTS, are in the public domain and have been subjected to many evaluations, the implementation itself (specific code, in a specific programming language) remains proprietary.
In the “crypto” world, that’s reason enough to be wary. Even a perfect algorithm with mathematically proven properties can be vulnerable to attacks after incorrect implementation. There is a whole class of vulnerabilities called side-channel attacks that covers this issue.
The eyes of many users have turned to open solutions such as TrueCrypt. But not for long.
It quickly turned out that the “big” updates (so-called feature updates) of Windows are incompatible with various disk encryption methods that come from vendors independent of Microsoft. The Internet was flooded with a wave of posts of frustrated users whose devices turned to bricks just after rebooting the device, forced by the installation of updates.
The reason is simple, some updates for Windows use the Windows Preinstallation Environment (Windows PE, WinPE) which is an operating system in itself and, like “classic” Windows, requires dedicated drivers to understand the full disk encryption used and to cooperate with them.
Despite this, some users tried to stick to open source solutions, decrypting the entire disk before installing the update and re-encrypting it after completing this process.
In a business environment, it was disruptive to say the least. Mechanical 2.5-inch drives often took 24 or more hours to complete the above mentioned process and there were dozens or hundreds of devices.
Thus, even the most conscious users, tired of the whole process, finally apologized to BitLocker.
Today the problem of WinPE and the so-called 3rd party encryption solutions is less of a nuisance, but it’s hard to come across a large Windows-based environment that uses anything other than BitLocker.
Because with BitLocker everything works…
Here we come to the heart of the matter.
It seems that many users who have “struggled” with TrueCrypt or who have always used BitLocker have accepted that the solution is hassle-free, without asking any additional questions.
So how does Microsoft’s FDE solution deal with the previously described problems? Well… It does not. If necessary, it simply leaves our device and data unprotected. Shocking? This is just the beginning.
How does BitLocker work?
Running a reasonably modern PC in a way that ensures that its components have not been tampered with is an insanely complicated process.
Additionally, BitLocker itself is quite flexible and allows you to configure the way you enter a password to access your data. Here we have the opportunity to take advantage of, among others, TPM (Trusted Platform Module), PIN, text password, and even an external USB key.
BitLocker is basically a low-level driver. As long as we access the disk using the functions provided by Windows, its work is transparent to us.
So Microsoft decided to encrypt the main key called FVEK (Full Volume Encryption Key), which ensures the security of our data using a series of other keys – VMK (Volume Master Key).
In short, each VMK is a key encrypted with a different access method. This allows us to simultaneously access our data using both a text password and a Recovery Key.
All data is stored on a protected volume, in metadata marked with the header -FVE-FS- (some information is also stored in TPM, if it is in use).
The process of preparing BitLocker to work looks like this:
Each of the methods allowing access to the VMK key is called KP (Key Protector), each VMK key (outside of TPM) is therefore encrypted with KP.
During the update of the components of our device, a number of processes will take place in which we will not be able to decrypt the contents of the disk, and thus perform the activities related to the modernization, for example:
How does BitLocker handle these situations?
Let’s follow the installation process of the feature update for the Windows 10 environment.
With the help of the screenshot above, we can describe the situation in which our system is currently located:
Let’s see what the metadata related to BitLocker looks like at the same time.
The bdeinfo tool returns the information that there are two KPs available:
The program also clearly states that it is not possible to unlock the volume. The data is safe.
As Windows “requests”, let’s restart the computer. But only the part until the machine is turned off. We’re not rebooting it.
Another look at the metadata reveals the new Key Protector number 2, Clear Key type!
What is the new KP? It is a string of characters that was used to encrypt another copy of the VMK key, saved in the form of… public text. During shutdown, Windows put BitLocker into an operating mode called Suspended.
Since we have access to the string encrypted by VMK, it means that, as a consequence, we have access to all data on the disk. Let’s check it.
Attempting to mount the volume is successful!
We have access to the data stored on the disk, including the contents of the previously mentioned secret.txt file.
What’s more, we can get the FVEK key using the dislocker tool.
An interesting fact is that the system does not inform the user in any way that his data will not be protected during the update.
What happens next? The installation of the system update continues.
And upon its complete completion, Key Protector number 2 is removed from the metadata.
However, this is not very comforting, because if during the update someone managed to obtain the contents of the FVEK key, they will still be able to decrypt our disk without the need for any password or other key.
At this point, it is very important to understand that the presented operation of the mechanism is not a bug or a vulnerability. This is a design decision made by Microsoft. The way BitLocker works.
Microsoft’s solution creates situations that can cause problems and temporarily stop BitLocker from protecting our data.
The encryption “suspend” mechanism is not closely related to system updates. This is one of the BitLocker modes of operation. On Microsoft’s website, we will find detailed information on how we can operate it ourselves.
We can “suspend” encryption for a certain number of reboots or indefinitely.
The main danger of this mechanism is that we have no guarantee that after putting BitLocker in Suspended mode, the Clear Key type Key Protector will later be deleted.
So it’s worth checking from time to time how BitLocker is configured, which we entrusted with the data encryption function. Especially in the Active Directory environment, where there are hundreds of devices, and thus the probability of the problem is greater.
As in the screenshot above, the volume for which encryption is “suspended” gets an exclamation point icon. Pertinent information is also provided in the manage-bde tool.
In this article, I have outlined a potential angle for an attack on devices using BitLocker full disk encryption.
That being said, I am far from giving this tool a negative opinion: it works efficiently and uses reasonable algorithms. However, it does not change the fact that some of Microsoft’s design decisions seem to be a bit questionable, to say the least. And what do you think about Suspended mode? Be sure to let me know in the comments.
Within last year I shared a a few writeups of my bypasses of HTML sanitizers, including: > Write-up of DOMPurify 2.0.0 bypass using mutation XSS > Mutation XSS via namespace confusion – DOMPurify < 2.0.17 bypass While breaking sanitizers is fun and I thoroughly enjoy doing it, I reached a point where I began to think whether I can contribute even more and propose a fix that will kill an entire class of bypasses.
A few days ago, the Anaconda project announced the PyScript framework, which allows Python code to be executed directly in the browser. Additionally, it also covers its integration with HTML and JS code. An execution of the Python code in the browser is not new; the pyodide project has allowed this for a long time...