Forschende von Palo Alto Networks Unit 42 haben eine Analyse zu drei Post-Exploitation-Techniken veröffentlicht, mit denen Malware, die mit Rechten eines normalen Benutzers auf einem Windows-System mit TPM läuft, sich bei passkey-geschützten Konten des Opfers authentifizieren kann – ohne Biometrie, PIN-Code oder sichtbare Hinweise auf dem Bildschirm. Die Angriffe richten sich gegen den Google Password Manager im Browser Chrome und brechen nicht die Kryptografie von WebAuthn, sondern nutzen Besonderheiten bei der Schlüsselspeicherung, der Logik zur Wiederregistrierung von Geräten und der Prüfung des User-Verification-Flags auf Seiten der Webservices aus. Bisher wurden keine Fälle einer Ausnutzung in realen Angriffen festgestellt, es wurden keine CVE-Identifikatoren vergeben, und der vollständige Status der Fixes ist weiterhin unbekannt.
Architektonische Voraussetzungen der Angriffe
Alle drei Methoden – Pass-ta-key, Silver Pass-ta-key und Golden Pass-ta-key – setzen voraus, dass der Schadcode bereits auf dem Gerät des Opfers ausgeführt wird. Es handelt sich um Post-Exploitation-Techniken: Sie beschreiben, was ein Angreifer auf einer bereits kompromittierten Maschine tun kann, nicht die Art des anfänglichen Eindringens.
Nach Angaben der Forschenden speichert Chrome synchronisierte Zugangsdaten im Verzeichnis %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, und ein nicht privilegierter Prozess kann die Metadaten lesen, einschließlich der Service-Identifikatoren (relying party), Benutzernamen, Credential-IDs und des verschlüsselten Materials der privaten Schlüssel.
Ein zentrales Architekturmerkmal wird durch den Quellcode von Chromium bestätigt: Chrome erzeugt einen namenlosen TPM-Schlüssel (was laut Kommentar im Code seine Speicherung auf der Festplatte verhindern soll), exportiert ihn als undurchsichtigen Blob und lädt ihn anschließend erneut. Beim Signieren wird der Flag NCryptSignHash verwendet, der sämtliche Benutzerabfragen unterdrückt. In derselben Datei findet sich ein TODO-Kommentar mit Verweis auf das Chromium-Issue 398125799, in dem vorgeschlagen wird, solche Schlüssel zu markieren.
Drei Angriffsvektoren
Pass-ta-key: Umgehung ohne User Verification
Die erste Methode extrahiert den verpackten Geräteschlüssel von Chrome und fordert über die Windows CNG API von demselben TPM eine Signatur für eine vom Angreifer kontrollierte Anfrage an. Der Cloud-Authenticator von Google liefert eine gültige Assertion (assertion), die sich von der legitimen lediglich in einem Bit unterscheidet – dem Flag User Verified (UV), das nicht gesetzt ist.
Gemäß der Spezifikation Web Authentication Level 3 muss ein Service, der den Parameter userVerification auf „required“ setzt, eine Authentifizierung ohne gesetztes UV-Bit ablehnen. Nach Angaben von Unit 42 führt GitHub diese Prüfung korrekt durch, während eBay derartige Assertions akzeptierte, bis das Problem nach der Offenlegung behoben wurde.
Silver Pass-ta-key: Austausch des User-Verification-Schlüssels
Die zweite Methode zielt auf den Prozess der erneuten Geräte-Registrierung. Die Malware initiiert erzwungen eine Neuregistrierung von Chrome, und in dem dabei entstehenden Zeitfenster – wenn der Browser den User-Verification-Schlüssel noch nicht erzeugt hat – registriert der Angreifer seinen eigenen Schlüssel. Der Quellcode von Chromium bestätigt den Zustand deferred_uv_key_creation für neu registrierte Geräte.
Nach Darstellung der Forschenden prüft die Serverseite nicht, ob der neu registrierte Schlüssel aus einem Hardware-Sicherheitsmodul stammt. Mit dem untergeschobenen Schlüssel signierte Assertions tragen ein gesetztes UV-Flag, was – so wird berichtet – eine Authentifizierung vom Gerät des Angreifers aus ohne Zugriff auf die Maschine des Opfers ermöglicht. Allerdings erlaubt der öffentliche Chromium-Code keine unabhängige Verifizierung des serverseitigen Teils dieses Angriffs für die aktuelle stabile Chrome-Version.
Golden Pass-ta-key: Extraktion des Master-Secrets
Die schwerwiegendste dritte Methode richtet sich gegen das 32-Byte große Security Domain Secret (SDS) – einen Master-Schlüssel, der zur Entschlüsselung der synchronisierten privaten passkey-Schlüssel verwendet wird. Nach Angaben von Unit 42 stößt die Malware eine Neuregistrierung an und liest das Secret aus dem Speicher des Chrome-Prozesses in dem Moment aus, in dem es dort kurzzeitig im Klartext vorliegt.
Der Quellcode von Chromium bestätigt, dass Chrome 32-Byte-Secrets für Security Domains in Datenstrukturen des Client-Prozesses erzeugt oder empfängt. Die Zuverlässigkeit der Extraktion, die Möglichkeit der vollständigen Kontoübernahme und die Aufrechterhaltung des Zugriffs bei einem Wechsel der Secret-Epochen sind jedoch durch unabhängige Quellen bislang nicht bestätigt.
Die Forschenden berichten, dass Google eine zuvor bestehende SDS-Leckage über die FIDO-Logs von Chrome beseitigt hat, das Secret aber weiterhin im Speicher des Clients landet, womit der beschriebene Vektor nicht geschlossen ist.
Unklarheit über den Status der Fixes
Die Offenlegung legt nicht fest, ob alle drei Angriffsvektoren geschlossen wurden. Die Analyse enthält weder CVE-Identifikatoren noch eine Liste der betroffenen Chrome-Versionen oder einen vollständigen Status der Korrekturen. Die öffentliche Dokumentation von Google ermöglicht es Nutzerinnen und Nutzern, den PIN-Code des Google Password Manager zu ändern oder alle Daten des Passwortmanagers zu löschen, beschreibt aber keinen Mechanismus zur Rotation oder zum Widerruf des SDS. Offen bleibt die kritische Frage: Hebt das Ändern des PIN-Codes oder das Löschen der Daten ein Secret auf, das ein Angreifer bereits extrahiert hat.
Bewertung der Auswirkungen
Die Auswirkungen sind auf Nutzer von Chrome unter Windows mit TPM beschränkt, die den Google Password Manager zur Synchronisation von passkey verwenden. Zwei der drei Methoden (Silver und Golden Pass-ta-key) ermöglichen laut den Forschenden einen erneuten Zugriff aus der Umgebung des Angreifers nach der anfänglichen Kompromittierung – damit wird ein einmaliger Vorfall zu einem dauerhaften Zugangskanal zu den Konten des Opfers.
Wichtig ist der Kontext: Alle Techniken erfordern die vorherige Ausführung von Code auf dem Gerät. Es handelt sich nicht um einen Remote-Angriff auf passkey als Technologie, sondern um eine Erweiterung der Möglichkeiten eines Angreifers, der sich bereits im System festgesetzt hat. Für Organisationen, die passkey als Ersatz für Passwörter mit höherer Kompromissresistenz betrachten, zeigt diese Arbeit jedoch, dass die Post-Exploitation-Landschaft komplexer ist als angenommen.
Empfehlungen
Für Betreiber von Webservices (relying party):
- Den Parameter userVerification auf required setzen und das Vorhandensein des UV-Bits in der zurückgegebenen Assertion prüfen – dies ist die einzige Maßnahme, die vollständig auf Service-Seite kontrolliert wird und den ersten Angriffsvektor blockiert.
- Sich nicht ausschließlich auf die Konfiguration der Anfrage verlassen – die tatsächliche Antwort des Authenticators validieren.
Für Credential Provider:
- Bei der Registrierung neuer User-Verification-Schlüssel die Hardware-Attestation prüfen.
- Die Prüfungen bei Neuregistrierung und Wiederherstellung von Geräten verschärfen.
- Den Zugriff auf den lokalen passkey-Status beschränken und sicherstellen, dass Master-Secrets weder in Logs noch in allgemein zugänglichen Speicher gelangen.
Für Endnutzerinnen und Endnutzer:
- Den Endpunktschutz gegen Malware sicherstellen – dies ist für alle drei Angriffe zwingende Voraussetzung.
- Bei Verdacht auf eine Kompromittierung des Geräts den PIN-Code des Google Password Manager ändern und das Löschen der Daten des Passwortmanagers in Betracht ziehen, auch wenn die Wirksamkeit dieser Maßnahmen gegenüber bereits extrahiertem SDS in der Google-Dokumentation nicht bestätigt ist.
Die Analyse von Unit 42 macht ein systemisches Problem deutlich: Die Sicherheit von passkey hängt nicht nur von der Kryptografie ab, sondern von der gesamten Kette – von der Schlüsselspeicherung auf dem Gerät bis zur serverseitigen Validierung. Solange Google keine offizielle Stellungnahme mit einem bestätigten Status der Fixes und einem Mechanismus zur Rotation des SDS veröffentlicht, sollten Organisationen zumindest sicherstellen, dass ihre Webservices den UV-Flag strikt prüfen, und Nutzerinnen und Nutzer sollten aktuelle Chrome-Versionen einsetzen und den Schutz ihrer Endpunkte im Blick behalten.
