Okta-Einbruch: Angreifer griffen auf Daten von 134 Kunden zu

Vor rund zwei Wochen wurde bekannt, dass Cyberkriminelle Zugriffstoken des Identitäts- und Zugangsverwaltungsdienstleisters Okta abgreifen und missbrauchen konnten. Die Analyse von Oktas Sicherheits-Team kommt zum Schluss, dass die Täter durch einen Service-Account auf die Daten von 134 Kunden zugreifen konnten.

Oktas Chief Security Office David Bradbury hat nun einen Untersuchungsbericht vorgelegt, der Ursachen, Auswirkungen und Gegenmaßnahmen zu den Einbrüchen zwischen dem 28. September und 17. Oktober beleuchtet. Dabei konnten die Forensiker bestätigen, dass die Angreifer unbefugten Zugang zu Dateien in Oktas Kunden-Support-System erlangen konnten. Darunter waren HAR-Dateien, die ihrerseits Session-Token enthielten, die Session-Hijacking-Angriffe ermöglichten. Die 134 betroffenen Kunden stellen rund ein Prozent der Kundschaft des Unternehmens dar, bemüht sich Okta, die Reichweite gering darzustellen.

Okta-Einbruch: HAR-Dateien mit Session-Cookies ermöglichen Zugriff

HAR-Dateien erstellen Anwender etwa mit den Entwickler-Werkzeugen vom Webbrowser Google Chrome im Rahmen von Debugging-Sitzungen. Etwa dann, wenn Kunden Probleme melden und der Support diesen auf den Grund gehen will. Diese Dateien enthalten den kompletten Web-Verkehr zwischen Browser und Server, einschließlich sensibler Informationen wie Session-Cookies. Diese Session-Cookies können Angreifer wiederverwenden und damit noch aktive Sitzungen übernehmen.

"Der unbefugte Zugriff auf das Kunden-Support-System von Okta erfolgte über ein im System selbst gespeichertes Dienstkonto. Dieses Service-Konto hatte die Berechtigung, Kunden-Supportfälle einzusehen und zu aktualisieren", führt Bradbury aus. Ein Angestellter habe sich mit seinem persönlichen Google-Profil im Chrome-Webbrowser seines von der Okta-IT verwalteten Laptops angemeldet. Der Nutzername und das Passwort des Dienstkontos wurden dabei im Google-Konto des Angestellten gespeichert. Der laut Bradbury wahrscheinlichste Weg, wie die Angreifer an die Zugangsdaten gelangten, sei das Kompromittieren des persönlichen Google-Kontos des Angestellten oder eines seiner persönlichen Geräte.

Bradbury beschreibt weiter, wie die IT-Forensiker zunächst Probleme hatten, die zugegriffenen und heruntergeladenen Dateien in den Log-Dateien aufzuspüren. Beim Öffnen und Anzeigen von an Support-Fällen angehängten Dateien generiere das System bestimmte Ereignis-IDs und -Typen. Wenn Nutzer jedoch direkt über den Datei-Tab des Systems gehen, wie die Angreifer es taten, erzeugt das komplett andere Ereignisse mit anderen IDs. Erst am 13. Oktober steuerte BeyondTrust eine IP-Adresse von Angreifern bei, anhand derer die IT-Forscher dann weitere Ereignisse und Dateizugriffe, die mit dem kompromittierten Konto verknüpft waren, aufdecken konnten.

Als Gegenmaßnahmen hat Okta den kompromittierten Service-Account geschlossen, die Nutzung persönlicher Google-Konten in Google Chrome Enterprise auf den von Okta verwalteten Laptops per Einstellungsoption unterbunden, erweitertes Monitoring für das Kunden-Support-System eingeführt und Administrator-Session-Tokens an die Netzwerk-Location gebunden. Okta-Administratoren müssen sich dadurch erneut authentifizieren, sofern das System einen Netzwerkwechsel bemerkt.

Kritikpunkt Dienstkonten

Derweil kam auch Kritik in den Medien auf. Während Okta die Verfehlungen eines Mitarbeiters hervorhebt, der Zugangsdaten in einem persönlichen Google-Konto ablegte, liege der Fehler doch viel mehr bei Okta selbst, die Dienstkonten nicht korrekt zu schützen, wirft Dan Goodin von Arstechnica dem Unternehmen vor. "Der Fehler liegt stattdessen bei den Sicherheitsverantwortlichen, die das angegriffene Support-System entwickelt haben, insbesondere die Art und Weise, wie das angegriffene Dienstkonto konfiguriert war", erläutert Goodin.

Dienstkonten kommen üblicherweise für automatisierte Aufgaben zum Einsatz, etwa für nächtliche Datenbank-Backups oder Malware-Scans. Sie lassen sich daher nicht mit Multi-Faktor-Authentifizierung absichern. Dennoch müssen Zugriffe auf solche Konten dennoch abgesichert werden. Etwa eine Einschränkung auf zulässige IP-Bereiche für den Zugriff sei jedoch denkbar. Goodin erwähnt zudem das automatische Rotieren von Zugriffstoken für die Authentifizierung an dem Konto. Und natürlich müsse es Angestellten unmöglich sein, sich auf einer Arbeitsmaschine an persönliche Konten anzumelden. Er verweist auf das Zero-Trust-Prinzip, das hier sinnvoll sei: Ausgehend von der Annahme, dass das Netzwerk bereits kompromittiert sei, müsse es so entworfen werden, dass dennoch keine bösen Dinge passieren könnten. Das setze auf eine mehrschichtige Abwehr, um einzelne Fehlerquellen zu vermeiden wie das Kompromittieren eines Passworts oder Authentifizierungstokens.

(dmk)