Gesichtserkennung in Windows Hello for Business: Forscher decken neue Schwachstellen auf

Der Sicherheitsforscher Tillmann Oßwald vom IT-Sicherheitsunternehmen ERNW beleuchtet in einem aktuellen Blogbeitrag die sicherheitsrelevanten Schwächen von Windows Hello for Business (WHfB). Unter dem Titel „Der Gesichtsaustausch“ analysiert Oßwald die architektonischen Herausforderungen der biometrischen Authentifizierung über Gesichtserkennung – und zeigt auf, wie sich diese unter bestimmten Bedingungen ausnutzen lassen.

Bereits im vorherigen Beitrag hatte das Team den vollständigen Authentifizierungsprozess von WHfB in Verbindung mit einem Active Directory und dem Kerberos-Protokoll technisch nachvollzogen. Dabei wurden sowohl bekannte als auch neue Schwachstellen identifiziert.

Die Untersuchungen sind Teil des Forschungsprojekts „Windows Dissected“, das vom Bundesamt für Sicherheit in der Informationstechnik (BSI) gefördert wird. Ziel des Projekts ist es, sicherheitskritische Komponenten und Funktionen des Windows-Betriebssystems systematisch zu analysieren. Die Ergebnisse dieser mehrjährigen Studie sollen sukzessive veröffentlicht werden.

WHfB ist das Flaggschiffprodukt von Microsoft für die passwortlose Authentifizierung in Domänen. Dies steht im Gegensatz zu herkömmlichen Authentifizierungsmethoden, die Passwörter verwenden. Wenn sich ein Benutzer mit einem Passwort authentifiziert, wird dieses Passwort (genauer gesagt sein Hashwert) während des Authentifizierungsvorgangs direkt als Entropiequelle verwendet. Bei WHfB wird die biometrische Funktion (z. B. Gesicht oder Fingerabdruck sowie PIN) verwendet, um einen im Client gespeicherten Schlüssel zu „entsperren”. Dieser Schlüssel wird dann verwendet, um eine Signatur für die Kerberos-PKINIT-Authentifizierung zu erstellen. Das gleiche Verfahren wird angewendet, wenn Sie sich mit CloudAp.dll gegenüber Entra ID authentifizieren. In diesem Fall wird die Signatur verwendet, um den PRT zu erhalten, und der Client signiert einen von Entra ID bereitgestellten Nonce.

Diese Architektur birgt einige Herausforderungen. Erstens besteht nur eine lose Kopplung zwischen biometrischer Identifizierung und Authentifizierung. Außerdem steht zu keinem Zeitpunkt externe Entropie zur Verfügung, um einen kryptografischen Schlüssel abzuleiten. Lassen wir das erste Problem beiseite und konzentrieren wir uns auf das zweite: fehlende Entropie für kryptografische Schlüssel. Kryptografische Schlüssel spielen eine wichtige Rolle bei der Gewährleistung der Vertraulichkeit von Daten, wenn sie in einem Verschlüsselungsschema verwendet werden. Microsoft dokumentiert, dass die biometrischen Vorlagen der registrierten Benutzer verschlüsselt gespeichert werden:

„Jede Datenbankdatei verfügt über einen eindeutigen, zufällig generierten Schlüssel, der für das System verschlüsselt ist.“

Daraus lässt sich ableiten, dass jede Datenbank einen eindeutigen Schlüssel hat. Der Teil „verschlüsselt im System“ klingt etwas kryptischer (ein kleines Wortspiel beabsichtigt). Aus Sicht des Datenbanklayouts und der Reverse Engineering ist jedoch klar, was damit gemeint ist. Die Datenbank besteht aus drei Teilen: einem verschlüsselten Header, der einen Schlüssel zum Verschlüsseln der Vorlagen enthält, und einem SHA-256-Hash des restlichen Datenbankinhalts. Dieser Hash dient dazu, die Integrität der Datenbank sicherzustellen. Als Nächstes folgt ein unverschlüsselter Header mit Versions- und Verwaltungsinformationen. Und schließlich enthält die Datenbank einen oder mehrere Datensätze mit verschlüsselten Vorlagen.

Der verschlüsselte Header wird mit CryptProtectData verschlüsselt, das Daten ohne expliziten Schlüssel verschlüsselt. Bei Benutzerkonten wird der Schlüssel aus dem Passwort des Benutzers abgeleitet. Für das NT-Konto SYSTEM\AUTHORITY, unter dem der Windows-Biometriedienst ausgeführt wird, sind alle Informationen, die zur Ableitung des Schlüssels erforderlich sind, im System selbst gespeichert. Das bedeutet, dass ein Angreifer mit Administratorrechten diesen Header entschlüsseln und auf alle darin gespeicherten Informationen zugreifen sowie diese manipulieren kann.

„Für diesen ersten Proof of Concept haben wir uns außerdem dafür entschieden, so weit wie möglich Systemtools und APIs zu verwenden. Wie beim Speicheradapter haben wir CryptUnprotectData direkt verwendet und uns gegen eine Neuimplementierung der Logik entschieden. Die Verwendung der CryptUnprotectData-Funktion lässt in der Regel zahlreiche Erkennungsmöglichkeiten offen, erleichtert uns aber die Arbeit, da wir die uns zur Verfügung stehenden Tools verwenden können. Damit haben wir Zugriff auf den verschlüsselten Header und den Hash, der die Integrität der Datenbank gewährleistet. Bisher haben wir noch nicht über den Hauptteil der Datenbank gesprochen. Er besteht aus einem oder mehreren Datensätzen (je nachdem, wie viele Benutzer registriert sind). Jede WINBIO_STORAGE_RECORD-Struktur verfügt über eine WINBIO_IDENTITY-Struktur. Diese verknüpft die SID des Benutzers mit der verschlüsselten Vorlage, die im Datensatz gespeichert ist“, so.Tillmann Oßwald.

Für den ersten Proof of Concept, der im Zuge der verantwortungsvollen Offenlegung an Microsoft übermittelt wurde, wählten die Sicherheitsexperten von ERNW ein Szenario, das mit minimalem Aufwand reproduzierbar ist. Wie Tillmann Oßwald erklärt, wurden zwei Benutzer bei Windows Hello for Business (WHfB) registriert – mindestens ein Domänenbenutzer und ein lokaler Administrator. Beide verfügen über eigene biometrische Einträge in Form von WINBIO_STORAGE_RECORD-Strukturen in der WHfB-Datenbank.

Im Rahmen des Proof of Concept tauschten die Forscher die Sicherheitskennungen (SIDs) innerhalb der WINBIO_IDENTITY-Strukturen aus. In der Folge konnte der Domänenbenutzer mithilfe der Gesichtserkennung des lokalen Administrators authentifiziert werden – und umgekehrt. Nach dem Austausch der SIDs wurde der SHA-256-Hash neu berechnet und im verschlüsselten Header abgelegt.

Das demonstriere, so Oßwald, wie sich das Sicherheitsmodell von WHfB in einem Domänenkontext durch administrative Angreifer unterlaufen lässt. Darüber hinaus seien weitere Angriffe denkbar: Ein Angreifer könne etwa die gespeicherten biometrischen Daten durch eigene ersetzen, ohne SIDs manipulieren zu müssen. Zudem lasse sich die gespeicherte Vorlage entschlüsseln.

Die Erkenntnisse wurden an Microsoft übermittelt. Dabei wiesen die Forscher darauf hin, dass mehrere technische Voraussetzungen für den Angriff erfüllt sein müssen. Da Microsoft in der Vergangenheit ähnliche Schwachstellen nicht behoben habe und mit der erweiterten Anmeldesicherheit bereits eine Schutzoption innerhalb von WHfB existiere, sei nicht davon auszugehen, dass eine Behebung erfolgt.

In der Diskussion um mögliche Schutzmaßnahmen kam auch die Frage auf, ob das Trusted Platform Module (TPM) zur Sicherung der biometrischen Vorlagen genutzt werden könnte. Theoretisch seien verschiedene Ansätze denkbar, etwa die Speicherung der Daten im nichtflüchtigen TPM-Speicher. Dieser sei jedoch begrenzt und herstellerabhängig. Zudem müsse der Client Zugriff auf die Daten erhalten, ohne dabei Geheimnisse preiszugeben – was auch potenziellen Angreifern den Zugriff ermögliche.

Eine alternative Möglichkeit wäre die Verschlüsselung der Vorlagen mit einem vom TPM geschützten Schlüssel. Dies behebe zwar das Speicherproblem, nicht jedoch das der fehlenden Entropie. Die einzig tragfähige Lösung wäre laut Oßwald die Verwendung der biometrischen Merkmale selbst zur Erzeugung von Entropie – ein Prinzip, das WHfB bereits bei PIN-basierter Authentifizierung nutzt. Der Forschungsbereich „biometrische Kryptosysteme“ arbeitet an entsprechenden Methoden zur biometrieabhängigen Schlüsselfreigabe. Eine Umsetzung würde jedoch eine umfassende Neugestaltung der Systemarchitektur erfordern.

Quelle: ERNW Enno Rey Netzwerke GmbH 

---