1Password erkennt „verdächtige Aktivitäten“ in internem Okta-Konto

 (arstechnica.com)
1 Punkte von GN⁺ 2023-10-25 | 1 Kommentare | Auf WhatsApp teilen
  • 1Password hat am 29. September verdächtige Aktivitäten in seiner internen Okta-Instanz festgestellt, die den Zugriff auf Mitarbeiter-Apps verwaltet; eine Kompromittierung von Nutzerdaten oder sensiblen Systemen wurde nicht festgestellt
  • Der Zugriff stand im Zusammenhang mit der Kompromittierung von Oktas Kundensupport-Managementsystem; der Angreifer konnte Authentifizierungs-Cookies und Session-Tokens aus von Kunden hochgeladenen HAR-Dateien erlangen
  • Ein interner Notion-Bericht von 1Password hält fest, dass der Angreifer eine HAR-Datei erlangte, die ein IT-Mitarbeiter bei der Arbeit mit dem Okta-Support erstellt hatte und die Okta-Traffic sowie Session-Cookies enthielt
  • Der Angreifer forderte im Okta-Tenant von 1Password einen Bericht über Admin-Nutzer an und aktualisierte sowie aktivierte einen IDP für die Authentifizierung in der Google-Produktionsumgebung; ein späterer Wiederverwendungsversuch scheiterte jedoch, weil der IDP entfernt worden war
  • Die Okta-Kompromittierung wurde zu einem Beispiel für einen Folgeangriff, bei dem ein Eindringen bei einem Anbieter zu Angriffen auf Kundenunternehmen führt; 1Password ist der zweite bekannte Okta-Kunde, der ins Visier geraten ist

1Password erkennt Zugriff auf internes Okta

  • 1Password ist ein Passwortmanager, der von Millionen Nutzern und mehr als 100.000 Unternehmen verwendet wird
  • Das Unternehmen stellte am 29. September verdächtige Aktivitäten in der Okta-Instanz fest, die es zur Verwaltung von Mitarbeiter-Apps nutzt
  • CTO Pedro Canahuati erklärte, die Aktivität sei sofort beendet und untersucht worden; eine Kompromittierung von Nutzerdaten oder sensiblen Systemen für Mitarbeiter oder Nutzer sei nicht festgestellt worden
  • Anschließend untersuchte 1Password gemeinsam mit Okta, wie ein unbekannter Angreifer Zugriff auf das Konto erhalten hatte

Kompromittierung des Okta-Supportsystems und Risiko durch HAR-Dateien

  • Der Vorfall bei 1Password geht nachweislich auf die von Okta offengelegte Kompromittierung des Kundensupport-Managementsystems zurück
  • Okta erklärte, ein Bedrohungsakteur habe sich unbefugt Zugriff auf das Case-Management-System des Kundensupports verschafft und Dateien eingesehen, die einige Okta-Kunden hochgeladen hatten
  • Zu den erlangten Dateien gehörten HAR-Dateien, mit denen Okta-Supportmitarbeiter Browseraktivitäten von Kunden zur Fehlerbehebung nachstellen
  • HAR-Dateien können sensible Informationen wie Authentifizierungs-Cookies und Session-Tokens speichern und daher von Angreifern missbraucht werden, um sich als legitime Nutzer auszugeben

Zweites bekanntes Ziel nach BeyondTrust

  • Das Sicherheitsunternehmen BeyondTrust entdeckte den Einbruch, nachdem ein Angreifer mit gültigen Authentifizierungs-Cookies versucht hatte, auf dessen Okta-Konto zuzugreifen
  • Bei BeyondTrust konnte der Angreifer „einige wenige eingeschränkte Aktionen“ ausführen, doch Zugriffskontrollen blockierten die Aktivität und sperrten den Kontozugriff
  • 1Password wurde damit zum zweiten bekannten Okta-Kunden, der nach der Okta-Kompromittierung Ziel eines Folgeangriffs wurde

Ablauf des Vorfalls laut internem Notion-Bericht

  • Ein am 18. Oktober verfasster und im internen Notion-Workspace von 1Password geteilter Bericht enthält die Angabe, dass der Angreifer eine von einem IT-Mitarbeiter des Unternehmens erstellte HAR-Datei erlangt hatte
    • Der Mitarbeiter hatte diese Datei kürzlich bei der Zusammenarbeit mit dem Okta-Support erstellt
    • Die Datei enthielt eine vollständige Aufzeichnung des Traffics zwischen dem Browser des 1Password-Mitarbeiters und den Okta-Servern sowie Session-Cookies
  • 1Password reagierte nicht auf eine Anfrage zur Bestätigung der Echtheit des Dokuments, das ein anonymer Mitarbeiter als Text und Screenshots bereitgestellt hatte
  • Laut Bericht griff der Angreifer auch auf den Okta-Tenant von 1Password zu
    • Ein Okta-Tenant wird verwendet, um Systemzugriffsrechte und Berechtigungsstufen zu verwalten, die Mitarbeitern, Partnern und Kunden zugewiesen werden
    • Der Angreifer sah sich Gruppenzuweisungen an und führte weitere Aktionen aus, einige davon wurden jedoch nicht in den Event-Logs erfasst
    • Er aktualisierte den IDP (Identity Provider), der während des Logins für die von Google bereitgestellte Authentifizierung in der Produktionsumgebung verwendet wird

Aktionen des Angreifers und blockierter erneuter Versuch

  • Das IT-Team von 1Password bemerkte den Zugriff am 29. September, nachdem es eine unerwartete E-Mail erhalten hatte, die auf eine Anfrage nach einer Liste von 1Password-Nutzern mit Administratorrechten hindeutete
  • Die Teammitglieder kamen zu dem Schluss, dass kein autorisierter Mitarbeiter diese Anfrage gestellt hatte, und informierten das Sicherheitsteam des Unternehmens
  • Der Angreifer führte folgende Aktionen aus
    • Er versuchte, auf das Okta-Dashboard des IT-Mitarbeiters zuzugreifen, wurde jedoch blockiert
    • Er aktualisierte den bestehenden IDP, der mit der Google-Produktionsumgebung von 1Password verbunden war
    • Er aktivierte diesen IDP
    • Er forderte einen Bericht über Admin-Nutzer an
  • Am 2. Oktober meldete sich der Angreifer erneut im Okta-Tenant von 1Password an und versuchte, den zuvor aktivierten Google-IDP zu verwenden; dies scheiterte jedoch, weil der IDP entfernt worden war
  • Beide Zugriffe erfolgten von Servern des US-amerikanischen Cloud-Hosts LeaseWeb und nutzten eine Chrome-Version auf einer Windows-Maschine
  • Nach dem Vorfall änderte 1Password die Konfiguration seines Okta-Tenants so, dass Logins über Nicht-Okta-Identity-Provider abgelehnt werden

Wenn eine Anbieterkompromittierung zu Angriffen auf Kunden führt

  • Die Okta-Kompromittierung ist Teil einer Reihe von Angriffen der vergangenen Jahre auf Software- und Serviceanbieter mit großen Kundenstämmen
  • Angreifer dringen zunächst beim Anbieter ein und nutzen diese Position anschließend für Folgeangriffe auf Kundenunternehmen
  • Es ist möglich, dass künftig weitere Okta-Kunden bekannt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-25
Meinungen auf Hacker News

  • SSO extern auszulagern, ist nicht nur eine Frage davon, ob es technisch einfacher ist oder ob man die operativen Fähigkeiten dafür hat. Ein wichtiger Faktor ist, dass man in Kundenverträge schreiben kann, einen renommierten SSO-Anbieter zu nutzen, und dass dieser Anbieter auch die Dokumentationspflichten zur Art der Schlüsselverwaltung und zum Schutz des Schlüsselmaterials übernimmt.
    Bei 1Password ist es etwas ungewöhnlich, weil sie diese Strukturen wahrscheinlich bereits haben; normalerweise ist es aber viel einfacher zu sagen: „Niemand in der Organisation kann auf die Schlüssel zugreifen“, als: „Bob ist die Ausnahme; er betreibt den SSO-Server, und wir vertrauen ihm.“

    • Warum ist Okta besser als „Wir vertrauen Bob“? Man vertraut damit Leuten, die man überhaupt nicht kennt, und Okta hatte bereits mehrere bekannte Sicherheitsvorfälle.
    • Dem Messaging-Aspekt stimme ich zu, aber wie sieht es bei der tatsächlichen Sicherheit mit Bob auf Seiten des Dienstanbieters aus?

  • Es ist interessant, dass Speichersicherheitslücken in C am meisten diskutiert werden, aber in der Praxis entsteht großer Schaden oft eher durch den sogenannten Zusammenbruch der Einsicht, der durch übermäßige Komplexität beim Befolgen vermeintlicher Best Practices entsteht.

    • Oft sind es dieselben Lager, die unsicheres C kritisieren und dann wieder ein byzantinisches Monster erschaffen. Es scheint ein normalisierter Anreiz zu wirken, einfache Vorrichtungen in Rube-Goldberg-Maschinen zu verwandeln, um Beschäftigung zu sichern.
    • Organisatorische Bugs können eine Organisation stark treffen, aber Speichersicherheits-Bugs lassen sich meist automatisiert ausnutzen und betreffen alle Organisationen, die die betreffende Software einsetzen. Heartbleed wurde auch deshalb so viel diskutiert, weil die Auswirkungen so groß waren.
    • Am Ende geht es um Komplexität. Man übersieht Dinge, und wenn man etwas aktualisiert, verpasst man die Ketteneffekte, die das auf andere Logik haben kann. Komplexität erzeugt Schwachstellen, aber mehrschichtige Sicherheitsverteidigung und Gegenmaßnahmen können das Risiko senken.
      Ich sehe die menschliche Grenze, enorme Komplexität nicht mehr erfassen zu können, als grundlegende Ursache.
    • Was messbar ist, wird optimiert. Für Software-Schwachstellen gibt es numerische, leicht erfassbare Daten, aber es fehlt an Informationen darüber, wie Daten in Organisationen gestohlen werden – und manchmal sogar darüber, wann sie gestohlen wurden.
      Letzteres hat wahrscheinlich mit Menschen zu tun und ist komplex, weshalb man leichter in der Technik nach Erlösung sucht.
    • Ich frage mich, was mit „Zusammenbruch der Einsicht“ gemeint ist. Klingt nach einem sehr interessanten Konzept.

  • Wenn man den Teil liest, dass „alle System-Zugangsdaten des IT-Teammitglieds ersetzt wurden und MFA so umgestellt wurde, dass nur noch Yubikeys verwendet werden“, wäre es gut, wenn das zum Anlass würde, für alle Beschäftigten Yubikey-basierte Zwei-Faktor-Authentifizierung einzuführen. Alles unterhalb von FIDO2 ist wirklich schwach.
    Ich frage mich, warum sich Leute immer noch für Okta entscheiden. Persönlich finde ich es viel bequemer, GSuite als Identity Provider zu verwenden. Okta hatte ziemlich schwerwiegende Sicherheitsvorfälle, und ehrlich gesagt hatte ich auch davor nichts Gutes über deren Sicherheitspraktiken gehört.

    • Yubikey oder andere browserbasierte MFA hätten diesen Angriff nicht verhindert. Der Angreifer hatte nämlich ein gültiges Admin-Session-Token erhalten, nachdem MFA bereits abgeschlossen war.
      Hardwarebasierte MFA zu erzwingen ist eine gute Praxis und kann künftige Angriffe wie Spear-Phishing verhindern, hat aber mit diesem konkreten Vorfall nichts zu tun.
      Dass Leute Okta wählen, ist eher so etwas wie „niemand wurde je gefeuert, weil er IBM gekauft hat“. Wenn ich ein eigenes Keycloak betreibe und kompromittiert werde, bin ich verantwortlich; bei Okta ist es nicht mehr mein Problem – diese Outsourcing-Struktur spielt ebenfalls eine Rolle.
    • Gestohlen wurde ein Session-Cookie, und Zwei-Faktor-Authentifizierung hat mit diesem Problem nichts zu tun.
      Ich frage mich, ob du Google Workspace jemals ernsthaft für reale Zwecke genutzt hast. Es ist einer der funktionsärmsten Identity Provider, während Okta zu den funktionsreichsten gehört. Das ist, als würde man ein Fahrrad mit einem Motorrad vergleichen, nur weil beide zwei Räder haben.
      Ich hätte nicht gedacht, in einem Technikforum einmal Google Workspace als Identity Provider empfohlen zu sehen.
    • Die meisten Menschen entscheiden sich nicht für Okta. Irgendjemand auf Führungsebene entscheidet sich für Okta, und der Rest muss mit den Folgen leben.
      Wenn man Yubikeys verwendet, landet der gesamte Kundensupport für Passwortprobleme nicht bei einem Outsourcing-Anbieter, sondern bei der internen IT-Abteilung.
      Bei MFA gibt es technische und soziale Probleme. Die technische Sicherheitsseite von Implementierungen wie Keys, Tokens, Smartphones oder SMS ist fast nebensächlich; die sozialen Probleme wie Kundensupport, verlorene Passwörter, Keys in der Waschmaschine oder nicht empfangbare E-Mails überwiegen bei weitem.
      Alle möchten die riesige, dumme Kundensupport-Rolle in der Sicherheit auslagern, aber sobald man das getan hat, haben alle den Anreiz, Kosten zu senken. Das Ergebnis ist Okta.
    • GSuite als Identity Provider zu verwenden, ist sehr eingeschränkt. Es erfüllt zwar die Checkbox „ist ein Identity Provider“, aber sobald man über „kann verbunden werden“ hinausgeht, wird es schwierig oder unmöglich.
      Wenn man zum Beispiel in einer Organisation, in der alle Beschäftigten in GSuite sind, Zugriff auf eine AWS-Organisation bereitstellen will, ist AWS SSO[1] der empfohlene Weg. Richtet man die Verbindung ein, ist der Zugriff möglich, aber es gibt Lücken.
      Es gibt keine Funktion, mit der Nutzer auf Basis von GSuite-Nutzergruppen automatisch in AWS SSO provisioniert oder entfernt werden. Über die SCIM-Unterstützung von SSO kann man zwar selbst Code schreiben, muss ihn dann aber warten.
      Es gibt weder auf GSuite-Seite noch auf AWS-SSO-Seite eine Möglichkeit, beim Erstellen einer SSO-Session eine MFA-Prüfung zu erzwingen. GSuite kann vor der Authentifizierung einer SAML-Anwendung keine MFA-Prüfung verlangen, und AWS SSO kann bei Verwendung eines Identity Providers – anders als beim internen Directory – ebenfalls keine MFA-Prüfung erzwingen.
      Okta und ähnliche Produkte erledigen solche Dinge und sollen je nach verwendetem Endpoint auch MFA-Prüfungen erzwingen können. Ich habe es nicht selbst ausprobiert; das basiert auf Marketingmaterial und Vertriebserklärungen.
      Kurz gesagt bietet Okta zwischen Identity Provider und genutzten Anwendungen deutlich mehr Automatisierungs- und Sicherheitsklebstoff.
      [1] AWS SSO meint hier das AWS-Produkt „AWS IAM Identity Center (Successor to AWS Single Sign-On)“.
    • Gibt es Belege dafür, dass Okta besser oder schlechter ist als andere Lösungen? Sicherheitsmessung ist sehr schwierig.
      Die derzeit sichtbaren Belege sind ungefähr: Okta wurde im vergangenen Jahr kompromittiert, wurde auch diesmal kompromittiert, und dieser Vorfall ereignete sich in der Kundensupport-Abteilung oder deren Systemen. Die Offenlegung des Vorfalls könnte verspätet gewesen sein, aber wegen vieler Falschmeldungen könnten sie bis vor Kurzem auch keine Beweise gefunden haben. Sie haben dem Kunden, der zuerst gemeldet hat, keine Anerkennung gegeben und nach der Meldung möglicherweise nicht ordentlich mit dem Kunden kommuniziert.
      Was wir nicht wissen, ist viel mehr: wie versiert die Angreifer waren; wie oft die einzelnen Identity Provider kompromittiert wurden; wie oft sie solche Vorfälle erkannt haben; ob sie sie erkannt und dann vertuscht haben; wie viele Sicherheitsbugs die einzelnen Dienste haben, wie schwerwiegend und wie leicht zu finden sie sind; wie gut ihre Fähigkeiten zur Erkennung von Kompromittierungen sind; wie gut die Mitarbeitenden geschult sind; und welcher Anteil der Mitarbeitenden sich tatsächlich um Sicherheit kümmert.
      Nur weil Okta einen Vorfall gemeldet hat, kann man nicht schließen, dass das Produkt schlechter ist. Wir wissen nicht, wie gut andere Produkte sind; Okta könnte besser sein als einige oder alle Wettbewerber – und natürlich auch schlechter.

  • Früher kaufte man 1Password zum Listenpreis, und die Software funktionierte vollständig offline, wobei der verschlüsselte Tresor lokal oder in Dropbox gespeichert wurde. Da es online nichts zu stehlen gab, musste man sich auch keine Sorgen um Hacker machen.
    Dann hat jemand den Taschenrechner gezückt und entschieden, dass der Weg zu mehr Profitabilität darin besteht, die Daten aller in die Cloud zu verschieben und Abogebühren zu kassieren. Und nun machen wir uns Sorgen, ob unsere Daten abgeflossen sind.

    • Es stimmt aber auch, dass der Komfort für Menschen, die nicht versiert genug sind, das selbst zu handhaben, stark gestiegen ist.
      Und wie sehr unterscheidet sich das, soweit wir derzeit wissen, davon, den Tresor in Dropbox abzulegen? Dropbox kann ebenfalls gehackt werden, und dessen Daten sind bekanntlich nicht verschlüsselt. Es ist doch noch kein Fall bekannt, in dem ein 1Password-Tresor tatsächlich kompromittiert wurde, oder?

  • https://blog.1password.com/okta-incident/
    Ursprünglicher Incident-Report: https://blog.1password.com/files/okta-incident/okta-incident...

    • Das ist der interessante Teil. Während ein IT-Teammitglied mit dem Okta-Support arbeitete, erstellte es auf Anfrage in den Chrome Developer Tools eine HAR-Datei und lud sie ins Okta-Support-Portal hoch; diese Datei enthielt die gesamte Aufzeichnung des Traffics zwischen Browser und Okta-Servern sowie sensible Informationen wie Session-Cookies.
      Danach griff ein unbekannter Akteur mit derselben Okta-Session, die beim Erstellen dieser HAR-Datei verwendet worden war, auf das Okta-Admin-Portal zu.
      Wie Banken immer sagen: Man darf dem Support niemals sein Passwort geben.

  • Die Verantwortung liegt diesmal eindeutig bei Okta. Zur Problemlösung verlangen sie HAR-codierte Sitzungen im Klartext und hoffen nur darauf, dass Endnutzer sie ordentlich bereinigen.
    Könnte man die HAR-Daten nicht beim Upload bereinigen, sodass im System nur die relevanten und sicheren Teile übrig bleiben, wenn die schlecht bezahlten und unterbesetzten Support-Techniker sie sehen?
    HAR ist strukturierte Daten und lässt sich daher sehr leicht programmatisch bereinigen. Das ist keine Raketenwissenschaft.

  • Leute fragen immer wieder, warum man statt eines supereinfachen und superkomfortablen Online-Dienstes einen selbst gehosteten, selbst synchronisierten Passwortmanager nutzt; der Grund ist derselbe: Man wirft die Schlüssel zur eigenen Wohnung ja auch nicht in den Tresor des Bahnhofs im Viertel.

    • Man kann sich damit sicherer fühlen, aber in Wirklichkeit muss es das nicht sein. Wenn ein dedizierter Angreifer Okta kompromittieren kann, kann er auch deinen selbst gehosteten Passwortmanager kompromittieren, bei dem du rechtzeitige Updates vergessen hast oder Updates verspätet ankommen.
      Solche Organisationen beheben Probleme Wochen, manchmal Monate, bevor sie eine Stellungnahme veröffentlichen.
      Wenn man Open Source nutzt und ein kritischer Bug entdeckt wird, bekommt man den Patch zusammen mit der Pressemitteilung; große Dienste haben das Problem aber mit hoher Wahrscheinlichkeit bereits behoben. Für durchschnittliche Nutzer liegt das Nutzen-Risiko-Verhältnis eher bei Service-basierten Lösungen.
    • Das ist irrelevant. Die Passwörter in 1Password sind mit einem Schlüssel verschlüsselt, den nur der Nutzer besitzt. Es ist sehr fraglich, ob man einen privaten Homeserver sicherer betreiben kann als die Server von 1Password.
    • Ich nutze ebenfalls das pass-Kommandozeilentool + git und hatte bisher kein einziges Problem.
      Es lässt sich auch in Skripten verwenden.
      Keine Serverkompromittierung, keine Schwachstellen in Web-Erweiterungen, kein Risiko, durch einen Serverfehler alle Passwörter zu verlieren. Es funktioniert einfach.
    • Ich verstehe den Punkt, aber wenn mein Passworttresor aus selbst gehosteter Software und einer selbst gehosteten Tresordatei bestünde, würde ich mir wohl täglich Sorgen über Datenverlust machen.
    • Mich würde interessieren, was du verwendest.

  • Die Formulierung „1Password wurde der zweite bekannte Okta-Kunde, der Ziel eines Folgeangriffs wurde“ ist seltsam. Weiß Ars nicht, dass auch Cloudflare betroffen war?
    https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

    • Gemeint scheint zu sein, dass BeyondTrust das Problem gemeldet hat, Cloudflare der erste bekannte Okta-Kunde war, der angegriffen wurde, und 1Password der zweite.

  • Mich interessieren Best Practices zum Monitoring von verdächtigem Verhalten in Apps. Die Basics wie Anfrage- oder Fehlerraten auf Service-Ebene kenne ich, aber wie ausgefeilt wird das in der Praxis?
    Ich frage mich, ob es intelligente Tools gibt, die man mit einem Event-Stream füttert und die dann anomales Verhalten finden, oder ob man alles, was überwacht werden soll, im Voraus bedenken und Regeln hinzufügen muss.

    • Ich bin nur ein Laie vom Sofa ohne Erfahrung in diesem Bereich, also mit Vorsicht genießen. Die Priorität ist ein Audit Trail. Jede Aktion an Nutzerkonten oder Daten und jede Änderung am System sollte in einem Audit-Log stehen, inklusive Zeitstempel, Nutzer usw. Besonders Dinge wie Änderungen an Passwörtern oder Kontodetails.
      Wenn man so einen Event-Stream hat, kann man Datenanalyse-Tools darauf laufen lassen. Aus Aktivitäten über Tage, Wochen oder Monate sollte eine normale Baseline entstehen, und auffälliges Verhalten wie massenhafte Passwortänderungen oder E-Mail-Änderungen sollte Alarm auslösen.
      Das ist allerdings nur eine Sofa-Hypothese; ich würde gern wissen, ob jemand tatsächlich mit Audit-Logs und deren Nutzung gearbeitet hat.
    • Als Idee für ein AI-Startup ganz brauchbar. Man proxyt einfach alle Anfragen über einen Drittanbieterdienst als Security as a Service und lässt ihn Anomalien erkennen. Nur wird dieser Dienst wohl keine Verantwortung übernehmen, wenn er nichts erkennt.
    • https://www.obsidiansecurity.com/

  • Schon wieder erkannt?
    https://news.ycombinator.com/item?id=37991863