Passkey login accepts replayed WebAuthn assertions

Beschreibung

Craft CMS Passkey Login akzeptiert WebAuthn RequestOptions vom nicht authentifizierten Login Request Body und besteht nicht auf dem aktualisierten Berechtigungszähler, der vom WebAuthn Assertion Validator zurückgegeben wird. Ein erfasster Passkey-Login-Request-Body kann daher erneut abgespielt werden, da die alte Challenge wieder angenommen wird und der gespeicherte Berechtigungszähler veraltet bleibt. Craft CMS 5.10.3 und aktuelle `5.x` HEAD akzeptieren `PublicKeyCredentialRequestOptions` vom nicht authentifizierten `users/login-with-passkey` Request Body und setzen die aktualisierte `PublicKeyCredentialSource`, die von `web-auth/webauthn-lib` nach Bestätigungsvalidierung zurückgegeben/mutiert wurde, nicht fort. Infolgedessen ist ein erfasster Passkey-Login-Request-Body nicht einmalig. Das erneute Veröffentlichen der gleichen "RequestOptions" und "Response" kann zu einer Validierung gegen den gleichen veralteten Anmelder führen und eine weitere Craft-Sitzung für diesen Benutzer erstellen. Dies schwächt Passkeys von einer frischen, vom Server herausgeforderten Authentifizierungszeremonie in ein wiederspielbares Träger-Artefakt, wenn ein erfolgreicher Assertion Body ausgesetzt wird. Angriffsszenario 1. Ein Opfer meldet sich erfolgreich mit einem Passkey an. 2. Der 'POST /actions/users/login-with-passkey'-Body, der 'requestOptions' und 'response' enthält, wird aus einem Anwendungs-/Request-Log, einem Debugging-Proxy, einer Browsererweiterung, einer kompromittierten Analyseschicht oder einem anderen Request-Body-Offenlegungspunkt erfasst. 3. Der Angreifer postet den gleichen Körper an "Benutzer / Login-with-Passkey". 4. Craft deserialisiert die von Angreifern bereitgestellten "RequestOptions", so dass die alte Herausforderung für die Validierung akzeptiert bleibt. 5. Der WebAuthn-Validator vergleicht den "signCount" der Behauptung mit dem veralteten gespeicherten Berechtigungszähler. 6. Da Craft die aktualisierte Anmeldedatenquelle im ursprünglichen Login nicht beibehalten hat, wird der gleiche veraltete gespeicherte Zähler erneut verwendet. 7. Die gleiche erfasste Aussage validiert und Craft erstellt eine weitere authentifizierte Sitzung für das Opferkonto. Genau das soll WebAuthns Challenge und Signatur-Counter-Lebenszyklus verhindern: Eine erfolgreiche Assertion sollte an eine Server-herausgegebene Challenge gebunden sein und den serverseitigen Anmeldestatus aktualisieren, damit er nicht wieder verwendet werden kann. ## Auswirkungen Ein angreifer, der einen erfolgreichen passkey-login-anforderungskörper erhält, kann ihn wiedergeben, um zusätzliche authentifizierte craft-sitzungen für diesen benutzer zu erstellen. Dies besiegt WebAuthns beabsichtigten einmaligen Herausforderungs- und Signatur-Counter-Wiedergabeschutz und reduziert eine Passkey-Behauptung auf ein wiederverwendbares Träger-Artefakt, wenn es durch Anforderungsprotokollierung, einen Debugging-Proxy, eine kompromittierte Skriptschicht mit gleichem Ursprung oder einen anderen Offenlegungspfad für Anforderungskörper ausgesetzt wird. Die Auswirkung ist eine Konto-/Sitzungsübernahme des betroffenen Passkey-Kontos, nachdem eine einzige Durchsetzungsstelle erfasst wurde. Das Problem liegt im nativen Passkey-Login-Flow von Craft und betrifft neue Craft-Installationen mit aktivierten Passkeys.

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 5.10.5.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Pixel & Tonic Craft CMS.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.