Passkeys gelten als passwortlose Anmeldemethode, bei der kryptografische Schlüssel auf dem Gerät des Nutzers gespeichert werden. Google beschreibt sie in seiner Dokumentation als widerstandsfähiger gegen Phishing, weil sie sich nicht weitergeben, kopieren, aufschreiben oder versehentlich an Dritte herausgeben lassen. Unit 42 betont jedoch, dass dieser Sicherheitsgewinn die Risiken von Malware auf einem bereits kompromittierten System nicht beseitigt.
Die erste Technik trägt denselben Namen wie die Angriffsfamilie: „Pass-ta-key“. Dabei kann Malware ohne Administratorrechte ein vertrauenswürdiges Gerät nachahmen und für einen Passkey des Opfers eine gültige Authentifizierungsantwort anfordern. Dafür missbraucht die Schadsoftware laut Unit 42 den durch das TPM abgesicherten Geräteschlüssel von Chrome, um eine Anfrage an Googles Cloud-Authentifikator zu signieren. Das soll ohne Interaktion des Nutzers, ohne Biometrie und ohne Entsperren des Geräts möglich sein. Der Cloud-Authentifikator behandle die Anfrage dann so, als käme sie vom vertrauenswürdigen Rechner des Opfers, und liefere eine signierte Anmeldebestätigung zurück.
Allerdings enthält diese Bestätigung ein Kennzeichen dafür, ob tatsächlich eine Nutzerverifikation per PIN oder Biometrie stattgefunden hat. Wird dieses Kennzeichen korrekt geprüft, scheitert der Angriff. Unit 42 zufolge funktionierte der Ansatz deshalb nicht bei GitHub, weil der Dienst das entsprechende Merkmal ordnungsgemäß überprüfte. Gegen eBay sei der Angriff in Tests dagegen erfolgreich gewesen, obwohl eBay eine Nutzerverifikation verlangte. Laut den Forschern validierte eBay das Kennzeichen nicht korrekt; eBay habe den Fehler nach dem Hinweis der Forscher behoben.
Die zweite Methode, „Silver Pass-ta-key“, geht weiter. Hier bringt die Malware Chrome dazu, das Gerät erneut beim Cloud-Authentifikator zu registrieren, etwa indem der vorhandene Schlüssel für die Nutzerverifikation ungültig gemacht oder die lokale Datei mit dem Passkey-Status gelöscht wird. Während dieser Neuregistrierung kann der Angreifer nach Angaben von Unit 42 einen eigenen Schlüssel für die Nutzerverifikation hinterlegen, weil der Cloud-Authentifikator nicht prüft, ob der neue Schlüssel aus vertrauenswürdiger Hardware stammt. Google akzeptiere anschließend Anfragen, die mit diesem Angreiferschlüssel signiert sind, als Nachweis dafür, dass das Opfer das Gerät per PIN oder Biometrie entsperrt habe. Damit werde auch der Zugriff auf Konten möglich, die eine korrekt geprüfte Nutzerverifikation verlangen. Ist der schädliche Schlüssel einmal registriert, kann sich der Angreifer laut Unit 42 sogar von einem anderen System aus authentifizieren, ohne erneut auf den Rechner des Opfers zugreifen zu müssen.
Am weitesten reicht „Golden Pass-ta-key“. Diese Technik soll es Malware ermöglichen, den Hauptschlüssel zu erlangen, mit dem alle über das Google-Password-Manager-Konto des Opfers synchronisierten Passkeys verschlüsselt werden. Dieser Schlüssel, von Unit 42 als „security domain secret“ bezeichnet, wird dem Bericht zufolge vorübergehend an Chrome übermittelt, wenn ein Gerät registriert wird oder den Zugriff auf das Konto wiederherstellt. Zunächst fanden die Forscher, dass Chrome das Geheimnis im Klartext in internen FIDO-Protokollen ausgab. Google entfernte es nach der Meldung aus den Protokollen. Unit 42 erklärt jedoch: „Obwohl Google dieses Geheimnis nach unserem Bericht aus der Protokollausgabe von Chrome entfernt hat, wird das security domain secret weiterhin an den Client gesendet und bleibt im Prozessspeicher von Chrome zugänglich.“ Wenn ein Angreifer das Opfer zu einer erneuten Registrierung zwinge und wisse, wonach er suchen müsse, könne er das Geheimnis direkt aus dem Speicher extrahieren.
Mit diesem gestohlenen Hauptschlüssel lassen sich laut Unit 42 die synchronisierten Passkey-Datensätze des Opfers entschlüsseln und deren private Schlüssel wiederherstellen. Diese privaten Schlüssel könnten auf ein anderes System übertragen und dort zur Anmeldung als Opfer verwendet werden. Die Forscher warnen außerdem, dass sich mit dem gestohlenen Hauptschlüssel auch künftig synchronisierte Passkeys entschlüsseln ließen. Nach ihrer Darstellung bietet Googles aktuelle Implementierung keine Möglichkeit, diesen Schlüssel zu rotieren oder zu widerrufen.
Unit 42 empfiehlt, dass Websites eine Nutzerverifikation verlangen und korrekt validieren. Anbieter von Zugangsdaten-Managern sollten neu registrierte Geräteschlüssel prüfen, Wiederherstellungs- und Neuregistrierungsprozesse absichern und verhindern, dass Hauptschlüssel im Speicher des Browsers zugänglich werden. Die Forscher meldeten die Angriffe auf den Google Password Manager an Google und informierten betroffene Dienste, darunter eBay, über zusammenhängende Schwächen bei der Nutzerverifikation, bevor sie ihre Ergebnisse veröffentlichten.