[English]Der Anbieter Okta (Anbieter von Authentifizierungsdiensten in der Cloud) musste gerade eingestehen, dass sein Support-System mittels gestohlener Credentials kompromittiert wurde. Der Angreifer konnte Dateien einsehen, die von bestimmten Okta-Kunden im Rahmen aktueller Supportfälle hochgeladen wurden. Der Anbieter fordert inzwischen Kunden auf, ihrer Credentials zu erneuern.
Anzeige
Ich bin über nachfolgenden Post von Will Dormann auf diesen Artikel von Okta gestoßen, in dem der Sachverhalt offen gelegt wird. Das Okta Security Team hat einen Angreifer identifiziert, der sich mit gestohlenen Zugangsdaten Zugriff auf das Support Case Management System von Okta verschafft hat.
Der Angreifer war in der Lage, Dateien einzusehen, die von bestimmten Okta-Kunden im Rahmen aktueller Support-Fälle in das Support-System hochgeladen wurden.
Der Hersteller gibt an, dass das Okta-Support-Fallverwaltungssystem vom Okta-Produktionsdienst getrennt ist. Der Okta-Produktionsdienst sei vollständig in Betrieb und nicht beeinträchtigt worden, heißt es. Darüber hinaus ist das Auth0/CIC-Fallverwaltungssystem von diesem Vorfall nicht betroffen.
Anzeige
Okta schreibt, dass alle Kunden, die von diesem Vorfall betroffen sind, benachrichtigt wurde. Wer als Okta-Kunde über die Medien vom Vorfall erfährt oder über Dritte kontaktiert wird, soll laut Okta nicht betroffen sein.
Wie konnte das passieren?
Der Anbieter erklärt, dass der Okta-Support seine Kunden bei Supportfällen bittet, eine HTTP-Archivdatei (HAR) hochzuladen. Diese HAR-Datei ermöglicht eine Fehlerbehebung durch Replikation der Browseraktivität. Das Problem: HAR-Dateien können auch sensible Daten enthalten, darunter Cookies und Sitzungs-Tokens. Böswillige Akteure können die in den HAR-Dateien enthaltenen Cookies und Sitzungs-Tokens nutzen, um sich als legitime Benutzer auszugeben. Genau dies ist wohl im aktuellen Fall passiert.
Okta hat mit den betroffenen Kunden zusammengearbeitet, um das Problem zu untersuchen, und hat Maßnahmen zum Schutz aller Kunden ergriffen. Dazu gehört auch der Widerrufs eingebetteter Sitzungs-Tokens. Generell empfiehlt Okta, alle Anmeldedaten und Cookies/Session-Tokens in einer HAR-Datei zu säubern, bevor sie weitergegeben werden.
Weitere Hinweise
Okta hat in seinem Artikel Indikatoren für eine Gefährdung (IP-Adressen) aufgelistet, an Hand derer eine eigene Gefährdungsanalyse durchgeführt werden könnte. In diesem Artikel von Bleeping Computer heißt es, dass der Angriff durch das Identitätsmanagement-Unternehmen BeyondTrust, als betroffener Kunde, entdeckt wurde.
Das Sicherheitsteam von BeyondTrust entdeckte und blockierte am 2. Oktober 2023 einen Versuch, sich in ein internes Okta-Administratorkonto einzuloggen. Bei diesem Versuch wurde ein Cookie verwendet, welches aus dem Support-System von Okta gestohlen wurde. Der Sachverhalt wurde von BeyondTrust in diesem Blog-Beitrag dokumentiert.
BeyondTrust schreibt dazu sinngemäß, dass man Okta am 2. Oktober 2023 über die Bedenkung und Vermutungen eines Hacks informiert habe. BeyondTrust stellte dem Unternehmen forensische Daten zur Verfügung, aus denen hervorging, dass die Support-Organisation von Okta kompromittiert wurde. Da es von Okta keine Bestätigung einer möglichen Sicherheitsverletzung gegeben habe, wurde der Vorfall weiter bei Okta eskalaiert. Am 19. Oktober bestätigte die Okta-Sicherheitsleitung, dass tatsächlich eine Sicherheitsverletzung stattgefunden hat und BeyondTrust einer der betroffenen Kunden ist.
BeyondTrust sagt, dass der Angriff durch "benutzerdefinierte Richtlinienkontrollen" vereitelt wurde, aber aufgrund von "Einschränkungen im Sicherheitsmodell von Okta" war der Angreifer in der Lage, "ein paar begrenzte Aktionen" durchzuführen. Trotzdem konnte sich der Angreifer keinen Zugang zu den Systemen des Unternehmens verschaffen, und die Kunden des Unternehmens waren nicht beeinträchtigt. Laut Bleeping Computer ist auch Cloudflare von diesem Vorfall als Kunde betroffen.
Ähnliche Artikel:
Authentifizierungsdienst OKTA durch Lapsus$ gehackt?
Lapsus$-Hacks: Stellungnahmen von Okta und Microsoft
Okta gesteht "Lapsus" bezüglich Offenlegung beim "Lapsus$-Hack" ein
Anzeige
Na Prost. Mit fallen gleich mal drei Banken ein, die Otka als zentrale Zugriffsverwaltung nutzen.
Und das nur in Berlin.
Also ich sehe Okta auch auch großes Problem.
Irgendwie zeichnet ab, dass solche zentralen Tools genau das Gegenteil von Zero Trust sind: Single Point of Failure.