Hacker stehlen Access Tokens aus der Support-Abteilung von Okta
(krebsonsecurity.com)- Durch eine Kompromittierung des Kundensupport-Systems von Okta wurden Dateien offengelegt, die einige Kunden in Support-Fällen hochgeladen hatten; die Angreifer hatten offenbar mindestens zwei Wochen lang Zugriff auf die Support-Plattform, bevor sie blockiert wurden
- Die Angreifer gelangten mit gestohlenen Zugangsdaten in das System zur Verwaltung von Support-Fällen und konnten HAR-Dateien einsehen, die Kunden zur Fehlerbehebung eingereicht hatten
- HAR-Dateien können Cookies und Session Tokens enthalten; werden sie entwendet, besteht das Risiko, dass Angreifer Sessions wie gültige Nutzer wiederverwenden
- BeyondTrust entdeckte am 2. Oktober den Versuch, in der eigenen Okta-Umgebung ein Administratorkonto zu erstellen; 30 Minuten zuvor hatte das Unternehmen eine HAR-Datei mit einem gültigen Okta Session Token an Okta weitergegeben
- Okta informierte rund 170 Kunden, etwa 1 % seiner mehr als 18.000 Kunden; auch 1Password und Cloudflare machten eine Kompromittierung ihrer Okta-Authentifizierungsplattformen öffentlich, erklärten jedoch, dass Kundendaten oder Systeme nicht betroffen gewesen seien
Kundendateien im System zur Verwaltung von Support-Fällen offengelegt
- Okta stellt Tausenden Unternehmen Identity-Tools bereit, darunter Multi-Faktor-Authentifizierung und Single Sign-on; der Vorfall begann mit einer Kompromittierung der Kundensupport-Abteilung
- In einer Mitteilung an einige Kunden vom 19. Oktober erklärte Okta, dass gestohlene Zugangsdaten für den Zugriff auf das System zur Verwaltung von Support-Fällen verwendet wurden
- Die Angreifer konnten Dateien sehen, die einige Okta-Kunden in jüngeren Support-Fällen hochgeladen hatten
- Der Umfang der Betroffenheit wurde zunächst als „sehr geringe Zahl“ beschrieben; später wurde bestätigt, dass rund 170 Kunden informiert wurden, etwa 1 % der Kundenbasis
Warum HAR-Dateien gefährlich wurden
- Okta fordert bei der Lösung von Kundenproblemen mitunter HTTP Archive(HAR)-Dateien an, also Aufzeichnungen von Webbrowser-Sessions
- HAR-Dateien können Cookies und Session Tokens von Kunden enthalten und sind daher sensibel
- Angreifer können sich mit Cookies oder Tokens aus den Dateien als gültige Nutzer ausgeben
- Okta untersuchte den Vorfall gemeinsam mit betroffenen Kunden und ergriff Schutzmaßnahmen, darunter das Widerrufen eingebetteter Session Tokens
- Vor dem Teilen von HAR-Dateien sollten alle Zugangsdaten, Cookies und Session Tokens entfernt werden
Von BeyondTrust erkannter Angriffsablauf
- Der Sicherheitsanbieter BeyondTrust gehörte zu den Kunden, die am 19. Oktober von Okta informiert wurden
- BeyondTrust-CTO Marc Maiffret sagte, die Mitteilung sei mehr als zwei Wochen eingetroffen, nachdem BeyondTrust Okta auf ein potenzielles Problem hingewiesen hatte
- Das Sicherheitsteam von BeyondTrust entdeckte am 2. Oktober, dass jemand versuchte, mit einem Okta-Konto, das einem eigenen Engineer zugewiesen war, in der Okta-Umgebung des Unternehmens ein mächtiges Administratorkonto anzulegen
- Bei der Überprüfung der Aktivitäten dieses Mitarbeiterkontos stellte sich heraus, dass ein Support Engineer 30 Minuten vor der unbefugten Aktivität auf Anfrage von Okta eine HAR-Datei mit einem gültigen Okta Session Token an Okta weitergegeben hatte
- Die Angreifer versuchten, Cookies aus dem Browserverlauf für Session Hijacking zu nutzen und anstelle dieses Nutzers zu handeln
- BeyondTrust informierte Okta am 3. Oktober darüber, dass Okta sehr wahrscheinlich kompromittiert worden sei, und teilte dieselbe Einschätzung auch in Telefonaten am 11. und 13. Oktober mit
- BeyondTrust erkannte den Angriff während seiner Durchführung und erklärte, dass die eigenen Kunden nicht betroffen seien
Oktas Reaktion und offene Fragen
- Okta Deputy CISO Charlotte Wylie sagte, Okta habe die Meldung von BeyondTrust vom 2. Oktober zunächst nicht als Ergebnis einer Kompromittierung der eigenen Systeme betrachtet
- Bis zum 17. Oktober identifizierte und blockierte Okta den Vorfall, deaktivierte das kompromittierte Kundenkonto für das Case Management und machte die zugehörigen Okta Access Tokens ungültig
- Wylie nannte nicht die genaue Zahl der Kunden, die über ein potenzielles Sicherheitsproblem informiert wurden, beschrieb sie aber als „sehr, sehr kleinen Teil“ von mehr als 18.000 Kunden
- Wie lange die Eindringlinge Zugriff auf das Case-Management-Konto des Unternehmens hatten und wer hinter dem Angriff steckt, wurde nicht offengelegt
- Wylie sagte, der Angreifer sei ein bekannter Threat Actor, der es bereits zuvor auf Okta und bestimmte Okta-Kunden abgesehen hatte
Verwandte Kompromittierungen und spätere Veröffentlichungen
- Oktas Offenlegung erfolgte wenige Wochen nach den Hacks bei Caesar’s Entertainment und MGM Resorts
- In den Fällen der beiden Casino-Unternehmen brachten die Angreifer Mitarbeiter per Social Engineering dazu, die Anforderungen für Multi-Faktor-Authentifizierungs-Logins von Okta-Administratorkonten zurückzusetzen
- Im März 2022 machte Okta eine Kompromittierung im Zusammenhang mit der auf Social-Engineering-Angriffe spezialisierten Hackergruppe LAPSUS$ öffentlich
- Laut Oktas Post-Mortem-Bericht verschaffte sich LAPSUS$ per Social Engineering Zugriff auf die Workstation eines Support Engineers des Drittanbieter-Outsourcing-Unternehmens Sitel, das Zugriffsrechte auf Okta-Ressourcen hatte
- Okta veröffentlichte später einen Blogbeitrag zum Vorfall und nahm darin Indicators of Compromise auf, mit denen Kunden prüfen können, ob sie betroffen sind
- Okta erklärte, alle betroffenen Kunden informiert zu haben
- Das Unternehmen betonte, dass Umgebungen oder Support-Tickets von Okta-Kunden, die nicht separat kontaktiert wurden, nicht betroffen seien
- Auch BeyondTrust veröffentlichte Ergebnisse der eigenen Untersuchung
- In Updates vom 24. Oktober machten 1Password und Cloudflare öffentlich, dass ihre Okta-Authentifizierungsplattformen infolge der Okta-Kompromittierung beschädigt wurden
- Beide Unternehmen erklärten, ihre Untersuchungen hätten ergeben, dass Kundendaten oder Systeme nicht betroffen seien
- Ein Okta-Sprecher sagte gegenüber TechCrunch, man habe rund 1 % der Kundenbasis, etwa 170 Kunden, informiert
1 Kommentare
Meinungen auf Hacker News
Das Lustige an diesem Artikel ist, dass Okta von einem Drittanbieter über verdächtige Tenant-Aktivitäten informiert wurde, zunächst keine Hinweise auf eine Kompromittierung fand und die Kompromittierung erst bestätigte, nachdem BeyondTrust weiter Druck gemacht hatte.
Okta hat dazu diesen Blogbeitrag veröffentlicht: https://sec.okta.com/harfiles
Die Einleitung lautet „Okta Security has identified adversarial activity“, aber von der Benachrichtigung durch einen Drittanbieter ist keine Rede. Tolle Transparenz
Der Titel ist furchtbar und weder transparent noch direkt. Dass Okta nicht einmal erwähnt, dass BeyondTrust sie am 2. Oktober, 30 Minuten nachdem eine HAR-Datei bei Okta Support hochgeladen wurde, informiert hat, ist wirklich miserabel
„Oktas Deputy CISO Charlotte Wylie sagte, Okta sei zunächst davon ausgegangen, dass die Warnung von BeyondTrust vom 2. Oktober nicht auf eine Kompromittierung der eigenen Systeme zurückzuführen sei. Bis zum 17. Oktober habe das Unternehmen den Vorfall jedoch identifiziert und eingedämmt“
Das heißt, einer Firma, die sich als Expertin für Cybersicherheit und Authentifizierung versteht, wurde innerhalb von 30 Minuten mitgeteilt, dass sie gehackt worden war; diese Firma sagte, das stimme nicht, und während sie es 15 Tage lang nicht eingestand, konnte der Angreifer frei agieren.
Wylie, das muss besser werden
Man sollte sich den im Originalartikel verlinkten Blogbeitrag ansehen. Ein Sicherheitsanbieter, der Kunde von Okta war, erkannte kurz nachdem er eine HAR-Datei mit Okta geteilt hatte verdächtige Aktivitäten in seinem eigenen Netzwerk und informierte Okta über die Kompromittierung.
https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...
Vermutlich ist das nur eine komplizierte Art zu sagen, dass sich nach dem Login die IP geändert hat. Die einfachste Lösung ist natürlich, HAR-Dateien aktiver Sessions nicht freiwillig weiterzugeben
Das wird vermutlich unpopulär sein, aber ich frage mich, ob man das zentrale SSO-Gateway mit OAuth, SAML und 2FA nicht on-premises betreiben sollte, statt den „Easy Button“ von SaaS zu drücken.
Dazu zählen nicht nur Okta, sondern auch Auth0 (von Okta übernommen), Authy und Duo
Jede Software hat Sicherheitsbugs, und On-Premises-Software ist da keine Ausnahme. Viele IT-Organisationen haben nicht die Expertise, ein Verzeichnis zu betreiben und zu schützen. Das ist nicht einfach Software installieren, ein paar Accounts anlegen und sie in die Ecke stellen, sondern eine sehr schwierige Aufgabe, zu der Disaster Recovery, Backup-Tests und die Beurteilung gehören, ob man kompromittiert wurde.
Niemand hat bewiesen, dass On-Premises-IT-Sicherheit besser ist als die Sicherheit von Cloud-Anbietern. Unter den On-Premises-IT-Abteilungen, die ich selbst gesehen habe, gab es auch solche mit sehr schlechter Sicherheit: eine, die zwischen 2010 und 2020 noch ein VPN mit MD5-Zertifikaten betrieb; eine, die einen Webservice bereitstellte, über den nicht authentifizierte Nutzer auf personenbezogene Daten wie Sozialversicherungs-/Steuernummern, Adressen, Namen und Telefonnummern zugreifen konnten; eine, die Pflegekräften einen werbefinanzierten Texteditor zum Verfassen von Patientennotizen gab; eine, die eine nicht mehr unterstützte Redcap-Version mit bekannten Sicherheitsbugs nicht aktualisierte, usw.
Soweit ich weiß, ist Redcap Software, die Informationen speichert, die in der medizinischen Forschung und zur Berechnung von Statistiken im öffentlichen Gesundheitswesen verwendet werden, und enthält viele sensible Daten.
Der Kernpunkt ist: Ein Wechsel von der Cloud zu On-Premises kann die Sicherheit verbessern, muss es aber nicht. Es hängt von den Fähigkeiten der jeweiligen IT-Organisation ab, und viele Organisationen sind nicht in der Lage, Identity Services wie Okta zu betreiben. Außerdem haben Cloud-Anbieter in der Regel deutlich größere Budgets und können die Kosten auf viele Kunden verteilen, sodass sie mehr in Sicherheitsexperten, Systemschutz und Einbruchserkennung investieren können
Solchen Managern und Führungskräften stellt niemand Fragen
Man kann tatsächlich Software auf Systemen schreiben und testen, die nie verbunden sind. Überraschend, aber wahr
Identity Provider, Passwortmanager und VPN-Anbieter dürfen auf keinen Fall gehackt werden. Das sind Unternehmen, die mit Sicherheitsprodukten Geld verdienen, und ich werde keine nutzen, die kompromittiert wurden. Wahrscheinlich gibt es da tieferliegende Probleme.
Die Grundannahme ist, dass alle kompromittiert werden können, und die Beweislast dafür, dass sie nicht kompromittiert werden, liegt bei ihnen. Statt Leuten, die wiederholt Inkompetenz gezeigt haben, Wohlwollen entgegenzubringen, scheint es vorsichtiger, auf positive Belege zu warten, die die außergewöhnliche Behauptung stützen, dass sie nicht gehackt werden.
Wenn sie ausreichend kompetent und verantwortungsbewusst sind, werden sie es erkennen und offenlegen, aber die meisten werden das wohl nicht tun. Denn Leute wie du würden dann sofort aufhören, sie zu nutzen. Deshalb sollten alle, die sich auch nur ein wenig Sorgen machen, Offline-, selbst gehostete oder selbst gebaute Alternativen verwenden.
Okta-Challenge: einen Monat lang nicht gehackt werden. Schwierigkeitsgrad: unmöglich
Spaß beiseite: Okta wirkt, als hätte es Freude daran, ausgenommen zu werden. Man würde erwarten, dass sich etwas ändert, wenn der Aktienkurs wegen solcher Vorfälle weiter fällt, aber offenbar nicht.
Der Teufel steckt im Detail. Vermutlich haben sie nach Zero Trust gearbeitet.
Einerseits war es keine Kompromittierung des Kernprodukts. Andererseits geht jeder Kompromittierung eines Kernprodukts eine indirekte Kompromittierung eines Nicht-Kernbereichs voraus.
Wie gut, dass sie den Konkurrenten Auth0 übernehmen durften.
Irgendwann werde ich auf einer Konferenz einen Vortrag über ein Experiment halten: Leute dafür bezahlen, in Support-Rollen bei verschiedenen Unternehmen einzusteigen, und diese Unternehmen dann über die ihnen gewährten Systemzugriffe kompromittieren.
Am Ende der E-Mail stand Folgendes:
„Diese Informationen sind vertrauliche Informationen von Okta und dürfen nicht außerhalb Ihrer Organisation weitergegeben werden.“
Ehrlich gesagt ziemlich lustig.