In the last blog post, we discussed the full authentication flow using Windows Hello for Business (WHfB) with face recognition to authenticate against an Active Directory with Kerberos and showcased existing and new vulnerabilities. In this blog post, we dive into the architectural challenges WHfB faces and explore how we can exploit them.
The majority of the work was conducted in the context of the “Windows Dissected” project. This project, funded by the BSI (German: “Bundesamt für Sicherheit in der Informationstechnik” – the German Federal Office for Information Security), has the goal to perform ” various in-depth security analyses of security-critical components and functions in Windows.” Over the next years we will discuss these results here once they are published.
WHfB is Microsoft’s flagship product for passwordless authentication in Domains. This is in contrast to traditional authentication methods, which use passwords. If a user authenticates with a password, this password (more precisely, its hash) is used directly as an entropy source during the authentication procedure. With WHfB, the biometrics feature (such as face or fingerprint, as well as PIN) is used to “unlock” a key stored in the client. This key is then used to produce a signature for the Kerberos PKINIT authentication. The same procedure is done if you are authenticating with CloudAp.dll against Entra ID. In this case, the signature is used to obtain the PRT, and the client signs a Nonce provided by Entra ID.
This architecture has some challenges. First, there is only a loose coupling between biometric identification and authentication. Additionally, there is no external entropy available to derive a cryptographic key at any point. Let’s set aside the first issue and focus on the second: missing entropy for cryptographic keys. Cryptographic keys play a major role when ensuring confidentiality of data when used in an encryption scheme. Microsoft documents that the biometric templates of the enrolled users are stored encrypted:
“Each database file has a unique, randomly generated key that is encrypted to the system.”
Therefore, from this, we know that each database will have its unique key. The part regarding “encrypted to the system” sounds a bit more cryptic (slight pun intended). From a database layout and reverse engineering perspective, it is pretty clear what is meant. The database consists of three parts: an encrypted header that holds a key for encrypting the templates and a SHA-256 hash of the remainder of the database. This hash is used to ensure the integrity of the database. Next, an unencrypted header with version and management information. And finally, on one or more records with encrypted templates.
The encrypted header is encrypted using CryptProtectData, which encrypts data without requiring an explicit key. In the case of user accounts, the key is derived from the user’s password. For the NT SYSTEM\AUTHORITY account on which the Windows biometric service runs, all information required to derive the key is stored in the system itself. This means that an administrative attacker can decrypt this header and access all information stored inside, as well as manipulate it.
For this first Proof of Concept2, we also decided to use system tools and APIs as much as possible. Like the storage adapter, we used CryptUnprotectData directly and have not decided to reimplement its logic. Using the CryptUnprotectData function typically leaves plenty of detection possibilities, but it makes our lives easier because we can use the tools we have at hand. With this we have access to the encrypted header and the hash that ensures the integrity of the database. So far, we have not discussed the body of the database. It consists of one or more (depending on how many users are enrolled) records. Each WINBIO_STORAGE_RECORD structure has a WINBIO_IDENTITY structure. This ties the user’s SID to the encrypted template stored in the record.
For our initial Proof of Concept, which we used in the disclosure with Microsoft, we wanted something that required little effort to showcase. The scenario is the following: Two users are enrolled with WHfB. At least one user is a domain user, and the other user is a local administrator. Both are enrolled with WHfB. The database will now hold two WINBIO_STORAGE_RECORD structures. Our Proof of Concept now exchanges the SIDs from each of the WINBIO_IDENTITY structures with one another. Now, the local administrative user’s face will unlock the domain user, and vice versa. After swapping the SIDs, we need to recompute the SHA-256 hash and store it in the encrypted header.
This showcases how administrative attackers break the security model of WHfB in a Domain context. Further attacks are, of course, also possible. For example, an attacker could replace stored biometrics with their own biometrics. So, there is no need to exchange SIDs. Additionally, the stored template can be decrypted.
We disclosed our discovery to Microsoft. We have already stated that there are several prerequisites. As similar issues have not been resolved in the past, and with Enhanced Sign-in Security, there is an option within WHfB to mitigate the problem, we have already suspected that Microsoft will not attempt to resolve this issue.
In discussions surrounding this topic, some people were asking if Microsoft could use the TPM to protect the templates. Theoretically, there are some possibilities, but they do not offer any significant security benefits. The templates could be stored in the non-volatile storage of the TPM. First, there is only limited memory available, and the size is highly dependent on the TPM manufacturer. Furthermore, the client needs to access this data without providing any secrets, so in this case, an attacker would also be able to access this data. Instead of storing the templates directly in the non-volatile memory of the TPM, a more feasible approach would be to encrypt the templates using a key protected by the TPM. While this solves the problem of memory space, it does not address the issue of missing entropy.
The only solution would be to use the user’s biometrics as entropy. Microsoft uses this approach if a PIN is used to authenticate with WHfB. The research field “biometric cryptosystems” works on methods for biometric-dependent key release.1 However, this would result in a massive overhaul of the system’s architecture.
Cheers!
Till & Baptiste
- If you are interested in this topic “A survey on biometric cryptosystems and cancelable biometrics” from 2011 takes a look into these systems.↩︎
- Proof of Concept (PoC) on GitHub↩︎