Im vergangenen Jahr entdeckte und enthüllte Varonis Threat Labs Authentifizierungs-Bypasses und Social-Engineering-Angriffe bei mehreren beliebten Cloud-Diensten wie Box, Google und Zoom.
Da wir wissen, dass Okta für Zehntausende von Kunden der Goldstandard für sichere Authentifizierung ist, haben wir uns entschieden, nach ähnlichen Problemen in dieser Suite von Identitätsprodukten zu suchen.
Unsere Suche nach undokumentierten APIs führte uns tief in den Kaninchenbau der hybriden Identitätslösungen von Okta – und zu mehreren bekannt gewordenen Sicherheitsvorfällen:
- CrossTalk – ein Social-Engineering-Angriff, mit dem ein vom Angreifer kontrolliertes kostenloses Entwicklerkonto SMS- und E-Mail-Phishing-Angriffe stagen konnte
- Secret Agent – Hierbei wurde mit einem entschlüsselten SSWS-Token auf dem Okta-Sync-Server ein böswilliger Agent registriert. Dadurch konnten Authentifizierungsanfragen abgefangen und Klartext-Zugangsdaten von beliebigen Benutzern in der Organisation gestohlen werden.
Wie jedes Forschungsteam erzählen wir gerne unsere Geschichten und teilen unsere Techniken – aber wir wissen auch, dass dieses Wissen in den falschen Händen Schaden anrichten kann. Obwohl wir diese Probleme schon im letzten Jahr entdeckt haben, haben wir beschlossen, die Veröffentlichung länger als üblich zu verschieben, um dem hervorragenden Team von Okta genügend Zeit zu geben, sie zu beheben.
Das Okta-Team hat außerdem einen Best-Practice-Leitfaden erstellt, in dem beschrieben wird, wie Sie Ihre Instanzen sicher konfigurieren und solche Angriffe abwehren können. Für weitere Informationen wenden Sie sich an Ihren Kundenbetreuer von Okta.
Wir schätzen die Partnerschaft und die Professionalität des Okta-Sicherheitsteams sehr, ebenso wie ihren Einsatz für die Absicherung ihrer Suite gegen die von uns entdeckten Angriffsarten.
Phishing von Nutzern mit CrossTalk
Okta bietet Kunden einen Mechanismus zum Senden von SMS-Nachrichten und E-Mails an ihre Benutzer. Administratoren können Vorlagen erstellen und Nachrichten auslösen, wenn bestimmte Aktionen ausgeführt werden (z. B. MFA-Code senden, wenn ein Benutzer versucht, sich anzumelden).
Varonis Threat Labs entdeckte CrossTalk, einen Fehler, der es Okta-Admins ermöglichte, SMS- und E-Mail-Nachrichten an jeden Okta-Benutzer in jedem Unternehmen zu senden.
Mithilfe von CrossTalk konnte ein Bedrohungsakteur mit Zugriff auf einen beliebigen Okta-Tenant:
- seine SMS- und E-Mail-Vorlagen an das jeweilige Zielunternehmen anpassen
- Benutzer mit E-Mail-Adressen und Telefonnummern erstellen, die mit den Mitarbeitern des Zielunternehmens entsprechen
- E-Mails und SMS an arglose Benutzer verschicken
Der Benutzer erhält so eine Nachricht vom vertrauten, legitimen Okta-Dienst, ohne jedwede forensische Artefakte oder Hinweise darauf, dass die Nachricht von einem anderen Tenant oder möglicherweise einem böswilligen Akteur stammt.
Um CrossTalk auszunutzen, musste ein Angreifer zunächst einen Okta-Tenant kompromittieren. Das ist eine große Barriere – daher haben wir versucht, ein kostenloses Okta-Konto zu erstellen, von dem aus wir unsere Angriffe durchführen konnten.
Entwicklerkonten hingegen sind eine andere Geschichte! Nachdem wir ein kostenloses Entwicklerkonto in Okta erstellt hatten, konnten wir innerhalb weniger Minuten unserem Marketingteam verdächtige Nachrichten „von Okta“ senden.
Beachten Sie, wie die Nachricht des Angreifers an den Nachrichtenverlauf des Benutzers mit dem offiziellen Okta-SMS-Dienst angehängt wird. So ist es für den Mitarbeiter fast unmöglich, darin irgendetwas Verdächtiges zu erkennen:
Bösartige Nachricht, die vom Okta-SMS-Dienst gesendet wird
Durch die Erstellung eines kostenlosen Entwicklerkontos in Okta konnte ein anonymer Angreifer SMS oder E-Mail-Nachrichten an die Benutzerbasis senden, und zwar scheinbar vom echten Okta-Konto. Das kann genutzt werden, um einen Phishing-Angriff zu starten, MFA zu umgehen, Malware zu verbreiten oder Benutzer zur Durchführung privilegierter Aktionen zu verleiten.
Die Sync-Agenten von Okta entdecken
Social-Engineering-Angriffe mögen ja toll sein, aber wir wollten noch tiefer gehen. Also haben wir unsere eigene lokale Okta-Umgebung angelegt, um zu untersuchen, wie die Okta-Cloud mit lokalen Geräten kommuniziert.
Okta stellt mehrere Agenten bereit, um die Kommunikation mit dem lokalen Realm zu ermöglichen. Wir haben beschlossen, uns auf die Agenten zu konzentrieren, die Unternehmen am häufigsten verwenden: Active Directory (AD) und LDAP. So funktioniert der AD-Sync-Agent:
Okta für Active-Directory-Architektur
Finden von Klartext-Passwörtern
Nach der Einrichtung der Forschungsumgebung und der Bereitstellung der Okta-Agenten versuchten wir sofort, das SSL (Secure Sockets Layer) aus der Kommunikation zwischen Oktas Endgeräten und unserer Lab-Umgebung zu entfernen. Die Intermediate Language (IL) zu dekompilieren macht immer Spaß, ist aber auch zeitaufwändig. Deswegen entschlossen wir uns für eine schnellere Methode, um den Okta-Traffic als Klartext untersuchen können.
Die Einrichtung unseres SSL-Abfangproxys war einfach, da sich bei Produkten das SSL-Pinning für Unternehmensproxys üblicherweise umgehen lässt. Nachdem wir einige Anfragen abgefangen hatten, fiel uns etwas Merkwürdiges auf: Immer wenn Okta-Benutzer versuchten, sich beim Okta-Web-Dashboard anzumelden, wurden ihre Passwörter innerhalb der SSL-Ebene in im Klartext übermittelt.
Das war nicht das einzige ungewöhnliche Verhalten, das uns in unserer Forschungsumgebung auffiel. Während der Installation benötigen Oktas Agenten einen privilegierten Benutzer, um Anfragen für alle Benutzer zwischen der Site und Okta zu autorisieren. Das ist zwar gängig, doch aus einem unbekannten Grund speicherte das Installationsprogramm von Okta die privilegierten Anmeldedaten im Klartext in den Log-Dateien des Installationsprogramms.
Diese Log-Dateien können von allen Benutzern auf dem Computer gelesen werden und können für die laterale Bewegung innerhalb des Unternehmensnetzwerks verwendet werden, falls der Okta-Synchronisierungsserver kompromittiert wird. Das deutet erneut darauf hin, wie wichtig es ist, Ihre Umgebung kontinuierlich nach offenliegenden Geheimnissen zu scannen.
Das Team von Okta hat seitdem sein Installationsprogramm aktualisiert und ein Kontrollkästchen „Keine Logs im Installationsprogramm führen“ hinzugefügt. Dieses verhindert, dass Anmeldedaten in den Installationslogs gespeichert werden.
Angriffe auf die LDAP-API
Nachdem wir einige Protokollanalysen durchgeführt hatten, versuchten wir, die Okta-Prozesse und -Agenten zu replizieren, um sicherzustellen, dass wir die inneren Abläufe verstanden.
Unsere Experimente mit der LDAP-Integration führten uns zu den LDAP-API-Endpoints in Okta. Hier nehmen die Anmelde- und API-Anfragen ihren Weg (ohne große Manipulation) vom Gerät des Benutzers über die Cloud bis hin zum LDAP-Server vor Ort. Unser erster Gedanke war, eine LDAP-Injektion zu versuchen, und siehe da – es hat geklappt!
Wir konnten Benutzernamen mit Klammern an den Endpoint übergeben, und der LDAP-Server interpretierte sie, wenn sie sorgfältig erstellt waren. Obwohl wir die Authentifizierung so nicht umgehen konnten, ließ sich dennoch der Brute-Force-Schutzmechanismus von Okta umgehen, indem wir eine AND-TRUE-Anweisung am Ende des Benutzernamens hinzufügten.
Wir vermuten, dass der Brute-Force-Schutzcode jedes Mal eine Zählervariable erhöht, wenn er den angegebenen Benutzernamen in der Datenbank nicht finden kann. Wenn man nun AND TRUE anhängt (und es vom API-Code interpretieren lässt), wird der Zähler dementsprechend nicht erhöht.
Gemäß unserer Überzeugung, dass die Schwachstellenforschung mit praktischen Angriffen arbeiten sollte, kamen wir zu dem Schluss, dass dieser Angriff zwar valide ist, aber aufgrund der aktuellen Anforderungen an die Passwortkomplexität nicht praktikabel. Wir wollten etwas Besseres finden.
Einen Secret Agent anlegen
Der Einfachheit halber konzentrieren wir uns hier auf den LDAP-Agenten, aber wir konnten diese Angriffe auch auf andere Sync-Agenten durchführen, einschließlich des AD-Sync-Agenten.
Auf dem Computer, auf dem der Okta-Sync-Agent installiert ist, befinden sich zwei vertrauliche Dateien. Eine ist die Konfigurationsdatei des Agenten, die ein verschlüsseltes, langlebiges SSWS-Token enthält. Das andere ist der Installations-Log, der den Benutzernamen und das Passwort für die privilegierte Entität enthält, die der Agent für die Authentifizierung im lokalen Verzeichnis verwendet (diese Anmeldedaten befinden sich auch in der Konfigurationsdatei).
Beispielkonfigurationsdatei für den LDAP-Agenten
Die Active-Directory-Agentenkonfiguration wird mit der Microsoft DPAPI (Data Protection API) verschlüsselt. Die Konfiguration des LDAP-Agenten wird mit einer proprietären Methode verschlüsselt. In beiden Fällen ist die Entschlüsselung des SSWS-Tokens trivial, da wir den dekompilierten Quellcode des Agenten sehen konnten.
Bei der Untersuchung der API, die von Oktas Cloud-Service und dem lokalen Sync-Agenten verwendet wird, stellten wir fest, dass sich das von uns gefundene entschlüsselte SSWS-Token verwenden ließ, um einen bösartigen Sync-Agent zu registrieren. Unser bösartiger Agent kann nach neuen Okta-Anmeldeversuchen abfragen. Wenn die delegierte Authentifizierung aktiviert ist und ein Benutzer versucht, sich anzumelden, sendet der Cloud-Dienst von Okta die Anmeldeanfrage zur Genehmigung an den böswilligen Agenten.
Die Standardeinstellungen sowohl für AD- als auch für LDAP-Agenten erfordern LDAP-Bind-Anfragen mit Klartext-Passwörtern, um den Benutzer im lokalen Verzeichnis zu authentifizieren. Sie ermöglichten es unserem Agenten, die Klartext-Anmeldedaten jedes Benutzers zu hijacken, der versuchte, sich anzumelden.
Keine delegierte Authentifizierung, keine Probleme?
Wenn die delegierte Authentifizierung nicht aktiviert ist, ist die Passwortsynchronisierung normalerweise aktiviert. Diese Funktion synchronisiert Passwörter zwischen Okta und LDAP/Active Directory, sodass Mitarbeiter ihre Passwörter nicht zweimal ändern müssen.
Das zuvor erwähnte SSWS-Token kann auch zum Abhören von Passwortänderungen verwendet werden. Wenn eine Passwortänderung angefordert wird, stellt Okta die Benutzer-ID, die E-Mail-Adresse und das neue Benutzerkennwort als Klartext bereit. Diese sensiblen Daten werden mit einem Schlüssel verschlüsselt, der auch in der Agentenkonfiguration zu finden ist.
Das SSWS kann unbegrenzt verwendet werden, so oft wir möchten, ohne die Funktionalität des ursprünglichen Agenten zu beeinträchtigen. Das bedeutet, dass dasselbe Token verwendet werden kann, um in allen integrierten LDAP- und Active Directorys nach Okta-Befehlen abzufragen.
Wenn die Just-in-Time-Bereitstellung in der Verzeichnisintegration aktiviert ist (impliziert delegierte Authentifizierung), werden alle Authentifizierungsanfragen in Okta an alle LDAP-Agenten weitergeleitet – sowohl für vorhandene als auch für nicht vorhandene Okta-Nutzer. Wir konnten das SSWS-Token eines LDAP-Agenten verwenden, um den Zugriff sowohl auf LDAP- als auch auf Active-Directory-Benutzer zu autorisieren. Es wäre ebenso möglich gewesen, das SSWS-Token zu verwenden, um nicht vorhandene Benutzer zu authentifizieren und sie als Domänenadministratoren bereitzustellen – in der Hoffnung, dass Active-Directory-Domänenadministratoren automatisch privilegierte Berechtigungen in Okta erhalten.
Mit dieser Methode lässt sich auch MFA umgehen, da es sich hierbei um die erste Anmeldung eines neuen Benutzers handelt, also ohne aktivierte MFA. Dieser Angriff hinterlässt ein Artefakt in Okta-Protokollen, denn Okta protokolliert die Bereitstellung eines neuen Benutzers.
Wenn Just-in-Time-Bereitstellung aktiviert ist, werden Authentifizierungsanfragen auch für reine Okta-Benutzer delegiert. Dies sind Benutzer, die in Okta existieren, aber nicht in LDAP oder Active Directory. Der Okta-Superadmin ist in der Regel ein solcher Benutzer. Wenn wir eine solche Anfrage mit unserem kompromittierten SSWS-Token beantworten, können wir möglicherweise auf das Okta-Superadmin-Konto zugreifen.
Die neuen Agenten, die wir registriert haben, wurden im Okta-Admin-Dashboard sowie in den Protokollen angezeigt. Das wäre also eine Möglichkeit, um festzustellen, ob ein Secret Agent in Ihrer Umgebung registriert wurde.
Ein bösartiger Agent kann von überall aus ausgeführt werden. Erfahrene Angreifer tarnen jedoch ihre Diebstahlaktivitäten, indem sie den Angriff von der bereits kompromittierten Umgebung des Opfers aus durchführen. Das ist in diesen Abbildungen dargestellt.
.png?width=333&height=622&name=Blog_VTLOkta_Diagram_MaliciousSyncAgent-DelegatedAuth_V1%20(1).png)
Empfehlungen für Cloud-Sicherheitsteams
Oft können Endbenutzer Phishing-Angriffe nur schwer erkennen, wenn diese von einem legitimen Dienst ausgehen. Es versteht sich von selbst, dass MFA zwar nicht perfekt ist, aber einen effektiven Schutz gegen Phishing und identitätsbasierte Angriffe bietet. Okta bietet außerdem umfangreiche Funktionen, um Ihr Risiko zu mindern:
- Aktivieren Sie das Melden verdächtiger Aktivitäten, damit Endbenutzer unbekannte Aktivitäten aus E-Mail-Benachrichtigungen zu Kontoaktivitäten melden können (z. B. „Haben Sie gerade versucht, Ihr Passwort aus Rumänien zurückzusetzen?“)
- Konfigurieren Sie Okta ThreatInsight so, dass bösartige IP-Adressen erkannt werden, die versuchen, Angriffe mit Anmeldedaten durchzuführen
- Verwenden Sie Okta HealthInsight, um Benachrichtigungen für wichtige Aktionen wie die Aktivierung von MFA-Faktoren, das Zurücksetzen von Faktoren usw. zu aktivieren
Active Directory ist bekannt für seine riesige Angriffsfläche. Die AD-Überwachung sollte ein wesentlicher Bestandteil Ihres Sicherheitsstacks sein, damit Sie Schwachstellen (z. B. Admin-Konten mit SPN) und Fehlkonfigurationen identifizieren und Anomalien erkennen können, die auf gängige Angriffe wie Kerberoasting oder neuartige Angriffe wie Secret Agent hindeuten könnten.
Jeder Cloud-Service hat kritische Aktionen, über die Sicherheitsteams sofort Bescheid wissen sollten. In Okta muss man Bescheid wissen, ob ein neuer Superadministrator erstellt wurde oder, wie wir hier gesehen haben, ob ein neuer Sync-Agent registriert wurde, damit man seine Legitimität überprüfen kann.
Für andere Apps wie GitHub, Salesforce oder AWS sind diese Schlüsselaktionen unterschiedlich. Eine SaaS-Sicherheitslösung wie DatAdvantage Cloud, mit sofort einsatzbereiten Erkennungsfunktionen und Einblicken in Fehlkonfigurationen für die jeweiligen SaaS-Dienste, kann Sie bei der Verwaltung Ihrer Cloud-übergreifenden Sicherheitslage unterstützen und Sie warnen, sobald etwas Ungewöhnliches auftritt.
