Unsecure by Design? Okta im Fokus

Wer ist Okta, Inc.?

Okta, Inc. ist ein börsennotiertes Unternehmen für Identitäts- und Zugriffsmanagement mit Sitz in San Francisco. Es bietet Cloud-Software an, die Unternehmen dabei hilft, die Benutzerauthentifizierung in Anwendungen zu verwalten und abzusichern. Darüber hinaus ermöglicht es Entwicklern, Identitätskontrollen in Anwendungen, Website-Webdienste und Geräte zu integrieren.

Okta vertreibt sechs Dienste, darunter einen Single-Sign-On-Dienst, der es Benutzern ermöglicht, sich über einen zentralen Prozess bei einer Vielzahl von Systemen anzumelden. Es bietet auch API-Authentifizierungsdienste an. Die Dienste von Okta basieren auf der Amazon-Web-Services-Cloud.

Okta’s Kundenbasis

Im Januar 2019 gab der CEO von Okta bekannt, dass das Unternehmen über 100 Millionen registrierte Benutzer hat. Die Kunden von Okta bestehen hauptsächlich aus anderen Unternehmen (B2B) und Behörden wie dem Justizministerium der Vereinigten Staaten.
(Quelle: https://de.wikipedia.org/wiki/Okta_Inc.)

Okta: Opfer einer Cyberattacke

Nun wurde dieses Unternehmen das Opfer einer Cyberattacke. Und das nicht zum ersten Mal. Die Medienberichte dazu sind nicht sehr positiv: “Okta: Schon wieder gehackt.” Solche Angriffe können erhebliche Auswirkungen haben. Der zweite große Kursverlust in diesem Jahr aufgrund von Hacker-Attacken trifft die Okta-Aktie hart und könnte zu langfristigem Reputationsverlust des Unternehmens führen.
(Quelle: https://www.deraktionaer.de/artikel/medien-ittk-technologie/okta-schon-wieder-gehackt-20341720.html

Der zweite Angriff: Ein Blick hinter die Kulissen

Wenn es Probleme mit dem Dienst gibt, kann man sich an den Support von Okta wenden. Es ist dabei nicht unüblich, wenn für die Analyse der Probleme „Supportdateien“ angefordert oder vom Kunden bereitgestellt werden.

In der Regel sind das Protokolle – bei Okta geht das jedoch offensichtlich noch weiter:

“While the company has yet to provide details on what customer information was exposed or accessed in the breach, the support case management system breached in this attack was also used to store HTTP Archive (HAR) files used to replicate user or administrator errors to troubleshoot various issues reported by users. They also contain sensitive data, such as cookies and session tokens, which threat actors could use to hijack customer accounts. ‘HAR files represent a recording of browser activity and possibly contain sensitive data, including the content of the pages visited, headers, cookies, and other data,’ Okta explains on its support portal. ‘While this allows Okta staff to replicate browser activity and troubleshoot issues, malicious actors could use these files to impersonate you.’”
(Quelle: https://www.bleepingcomputer.com/news/security/okta-says-its-support-system-was-breached-using-stolen-credentials/)

Übersetze ich den englischen Text, dann lese ich darin, dass in den überlassenen Dateien auch „cookies und session tokens“ enthalten sind.

Um deren Bedeutung zu verstehen, muss man sich anschauen, wie eine „Anmeldung“ funktioniert. Zunächst identifiziert man sich gegenüber dem Anbieter (also okta oder Microsoft oder andere) mit einem Benutzernamen, einem Kennwort und vielleicht sogar einem „zweiten Faktor“. War das erfolgreich, bekommt man eine Art „temporären Ausweis“ zugewiesen – ein Cookie oder Token.

Diese Information wird als Datei oder vielleicht sogar nur im Arbeitsspeicher des Computers abgelegt. Wenn nun die „Diagnosedaten“ bereitgestellt werden, dann können diese „Ausweise“ darin enthalten sein. Im Fall von okta ist das offensichtlich sogar gewünscht.

Die Auswirkungen eines Identitätsdiebstahls

Bei der Suche nach dem Fehler, wahrscheinlich bei Anmeldeproblemen, kann sich der Support von okta mit einem gültigen Ausweis in einem System anmelden, als wäre man die Person, die das Problem hat. Dieses Vorgehen stellt jedoch nichts anderes als einen „Identitätsdiebstahl“ oder einen Angriff auf eine Identität dar.

Die „Bösen“ überlisten aktuell die Verfahren mit Multi-Faktor-Authentifizierung auf genau diese Weise. Wenn sie Zugang zu einem gültigen Token erhalten, müssen sie sich nicht mehr mit dem Stehlen von Kennwörtern beschäftigen. Sie sind automatisch über den Token zum Zugang berechtigt.

Die Tragweite der Angriffe

Die vollständige Tragweite dieser Angriffe können wir wahrscheinlich aktuell nicht überblicken. Bei Okta kommt verschärfend hinzu, dass es nicht um die eigenen, sondern um Kundendaten handelt. Unternehmen wie „1password“ werden automatisch zum Ziel, weil sie Okta als Anbieter gewählt haben.
(Quelle: https://blog.1password.com/okta-incident/)

Ableitungen für die Informationssicherheit

Aus diesen Vorfällen ergeben sich einige Ableitungen für die Informationssicherheit:

  1. Zugangsgeräte als Gefährdung sehen: Neben den eigentlichen Anmeldedaten sollte man auch die Zugangsgeräte als Gefährdung/Risiko sehen. Wer Zugang zu einem Gerät bekommt, kann sich darüber eventuell auch die Tokens besorgen.
  2. Verbot der Weitergabe von Diagnosedaten: Die Weitergabe jeglicher Form von „Diagnosedaten“ muss grundsätzlich verboten werden. Das Beispiel zeigt, wie bei einem eigentlich legitimen Vorgang durch einen Angriff auf den Dienstleister kritische Unternehmensdaten offengelegt werden können.
  3. Zeitliche Beschränkung von Anmeldungen: Anmeldungen müssen zeitlich beschränkt erfolgen – besonders bei sensiblen Konten wie z.B. Adminkonten. Die Zeit sollte so kurz wie möglich bemessen sein.
  4. Sicherheit ist ein Trugschluss: Nur weil wir die Anmeldungen per MFA absichern, haben wir noch lange keine Sicherheit. Wenn die Angreifer einen anderen Weg finden – hier die ausgestellten Ausweise – bricht das Konstrukt schnell zusammen.