Entmystifizierung von Okta AiTM

Da SaaS-Anwendungen immer beliebter werden und der traditionelle Netzwerkperimeter verschwindet, verlagern Angreifer ihren Fokus auf die Kompromittierung von Identitäten. Vor kurzem veröffentlichte CrowdStrike einen Blogbeitrag, in dem die ersten Angriffsvektoren für den Zugriff auf Okta beschrieben wurden. Dabei wurde Evilginx als eine AiTM-Technik hervorgehoben, die zur Umgehung von MFA und zum unbefugten Zugriff eingesetzt wird. Ihre Analyse, die in diesem Artikel detailliert beschrieben wird, ergab, dass für eine effektive Phishing-Attacke auf Okta-Benutzer mit Evilginx eine Wildcard-Cross-Origin-Resource-Sharing-Richtlinie (CORS) und die Deaktivierung der Gerätezuordnung erforderlich sind. Diese Behauptung ist jedoch irreführend. In diesem Blogbeitrag wird das Konzept von CORS erläutert und veranschaulicht, dass Evilginx bei richtiger Konfiguration in der Lage ist, AiTM-Angriffe unabhängig von den Okta-CORS-Einstellungen zu starten, und auch nicht von der Einstellung „Gerätezuordnung für die Erstellung von Sitzungen erzwingen“ betroffen ist.

Evilginx-Phishing-Mechanismus

Evilginx fungiert als Reverse-Proxy und agiert als Mittelsmann zwischen dem Opfer und dem Zieldienst. Es ermöglicht Angreifern, den Datenverkehr abzufangen und zu manipulieren, hauptsächlich um Sitzungscookies zu stehlen, wodurch sie die mehrstufige Authentifizierung umgehen und Konten übernehmen können.

Der Angriff folgt diesen Schlüsselschritten:

• Einrichtung und Konfiguration: Der Angreifer richtet Evilginx ein und konfiguriert ein Phishlet, eine YAML-Datei, die definiert, wie die Phishing-Website den Datenverkehr an den Zieldienst wie Okta weiterleitet.
• Köderverteilung: Auf der Grundlage des Phishlets wird ein Köder (Phishing-Link) generiert und über Phishing-E-Mails, SMS oder andere Social-Engineering-Taktiken an das Opfer gesendet.
• Cookie-Diebstahl: Das Opfer besucht die Phishing-Website, gibt seine Anmeldedaten ein und führt die mehrstufige Authentifizierung durch (z. B. durch die Genehmigung einer Push-Benachrichtigung oder die Eingabe eines Einmalcodes). Evilginx leitet den Authentifizierungsverkehr des Opfers an den Zielserver weiter und erfasst dabei vertrauliche Informationen wie Benutzername, Passwort und vor allem Sitzungscookies.
• Account Takeover: Der Angreifer extrahiert das gestohlene Sitzungscookie aus Evilginx, importiert es in seinen Browser und erhält Zugriff auf das Konto des Opfers. Mit SSO kann er auch auf andere verbundene Dienste zugreifen.
  

‍

Testen von Evilginx gegen Okta

Evilginx ist Open Source, enthält jedoch standardmäßig keine einsatzbereiten Phishlets. Zwar sind einige von der Community bereitgestellte Phishlets auf GitHub verfügbar, sie sind jedoch oft mit Problemen behaftet.

Wir haben versucht, ein sofort einsatzbereites Phishlet von Github zu testen, das auf unserer Phishing-Testdomain https://dev-49281249.0kta-auth.com gehostet wirdund auf die legitime Okta-Anmeldeseite abzielthttps://dev-49281249.okta.com. Die Anmeldung über einen Proxy kann nicht durchgeführt werden, da in der Browser-Entwicklerkonsole CORS-Fehler angezeigt werden.

‍Was ist CORS?

‍Cross-Origin Resource Sharing (CORS)

Um CORS zu verstehen, müssen wir uns zunächst die Same-Origin Policy (SOP) ansehen. Zwei URLs gelten als vom gleichen Ursprung, wenn sie dasselbe Protokoll, denselben Host und denselben Port (falls angegeben) verwenden. Wenn sich eine dieser Angaben unterscheidet, werden die URLs als Cross-Origin behandelt.

Standardmäßig setzen Browser die Same-Origin Policy (SOP) als Sicherheitsmaßnahme durch, die das Lesen von Daten aus anderen Quellen einschränkt, während das Schreiben und Einbetten von Daten aus anderen Quellen generell erlaubt ist. Das bedeutet:

Eine Webseite kann Daten frei an eine andere Quelle senden (schreiben), der Server entscheidet, ob diese verarbeitet werden, z. B. durch CSRF-Token-Validierung.

• Examples: Links (<a>), redirects, and form submissions (<form>).

Eine Webseite kann Ressourcen aus einer anderen Quelle einbetten.

• Examples: Images (<img>), scripts (<script>), stylesheets (<link>), and iframes (<iframe>).

Eine Webseite kann keine Daten aus einer anderen Quelle lesen, es sei denn, dies wird vom Server ausdrücklich erlaubt.

• Dies verhindert, dass eine bösartige Website Benutzerdaten von einer anderen Website stiehlt.

Eine von einem Bedrohungsakteur kontrollierte Seite auf https://attacker.com kann daher keine Daten von https://yourbank.com lesen. Während die Durchsetzung von Standardverfahren entscheidend ist, um Webangriffe über verschiedene Quellen hinweg zu stoppen, gibt es legitime Anwendungsfälle, die eine Lockerung der Richtlinie erfordern, zum Beispiel:

• Webanwendungen rufen APIs von einem anderen Backend ab (https://frontend.com → https://api.backend.com)
• Cloud-Dienste interagieren über verschiedene Domänen hinweg

Um einen kontrollierten Zugriff über verschiedene Quellen hinweg zu ermöglichen, setzen Browser CORS durch, was eine serverseitige Genehmigung für das Lesen über verschiedene Quellen hinweg erfordert.

Wenn eine Webseite versucht, Daten von einer anderen Quelle über fetch() oder XMLHttpRequest (XHR)abzurufen, überprüft der Browser zunächst, ob der Server dies zulässt.

Um den Zugriff über verschiedene Quellen hinweg ausdrücklich zuzulassen, muss der Server in seiner HTTP-Antwort entsprechende CORS-Header senden.

CORS in Okta

Laut der Dokumentation von Okta müssen alle Webanfragen und Weiterleitungen von Okta zu den Websites Ihrer Organisation ausdrücklich erlaubt werden. Daher werden standardmäßig alle Webanfragen zwischen verschiedenen Quellen abgelehnt.

Bei der sofort einsatzbereiten Einrichtung von Evilginx Phishlets haben wir festgestellt, dass nur ein Teil der Anfragen so konfiguriert ist, dass sie über Evilginx selbst weitergeleitet werden, während der Rest direkt vom Browser an die legitime Okta-Anmeldeseite weitergeleitet wird. Da der Phishing-Ursprung https://dev-49281249.0kta-auth.com nicht zur CORS-Zulassungsliste in der Okta-Einstellung hinzugefügt wird, wird CORS vom Browser blockiert.

Zur Fehlerbehebung können wir den Datenverkehr an Burp Suite weiterleiten und Seiten identifizieren, die immer noch auf die ursprüngliche Domain verweisen.‍

‍

Im Anmeldeanforderungsablauf wird eine POST-Anforderung an /idp/idx/introspect gesendet, die eine JSON-Antwort mit einem MIME-Typ von application/ion+json zurückgibt. Diese Antwort enthält eine URL für nachfolgende Anforderungen.

Diese URL verwendet jedoch immer noch die ursprüngliche legitime Domain, was zu einer Umgehung des Phishing-Proxys führt.

URL-Ersetzung durch Evilginx

Wie ersetzt Evilginx also automatisch Inhalte in der Antwort?

In Evilginx ist

auto_filter

standardmäßig in der

proxy_hosts

-Konfiguration des Phishlets aktiviert, wodurch Evilginx automatisch

sub_filters

-Regeln generiert Diese Regeln ändern den Inhalt der Website mit Proxy dynamisch, indem sie legitime URLs durch Phishing-Proxy-URLs ersetzen. Dadurch wird sichergestellt, dass das Opfer in der Phishing-Sitzung bleibt und nicht auf die legitime Website umgeleitet wird, bevor die Authentifizierung abgeschlossen ist.

Das Kernproblem besteht also darin, dass Evilginx diesen spezifischen MIME-Typ nicht verarbeitet.

Um dies zu beheben, können wir eine benutzerdefinierte sub_filters-Regel erstellen, um die legitime URL durch die Phishing-Proxy-URL zu ersetzen:

Es entsteht jedoch ein neues Problem:

Einige JSON-Antworten enthalten auch Parameter für nachfolgende Anfragen, wie z. B. redirect_uri. Evilginx extrahiert und ersetzt Parameter für GET- oder POST-Anfragen nicht automatisch. Infolgedessen kann die Ersetzung zu aggressiv sein und den Anfragestrom möglicherweise beschädigen.

‍

Um dieses Problem zu lösen, müssen wir diese Parameter explizit extrahieren und verarbeiten. Dies kann mit folgenden Befehlen erfolgen:

• force_get:Erzwingt, dass Evilginx Parameter aus einer URL extrahiert und sie korrekt umschreibt. (Wird standardmäßig nicht unterstützt und erfordert das Patchen von Evilginx.)
• force_post: Stellt sicher, dass Evilginx geänderte POST-Anforderungsparameter korrekt verarbeitet.

‍Sobald diese kleineren Probleme behoben sind, kann Evilginx einen Angriff mit einem Angriffstool für den Diebstahl von Anmeldeinformationen ausführen und Sitzungscookies erfassen. Hier gehen wir davon aus, dass der Benutzer MFA mit einem Code oder einer Push-Benachrichtigung verwendet.

‍

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von Vimeo.
Mehr erfahren

Video laden

Vimeo immer entsperren

‍Kurz gesagt ist die standardmäßige „Alles ablehnen“-CORS-Richtlinie von Okta eine gängige Sicherheitsmaßnahme, um nicht autorisierten Zugriff über verschiedene Quellen hinweg zu blockieren. Allerdings werden Angriffe, die auf Evilginx basieren, dadurch nicht effektiv gestoppt. Angreifer müssen lediglich geringfügige Anpassungen an der Phishlet-Konfiguration vornehmen, was den Angriff zwar etwas komplexer macht, aber nicht verhindert.

Okta-Sitzungsgerätebindung

Im Blog von CrowdStrike wird auch erwähnt, dass Okta Evilginx-Angriffe durch die Durchsetzung der „Gerätebindung für die Erstellung von Sitzungen“ abschwächt. Laut der Dokumentation von Okta stellt diese Funktion sicher, dass Authentifizierungsumleitungen im selben Browser verbleiben, in dem sie initiiert wurden, indem die Gerätekennung in Anfragen verglichen wird. Wenn die Werte nicht übereinstimmen, wird der Zugriff auf eine Anwendung verweigert und keine neue IDP-Sitzung zugelassen.

Diese Option ist standardmäßig aktiviert und hat keine Auswirkungen auf unsere Tests, da Evilginx den gesamten Authentifizierungsprozess übernimmt.

Um zu testen, ob Okta-Sitzungen gerätegebunden sind und ob ein gestohlenes Sitzungscookie in einem anderen Browser verwendet werden kann, haben wir eine kontrollierte Umgebung mit einem anderen Gerät (Betriebssystem), einem anderen Benutzeragenten und einer anderen IP-Adresse eingerichtet.

• Angreifersimulationsumgebung (Windows-VM)
  • Richten Sie eine virtuelle Windows-Maschine ein.
  • Installieren Sie Chrome als Browser.
  • Installieren Sie die folgenden Erweiterungen:
    • StorageAce (zum Importieren von Cookies)
    • User-Agent Switcher (zum Ändern des User-Agents)
    • Proxy SwitchyOmega (konfiguriert für die Verwendung des Tor-Netzwerks, um eine andere IP-Adresse sicherzustellen)

Mit dieser Konfiguration können wir einen Angreifer simulieren, der versucht, gestohlene Sitzungs-Token in einer völlig anderen Umgebung wiederzuverwenden.

Beim Testen des gestohlenen Sitzungs-Cookies in dieser Umgebung funktioniert es für normale Benutzer, aber nicht für Administratoren. Selbst wenn ein Angreifer das Sitzungs-Cookie stiehlt, bleibt es für Administratoren unter den Standardeinstellungen von Okta unbrauchbar, was zu einem 403-Fehler führt.

‍Außerdem werden gestohlene Sitzungscookies sofort ungültig.‍

‍Wir wechselten auch von Tor zu einem mobilen Hotspot, um die Standortverschiebung minimal zu halten, aber das Ergebnis war immer noch dasselbe.

Nach der Konfiguration der VM zur Verwendung des Proxy des Evilginx-Servers bleiben die VM und Evilginx in derselben Netzwerkumgebung, sind aber weiterhin separate Geräte mit unterschiedlichen Benutzeragenten. Unter diesen Bedingungen funktionierte das gestohlene Admin-Session-Cookie erfolgreich, was der Behauptung von Okta widerspricht, dass es gerätegebunden sei.

Diese Ergebnisse deuten darauf hin, dass Okta sich in erster Linie auf die Überprüfung der IP-Adresse verlässt, um Admin-Sitzungen zu schützen. Laut diesem Artikel („Protecting Administrative Sessions in Okta“) verfügt Okta über mehrere Maßnahmen zum Schutz von Admin-Sitzungen, wie z. B. ASN-Sitzungsbindung und IP-Sitzungsbindung. Dies stimmt mit unseren Testergebnissen überein.‍

‍

Bei AiTM-basierten Angriffen wie Evilginx legt die IP/ASN-gebundene Sitzungsabwehr die Messlatte nicht sehr hoch, da die gesamte Okta-Sitzung vollständig von den Angreifern kontrolliert wird, einschließlich der IP und ASN. Im Gegensatz dazu müssten Bedrohungsakteure bei Angriffen nach der Authentifizierung, wie dem Diebstahl von Token von den Geräten der Opfer, die Netzwerkumgebung der Opfer genauer nachahmen. Das ist jedoch über einen Proxy für Privathaushalte immer noch möglich. In unserem vorherigen Blogbeitrag wurde dieses Thema behandelt.

Effektive Abwehrstrategien

Die im Artikel von CrowdStrike erwähnten Okta-Einstellungen können Evilginx-Angriffe nicht effektiv abwehren. Organisationen sollten strengere Sicherheitsmaßnahmen ergreifen, um sich vor Phishing-Bedrohungen zu schützen.

Verhindern Sie Angriffe durch Domain-Identitätswechsel: Schulen Sie Benutzer darin, Phishing-Domains (z. B. 0kta-auth.com) zu erkennen, und setzen Sie Browser- und E-Mail-Sicherheitskontrollen durch, um verdächtige Links automatisch zu blockieren.

• Durchsetzung einer phishingresistenten MFA: Wie am Ende unseres Demo-Videos gezeigt, binden Methoden wie Okta FastPass die Authentifizierung an physische Geräte und ermöglichen so die Identifizierung, ob die Anfrage von einer Phishing-Website stammt, wodurch AiTM-Angriffe wirksam abgewehrt werden.
• Überwachung auf ungewöhnliche Anmeldeaktivitäten: Implementieren Sie Identity Threat Detection & Response (ITDR), um verdächtige Anmeldemuster, wie ungewöhnliche IP-Adressen und geografische Standortänderungen, zu erkennen.‍

Get Started

Start in minutes and secure your critical SaaS applications with continuous monitoring and data-driven insights.

Get a Demo

Quelle: Obsidian Security

---

Ihr Kontakt zu uns:

Pascal Cronauer, Regional Sales Director, Central Europe @Obsidian Security | SaaS Security | SSPM | Threat Mitigation | Integration Risk Mgmt

Marko Kirschner, Technical Enthusiast @Obsidian Security