Verwendung von MITM zur Umgehung des FIDO2-Phishing-Schutzes

Heim » Blog » Verwendung von MITM zur Umgehung des FIDO2-Phishing-Schutzes

FIDO2 ist ein moderner Authentifizierungsgruppenbegriff für passwortlose Authentifizierung. Die Fast Identity Online (FIDO) Alliance hat es entwickelt, um die Verwendung älterer bekannter Passwörter zu ersetzen und eine sichere Methode zur Authentifizierung mithilfe eines physischen oder eingebetteten Schlüssels bereitzustellen.  

FIDO2 ist vor allem dafür bekannt, Menschen vor Man-in-the-Middle- (MITM), Phishing- und Session-Hijacking-Angriffen zu schützen.  

In diesem Artikel führe ich Sie durch meine Forschung, die aufdeckt, wie man mit MITM-Angriffen FIDO2 umgehen kann. Zunächst werde ich eine vollständige WebAuthn- Beglaubigung Flow, dann gehe ich die Schutzmaßnahmen von FIDO2 durch. Dann werde ich bekannte Angriffstechniken angehen und Anwendungsfälle aus der Praxis vorstellen. Abschließend werde ich über Schadensbegrenzungen sprechen und darüber, was Sie tun können, um Ihr Unternehmen zu schützen.   

Aber zuerst einige Hintergrundinformationen

Der FIDO2-Authentifizierungsfluss besteht aus der WebAuthn-API-Spezifikation für eine Client-Relying-Party (RP) – die Cloud-Anwendungskommunikation – und dem Client-to-Authenticator-Protokoll (CTAP) für die Hardware-Kommunikation. Der gesamte Prozess wird vom Browser verwaltet und besteht aus zwei Authentifizierungsschritten: Geräteregistrierung und Authentifizierung.  

Es ist so aufgebaut, weil FIDO2 auf einem Kryptografiemechanismus mit öffentlichem Schlüssel basiert. Hierbei generiert der Client einen privaten und öffentlichen Schlüssel und sendet diesen bei der Anmeldung zur Signaturüberprüfung an RP zurück. FIDO kann als Authentifizierungsmethode für eine einzelne Anwendung oder in einem Verbund eingesetzt werden. Für diejenigen, die es nicht wissen: Ein Verbund bezieht sich auf ein Single Sign-On (SSO) für mehrere unabhängige Anwendungen, die von einem einzigen Identitätsanbieter (IdP) verwaltet werden.  

FIDO2-Sicherheitsfunktionen 

FIDO2 ist bekannt für seine Sicherheitsfunktionen, vor allem zur Verhinderung von Phishing-, Man-in-the-Middle- und Session-Hijacking-Angriffen.  

Im Rahmen meiner Forschung wollte ich herausfinden, ob FIDO2 gegen diese Angriffe immun ist – und war von den Ergebnissen überrascht. Ich begann mit Session Hijacking, einer Angriffstechnik, bei der der Angreifer die Sitzung eines Browsers stiehlt, um Zugriff auf die Anwendung und private Daten des Benutzers zu erhalten. Der zweite Angriff, den ich untersucht habe, war ein Man-in-the-Middle-Angriff (MITM) auf den IdP, bei dem ein Angreifer die Kommunikation zwischen zwei Geräten abhört, modifiziert und weiterleitet, die glauben, dass sie direkt miteinander kommunizieren.  

Heutzutage ist MITM dank des TLS-Schutzes schwieriger zu erreichen. Dennoch gibt es viele Methoden, um ein MITM zu erreichen, einschließlich DNS/DHCP-Spoofing, ARP-Poisoning und SLAAC. Darüber hinaus ist bekannt, dass staatliche Akteure TLS überwinden und entschlüsseln, indem sie das Zertifikat einer Organisation stehlen. Ein Beispiel ist das Angreifen Active Directory Zertifizierungsdienste. 

FIDO wurde entwickelt, um diese Angriffe zu verhindern. Allerdings schützen die meisten Anwendungen bei der Implementierung dieser modernen Authentifizierungsmethode die nach erfolgreicher Authentifizierung erstellten Sitzungstoken nicht. Ich habe festgestellt, dass viele Identitätsanbieter immer noch anfällig für MITM- und Session-Hijacking-Angriffstypen sind.  

Um zu verstehen, wie das funktioniert, müssen wir zu den Grundlagen zurückkehren. 

Im Laufe der Zeit haben sich die Grundlagen der Webkommunikation kaum verändert. Das HTTP-Protokoll und seine Funktionen werden im World Wide Web häufig verwendet, einschließlich der Verwendung von GET und POST zum Übertragen von Attributen zwischen Endpunkten und Cookies, um einen Sitzungsstatus für einen Client beizubehalten. Webanwendungen und SSO-Protokolle wie OIDC und SAML basieren auf dem HTTP-Protokoll und müssen dessen Richtlinien befolgen, um einen Clientstatus aufrechtzuerhalten. Im Laufe der Jahre hat sich die Sicherheit von Benutzersitzungen hinsichtlich der Art und Weise, wie sie lokal vom Browser gespeichert wird und wie sie von der Anwendung berechnet wird, verbessert. Diese Änderungen reichen jedoch nicht aus.  

Wie genau schützt Sie FIDO2? 

Für eine erfolgreiche FIDO2-Authentifizierung muss der Benutzer entweder das FIDO-Gerät bei der vertrauenden Seite registrieren oder den Browser anweisen, eine navigator.credentials.create()-Funktion auszuführen. Dadurch wird das FIDO-Gerät angewiesen, einen privaten und öffentlichen Schlüssel für einen bestimmten Benutzer zu generieren und ihn an einen Domänenursprung zu binden. Der Browser kann dann während des Authentifizierungsprozesses den Domänenursprung der vertrauenden Seite validieren.  

Als nächstes folgt der Authentifizierungsschritt, bei dem die vertrauende Seite für jede Authentifizierungsanforderung navigator.credentials.get() des Browsers aufruft. Sobald es vom RP ausgelöst wird, kommuniziert der Browser über CTAP mit dem FIDO-Sicherheitsschlüssel. Wenn die Authentifizierung vom Endbenutzer genehmigt wird, generiert der Sicherheitsschlüssel mithilfe des gespeicherten privaten Schlüssels eine Signatur. Diese Signatur wird später vom RP mithilfe seines öffentlichen Schlüssels überprüft. 

Bei einem Phishing-Angriff auf eine Website mit einer anderen URL verhindert die Domänenherkunft der validierten Website potenzielle Diebstahl von Anmeldeinformationen weil die URL nicht mit dem registrierten Ursprung übereinstimmt. Der MITM-Angriffsmechanismus ist jedoch anders. Voraussetzung für einen MITM-Angriff ist ein vertrauenswürdiges Zertifikat des Zielopfers. Die meisten modernen Browser geben eine Warnung aus und erzwingen eine sichere Authentifizierung über TLS gegenüber einer Remote-Website. Ein erfolgreicher MITM-Angriff legt den gesamten Anfrage- und Antwortinhalt des Authentifizierungsprozesses offen. Wenn dieser endet, kann der Angreifer das generierte Statuscookie abrufen und die Sitzung des Opfers kapern. Einfach ausgedrückt: Es gibt keine Validierung durch die Anwendung, nachdem die Authentifizierung beendet ist.  

Anwendungsfälle testen 

Ich habe mich entschieden zu nehmen Entra IdP, PingFederate und Yubico als Forschungsanwendungsfälle. Jeder funktioniert anders und hat seine eigenen Vor- und Nachteile.  

Anwendungsfall 1: Yubico Playground 

Der Yubico Playground wurde geschaffen, um FIDO-Sicherheitsfunktionen und -Schlüssel zu demonstrieren und zu testen. In diesem Beispiel authentifiziert FIDO den Benutzer direkt über HTTP bei einer lokalen Benutzerdatenbank. Bei erfolgreicher Authentifizierung wird ein Cookie mit dem Namen „Sitzung“ generiert. Es gibt keine Validierung auf dem Gerät, das diese Sitzung angefordert hat, und jedes Gerät kann dieses Cookie verwenden, bis es abläuft. Der Erwerb dieses Cookies könnte es dem Angreifer ermöglichen, den Authentifizierungsschritt zu umgehen, in den privaten Bereich des Benutzers einzudringen und in diesem Fall den Sicherheitsschlüssel aus dem Profil des Benutzers zu entfernen. Dies ist ein einfaches Beispiel für Session-Hijacking; Wenn wir zu komplizierteren Szenarien übergehen, werden wir sehen, wie sich diese Methode verändert.  

Anwendungsfall 2: Entra ID SSO 

Der zweite Anwendungsfall ist Entra ID SSO verfügt über Sicherheitsfunktionen zur Authentifizierung über verschiedene SSO-Protokolle und andere moderne Authentifizierungsmethoden. Es ist Bedingter Zugriff – Authentifizierungsstärke Die Funktion schränkt passwortlose Mechanismen ein – insbesondere FIDO2. Unser Test validierte native Microsoft-Anwendungen wie Office 365 und das Azure-Verwaltungsportal über das OpenID Connect (OIDC)-Protokoll und Beispielanwendungen von Drittanbietern über das SAML-Protokoll. In beiden Föderationsprotokollen stellt der IdP ein signiertes Zugriffstoken mit einer Ablaufzeit von einer Stunde bereit, das als POST-Attribut an die vertrauende Seite übergeben wird. Beim Federation-Mechanismus muss der Angreifer nicht einmal den Authentifizierungsprozess weiterleiten. Der Angreifer benötigt lediglich ein signiertes Token, und dieses kann im richtigen Zeitrahmen erneut verwendet werden und innerhalb eines längeren Zeitrahmens Statuscookies generieren. OIDC unterstützt Aktualisierungstoken, die Sitzungstoken für einen längeren Zeitraum generieren können. 

Im folgenden Beispiel können wir sehen, dass die native Azure-Verwaltungsportalanwendung das vom SSO gewährte Token nicht validiert. 

Anwendungsfall 3: PingFederate 

Der dritte Anwendungsfall ist PingFederate. Diese Dachanwendung bietet Verbund-SSO für eine Vielzahl von Unternehmensanwendungen. Im Gegensatz zu Entra verwendet Ping Adapter von Drittanbietern zur Durchführung der Authentifizierung. Diese Adapter können in einen Authentifizierungsrichtlinienablauf verkettet werden. Jeder Adapter hat seinen eigenen Kontext und ist vom anderen getrennt. Bei einer erfolgreichen Authentifizierung erfüllt ein Benutzer die Anforderungen aller Adapter in der Richtlinie. FIDO2-Funktionen können mit dem PingOne-Adapter genutzt werden. Überraschenderweise stellte unser Team fest, dass der beschriebene MITM-Angriff erfolgreich sein wird, wenn der Entwickler der vertrauenden Seite das OIDC-Token (oder die SAML-Antwort) nicht validiert.  

Die SSO-Anwendungsfälle sind im Vergleich zum direkten Ansatz schwerwiegender. Da mehr Akteure am Authentifizierungsprozess beteiligt sind, hat die vertrauende Seite weniger Kontrolle über die Validierung der Integrität des Quellgeräts. Obwohl FIDO vor MITM-Angriffen schützt, verlässt sich die gesamte Kette auf ihre schwächsten Glieder, nämlich die SSO-Protokolle, deren gewährende Token von einem anderen Gerät wiederverwendet werden können. 

Abhilfemaßnahmen und nächste Gedanken 

Was wäre, wenn es eine Möglichkeit gäbe, zu überprüfen, ob die authentifizierte Sitzung ausschließlich vom authentifizierten Client verwendet wird? Wir stellen vor Token-Bindung, ein vorgeschlagener Standard aus dem Jahr 2018. 

Mit der Token-Bindung können Anwendungen und Dienste ihre Sicherheitstoken kryptografisch an die TLS-Schicht binden, um Token-Diebstahl und MITM-Angriffe abzuwehren. Token Binding v1.0 bindet die gesamte Sitzung an den zugrunde liegenden TLS-Handshake. Die Public-Key-Kryptografie geht über den Authentifizierungskontext hinaus und WebAuthn stellt die Token-Bindungssignatur sicher bereit.  

Aber wie funktioniert Token Binding? 

  • Beim Client-Server-Hallo ist eine Token-Bindungserweiterung verfügbar. 
  • Die beiden Endpunkte einigen sich auf TLS-Felder, die der Client signieren wird.  
  • Genau wie bei WebAuthn erstellt der Browser ein langlebiges privates/öffentliches Schlüsselpaar.  
  • Der Client sendet den öffentlichen Schlüssel zur Signaturüberprüfung an den RP. Anschließend wird die Signatur über die Anwendungsschicht gesendet.  
  • Der Server überprüft die Signatur und bindet sie an das Sitzungstoken. 

Ich habe diese Untersuchung zunächst Mitte 2023 durchgeführt und die Ergebnisse an Microsoft übermittelt. Als Reaktion auf die erste Offenlegung behauptete Microsoft, es handele sich nicht um eine Sicherheitslücke. Trotzdem ist es ein Angriffsfläche Dies könnte einer exponierten Organisation Schaden zufügen. Vier Monate später präsentierte Microsoft eine Vorschau auf bedingten Zugriff Token-Schutz, Hierbei handelt es sich um eine Variante der Tokenbindung speziell für das Trusted Platform Module (TPM). In seiner Dokumentation erklärt Microsoft, dass Token-Diebstahl selten vorkommt, der Schaden dadurch jedoch erheblich sein kann. Bei Webanwendungen verhält sich TPM möglicherweise ähnlich wie FIDO und verwendet eine andere Kommunikationsmethode als der Sicherheitschip. Das WebAuthn-Protokoll bleibt jedoch für die Browser- und RP-Kommunikation gleich. Die aktuelle Vorschau ist auf bestimmte Webanwendungen und Windows-Clientversionen beschränkt. Die aktuelle Konfiguration ist umständlich und Microsoft wird die Funktion in Zukunft auf generische FIDO-Sicherheitsschlüssel erweitern. 

Bisher ist Microsoft EDGE der einzige Browser, der Token Binding bietet. Chrome bot Token Binding an, entfernte es jedoch aufgrund der geringen Akzeptanz.  

Der Vorschlag von Token Binding diskutiert zwei Arten der Gerätebindung. Eine für die direkte Authentifizierung heißt Provided Token Binding. Dieser Typ kommt häufig bei einfachen Anwendungen wie dem Yubico-Spielplatz vor. Der zweite Typ, Bindung des verwiesenen Tokens erörtert den Schutz sowohl des Identitätsanbieters als auch der vertrauenden Seite. In jedem Fall ist WebAuthn kann passieren die Token-Binding-Signatur sicher in der Authentifizierungsphase.  

Anwendungsmanagern wird empfohlen, eine Token-Bindung für eine FIDO2-Authentifizierung zu fordern, sofern verfügbar.  

Wenn Sie einen Authentifizierungsmechanismus entwerfen, müssen Sie Ihre Bedrohungszuordnung verstehen und Ihre Authentifizierung entsprechend aufbauen. In sensiblen Fällen wird der direkte Ansatz empfohlen, da die Anwendung möglicherweise mehr Kontrolle über das Sitzungstoken hat. 

Für Anwendungsentwickler empfehlen wir, wenn möglich, die Tokenbindung zum FIDO2-Authentifizierungsprozess hinzuzufügen oder zumindest die Verwendung des OIDC-Tokens oder der SAML-Antwort für jede erfolgreiche Authentifizierung auf die einmalige Verwendung zu beschränken.  

Es ist besorgniserregend, dass die großartigen Sicherheitsfunktionen von FIDO2 nicht die gesamte Benutzersitzung schützen. Es ist wichtig zu verstehen, dass moderne Authentifizierungsmethoden kein magischer Sicherheitszauber sind und es nicht ausreicht, sie nur zu kaufen und zu implementieren – man muss ihre Vor- und Nachteile genau verstehen. 

Um darüber zu erfahren, lesen Sie unbedingt unseren Leitfaden: Silverfort, Holen Sie sich hier eine Demo.

Stoppen Sie Identitätsbedrohungen jetzt