- Cloudflare gab bekannt, dass am 23. November 2023 ein Bedrohungsakteur auf den selbst gehosteten Atlassian-Servern entdeckt wurde, Kundendaten, Kundensysteme sowie Systeme und Konfigurationen des globalen Netzwerks jedoch nicht betroffen waren
- Der Eindringpfad bestand aus einem Access Token und drei Service-Account-Zugangsdaten, die nach der Okta-Kompromittierung im Oktober 2023 nicht rotiert worden waren; der Zugriff konzentrierte sich auf die Atlassian-Umgebung, darunter Jira, Confluence und Bitbucket
- Der Bedrohungsakteur führte vom 14. bis 17. November Aufklärung durch und griff auf interne Dokumente zu; am 22. November installierte er anschließend über ScriptRunner for Jira Sliver, um dauerhaften Zugriff zu erlangen
- Cloudflare rotierte im Rahmen einer „Code Red“-Reaktion mehr als 5.000 Produktions-Zugangsdaten, unterzog 4.893 Systeme einer forensischen Vorauswahlprüfung und reimaged bzw. rebootete alle Maschinen des globalen Netzwerks sowie alle Atlassian-Produkte
- Auch eine unabhängige Untersuchung von CrowdStrike fand keine übersehenen Aktivitäten; der letzte Nachweis von Bedrohungsaktivität wurde auf den 24. November 2023 um 10:44 UTC datiert
Überblick über den Vorfall und Umfang der Auswirkungen
- Cloudflare entdeckte am 23. November 2023 einen Bedrohungsakteur auf den selbst gehosteten Atlassian-Servern
- Das Sicherheitsteam leitete sofort eine Untersuchung ein und blockierte den Zugriff
- Am 26. November wurde das Forensik-Team von CrowdStrike für eine unabhängige Analyse hinzugezogen
- Durch den Vorfall waren weder Kundendaten noch Kundensysteme betroffen
- Dienste waren nicht involviert
- Es gab auch keine Änderungen an Systemen oder Konfigurationen des globalen Netzwerks
- Zugriffskontrollen, Firewall-Regeln und über eigene Zero-Trust-Tools erzwungene Hardware-Sicherheitsschlüssel begrenzten laterale Bewegungen
- Der Zugriff des Bedrohungsakteurs war auf Atlassian Confluence, das interne Wiki, Jira, die Bug-Datenbank, Bitbucket, das System zur Quellcodeverwaltung, sowie die Server beschränkt, auf denen Atlassian lief
Für den Angriff verwendete Zugangsdaten
- Der Angriff begann mit einem Service-Token und drei Service-Accounts, die nach der Okta-Kompromittierung im Oktober 2023 offengelegt, aber nicht rotiert worden waren
- Moveworks-Service-Token: wurde für den Remote-Zugriff auf Atlassian-Systeme verwendet
- Smartsheet-Service-Account: besaß Administratorrechte für die Atlassian-Jira-Instanz
- Bitbucket-Service-Account: wurde für den Zugriff auf das System zur Quellcodeverwaltung verwendet
- AWS-Umgebungskonto: hatte keinen Zugriff auf das globale Netzwerk, Kundendaten oder sensible Daten
- Diese Tokens und Accounts wurden fälschlicherweise als ungenutzt eingestuft und daher nicht rotiert
- Cloudflare stellte klar, dass dieses Problem kein Fehler von Atlassian, AWS, Moveworks oder Smartsheet war, sondern darauf zurückging, dass Cloudflare die Zugangsdaten nicht rotiert hatte
Angriffs-Timeline
- Ab dem 14. November um 09:22:49 begann der Bedrohungsakteur mit Systemerkundung und Aufklärung
- Anmeldeversuche bei der Okta-Instanz wurden abgewiesen
- Auch der Zugriff auf das Cloudflare Dashboard wurde blockiert
- Auf die AWS-Umgebung, die den Cloudflare-Apps-Marktplatz betreibt, wurde zugegriffen; diese Umgebung war jedoch vom globalen Netzwerk und von Kundendaten getrennt
- Am 15. November um 16:28:38 gelang der Zugriff auf Atlassian Jira und Confluence
- Mit dem Moveworks-Service-Token wurde das Gateway passiert und mit dem Smartsheet-Service-Account auf die Atlassian-Produktsuite zugegriffen
- Im Wiki wurde nach remote access, secret, client-secret, openconnect, cloudflared, token und weiteren Begriffen gesucht
- Von 2.059.357 Jira-Tickets wurden 36 aufgerufen, von 194.100 Wiki-Seiten 202
- Die aufgerufenen Jira-Tickets umfassten Themen wie Schwachstellenmanagement, Secret-Rotation, MFA-Umgehung, Netzwerkzugriff und Reaktion auf den Okta-Vorfall
- Am 16. November um 14:36:37 erstellte der Bedrohungsakteur mit den Smartsheet-Zugangsdaten einen Atlassian-Account, der wie ein gewöhnlicher Cloudflare-Nutzer aussah, und fügte ihn mehreren Gruppen hinzu
- Dies sollte den weiteren Zugriff auf die Atlassian-Umgebung ermöglichen, selbst falls der Smartsheet-Service-Account entfernt würde
- Vom 17. November um 14:33:52 bis zum 20. November um 09:26:53 wurde der Zugriff auf Cloudflare-Systeme, abgesehen von kurzen Zugriffstests, eingestellt
- Am 22. November um 14:18:22 nutzte der Angreifer die Jira-Administratorrechte des Smartsheet-Service-Accounts, um über das Plugin ScriptRunner for Jira das Sliver Adversary Emulation Framework zu installieren
- Sliver ist ein Tool und Framework, das von Red Teams und Angreifern für C2, Konnektivität sowie dauerhaften und verdeckten Zugriff verwendet wird
- Dadurch wurde dauerhafter Zugriff auf die Atlassian-Server erlangt und eine laterale Bewegung versucht
- Der Versuch, auf einen Nicht-Produktions-Konsolenserver in einem noch nicht produktiv genutzten Rechenzentrum in São Paulo, Brasilien, zuzugreifen, schlug fehl
Zugriff auf Quellcode und Dokumente
- Der Bedrohungsakteur sah sich nach dem 22. November innerhalb eines Tages 120 Code-Repositories von insgesamt 11.904 Repositories an
- Davon wurden 76 Repositories über die git-archive-Funktion von Atlassian Bitbucket auf den Atlassian-Server heruntergeladen
- Cloudflare konnte eine externe Exfiltration nicht bestätigen, behandelte die Repositories aber als exfiltriert und reagierte entsprechend
- Die 76 Repositories standen größtenteils mit folgenden Bereichen in Zusammenhang
- Funktionsweise von Backups
- Konfiguration und Verwaltung des globalen Netzwerks
- Cloudflares Identitätssysteme
- Remote-Zugriff
- Nutzung von Terraform und Kubernetes
- Einige Repositories enthielten verschlüsselte Secrets, und Cloudflare rotierte sie sofort, auch wenn sie stark verschlüsselt waren
- Cloudflare untersuchte vorrangig eingebettete Secrets im Code, Schwachstellen und mögliche Pfade, die für spätere Angriffe ausgenutzt werden könnten, statt den Quellcode selbst
- Cloudflare erklärte, dass das Unternehmen viel Quellcode als Open Source veröffentlicht und in Blogbeiträgen die verwendeten Algorithmen und Techniken öffentlich behandelt habe
Erkennung und Blockierung
- Am 23. November um 16:00 erhielt das Sicherheitsteam eine Warnung über die Anwesenheit eines Bedrohungsakteurs
- 15:58: Der Bedrohungsakteur fügte den Smartsheet-Service-Account der Administratorgruppe hinzu
- 16:00: Die automatische Benachrichtigung über diese Änderung wurde an das Sicherheitsteam gesendet
- 16:12: Das Cloudflare SOC begann mit der Untersuchung
- 16:35: Deaktivierung des Smartsheet-Service-Accounts
- 17:23: Von dem Bedrohungsakteur erstellter Atlassian-Nutzeraccount entdeckt und deaktiviert
- 17:43: Interner Cloudflare-Incident ausgerufen
- 21:31: Firewall-Regeln zum Blockieren der bekannten IP-Adressen des Bedrohungsakteurs angewendet
- Am 24. November wurden die letzte Aktivität und die Entfernung von Sliver bestätigt
- 10:44: Letzte bekannte Aktivität des Bedrohungsakteurs
- 11:59: Sliver entfernt
- Der Bedrohungsakteur versuchte, auf verschiedene Systeme zuzugreifen, darunter interne Metriken, Netzwerkkonfigurationen, Build-Systeme, Benachrichtigungssysteme und Release-Management-Systeme, war dabei aber nicht erfolgreich
- Es wurden keine Hinweise auf Zugriff auf das globale Netzwerk, Rechenzentren, SSL-Schlüssel, Kundendatenbanken oder Konfigurationsinformationen, Cloudflare Workers, AI-Modelle, Netzwerkinfrastruktur oder Datenspeicher wie Workers KV, R2 und Quicksilver gefunden
„Code Red“-Reaktion und Härtungsmaßnahmen
- Nachdem Cloudflare den Bedrohungsakteur am 24. November aus der Umgebung entfernt hatte, zog das Unternehmen Personal aus der gesamten Organisation hinzu, um den Vorfall zu untersuchen und den Umfang des Zugriffs zu bestimmen
- Ab dem 27. November konzentrierte sich ein großer Teil des technischen Personals innerhalb und außerhalb des Sicherheitsteams auf das Projekt Code Red
- Die Kontrollen der Umgebung wurden im Hinblick auf künftige Angriffe gehärtet, überprüft und korrigiert
- Es wurde überprüft, dass der Bedrohungsakteur keinen weiteren Zugriff haben konnte
- Alle Systeme, Accounts und Logs wurden untersucht, um dauerhaften Zugriff sowie Ziele von Zugriffen und Zugriffsversuchen zu identifizieren
- Zu den wichtigsten Maßnahmen gehörten
- Rotation von mehr als 5.000 Produktions-Zugangsdaten
- Physische Trennung von Test- und Staging-Systemen
- Forensische Vorauswahlprüfung von 4.893 Systemen
- Reimaging und Reboot aller Maschinen im globalen Netzwerk
- Reimaging und Reboot aller Atlassian-Produkte, darunter Jira, Confluence und Bitbucket
- Die Ausrüstung des Rechenzentrums in São Paulo wurde an den Hersteller zurückgegeben
- Das Forensik-Team des Herstellers untersuchte, ob Zugriff oder Persistenz erlangt worden war
- Obwohl nichts gefunden wurde, ersetzte Cloudflare die Hardware
- Zusätzlich wurden nicht aktualisierte Softwarepakete, möglicherweise erstellte Nutzeraccounts, ungenutzte aktive Mitarbeiteraccounts, Secrets, die in Jira-Tickets oder Quellcode verblieben sein könnten, sowie ins Wiki hochgeladene HAR-Dateien untersucht
- HAR-Dateien wurden gelöscht, weil sie Tokens enthalten könnten
- Die unmittelbaren Code-Red-Arbeiten endeten am 5. Januar 2024, doch Arbeiten an Zugangsdatenmanagement, Software-Härtung, Schwachstellenmanagement und zusätzlichen Verbesserungen bei Benachrichtigungen laufen weiter
CrowdStrike-Untersuchung und IOCs
- CrowdStrike bewertete unabhängig den Umfang der Aktivitäten des Bedrohungsakteurs und Hinweise auf Persistenz
- Es wurden keine Aktivitäten gefunden, die Cloudflares Untersuchung übersehen hatte
- Als letzter Nachweis von Bedrohungsaktivität wurde der 24. November 2023 um 10:44 UTC bestimmt
- Cloudflare kam auf Basis der Zusammenarbeit mit Partnern aus Industrie und Regierung zu der Einschätzung, dass der Angriff von einem staatlich unterstützten Angreifer durchgeführt wurde, der dauerhaften und umfassenden Zugriff auf Cloudflares globales Netzwerk erlangen wollte
- Cloudflare veröffentlichte Indicators of Compromise, damit andere Organisationen, die möglicherweise von der Okta-Kompromittierung betroffen waren, ihre Logs prüfen können
193.142.58[.]126: wichtigste Infrastruktur des Bedrohungsakteurs, im Besitz von M247 Europe SRL198.244.174[.]214: Sliver-C2-Server, im Besitz von OVH SASidowall[.]com: Infrastruktur zur Bereitstellung der Sliver-Payloadjvm-agent: Dateiname der Sliver-Payload, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 Kommentare
Meinungen auf Hacker News
Wegen solcher öffentlichen Analysen und Reaktionen von Cloudflare glaube ich, dass ich ihnen meine Daten und mein Geschäft anvertrauen kann.
Sie sind nicht perfekt, und es gibt Dinge, mit denen ich nicht einverstanden bin, aber wegen des unternehmensweit geteilten Engineering-Mindsets und der Haltung, solche Vorfälle ernst zu nehmen, wirken sie vertrauenswürdig.
Sie betonen, dass sie eine höhere Integrität als die Konkurrenz haben, und teilen nach dem jüngsten Sicherheitsvorfall einige betriebliche Untersuchungen.
Cloudflare liefert jedoch keine SOC-Risikoanalyse als PCI/DSS-Zahlungskartenverarbeiter und erklärt weder, warum sie die Konten mit erhöhten Rechten übersehen haben, noch wie diese Konten ursprünglich kompromittiert wurden. Sie beschreiben nur die Remediation, nicht die Verantwortung.
Sie erwähnen ein Audit durch Dritte, aber nicht aus Rücksicht auf die Nutzer, sondern weil PCI/DSS von Organisationen, bei denen Zahlungskartendaten kompromittiert wurden, jährliche Vor-Ort-Audits verlangt. Andernfalls hätten die großen Kartenanbieter die Zahlungsabwicklung eingestellt.
Es ist schwer zu glauben, dass nichts verloren ging; in den meisten Jira-/Confluence-Instanzen, die ich gesehen habe, steckten jede Menge vertrauliche Informationen.
Wenn man die Stelle liest: „Unsere Analyse der aufgerufenen Wiki-Seiten, Bug-Database-Issues und Source-Code-Repositories legt nahe, dass sie nach Informationen über Architektur, Sicherheit und Management unseres globalen Netzwerks suchten“, dann ist der einfachste Weg für einen staatlichen Akteur, einen loyalen Bürger als Mitarbeiter beim Zielunternehmen einzuschleusen und ihn diese Informationen schicken zu lassen.
Eine interessante, wenn auch nicht verifizierbare Geschichte: Vor mehr als zehn Jahren sollen bei einem geselligen Treffen von Googles SREs einige zugegeben haben, auf der Gehaltsliste der Geheimdienste ihres Landes zu stehen.
Falls nicht, frage ich mich, was für starke Drogen bei solchen Treffen im Umlauf waren, dass es zu einem so schrecklichen OpSec-Versagen kommen konnte.
Australier bekommen als eine Art Grundbedingung der Staatsbürgerschaft die „Gelegenheit“, an solcher Spionage teilzunehmen: https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
Ein Vorteil könnte sein, dass es hilft, gute Praktiken bei der Entwicklung von Zero-Trust-Prozessen und -Systemen zu erzwingen.
Bei der Stelle „Wir wurden zum zweiten Mal Opfer einer Kompromittierung des Okta-Systems“ frage ich mich, ob Cloudflare seine Okta-Nutzung überdenkt.
Okta verdient ebenfalls Kritik, aber hier wirkt es so, als würde Cloudflare die Verantwortung nach unten weiterreichen, um den eigenen Fehler zu kaschieren.
Ich benutze noch immer ein altes MacBook, das ich in der „Anfangszeit“ bekommen habe, also komplett ohne Managementsoftware. Damals gab es keine IT, und ich bekam einfach einen unberührten neuen Laptop.
Die Firma hat mir ein Upgrade auf ein M1/M2 Pro angeboten, aber ich habe abgelehnt, weil ich kein Okta-Login-System auf einem Arbeitsrechner verwenden möchte, wenn dort auch nur ein einziges persönliches Passwort oder ein Schlüssel liegt.
Deshalb kann ich erst upgraden, wenn es die Arbeit erheblich beeinträchtigt. Vielleicht kann ich solche Vorfälle gegenüber der IT-Abteilung als Begründung für meine Haltung nutzen.
Die Aussage „Ein Service-Token und drei Konten wurden nicht rotiert, weil fälschlicherweise angenommen wurde, sie würden nicht genutzt“ klingt merkwürdig. Wenn sie nicht genutzt werden, warum wurden sie dann nicht gleich stillgelegt?
Vermutlich fehlt da etwas oder ist bei der Weitergabe verloren gegangen, aber wörtlich genommen ergibt der Satz für mich nicht viel Sinn.
Zum Beispiel könnten diese Servicekonten irgendwo in einer Datenbank als inaktiver Zustand wie „stillgelegt“ oder „bereinigt“ markiert gewesen sein, diese Markierung war aber falsch. Also wurden die Passwörter aller aktiven Konten rotiert, während die inaktiven übersprungen wurden.
Wenn ich nur den Kontext von Public-Key-Infrastruktur und Zertifikatswiderruf nehme, den ich gut kenne, sind ein Zertifikat einfach ablaufen zu lassen, es als „nicht mehr verwendet“ zu markieren und es vollständig zu widerrufen ziemlich unterschiedliche Dinge. Eine Zertifizierungsstelle muss im ersten Fall nichts tun, im zweiten kann sie nichts tun oder widerrufen, und im dritten muss sie aktiv eine Sperrliste pflegen und verteilen. Wenn jemand sagt: „Ich habe versehentlich den privaten Schlüssel überschrieben, bitte stellt mir ein Zertifikat für einen neuen Schlüssel aus“, wird das alte Zertifikat normalerweise nicht auf eine Sperrliste gesetzt.
Dass sie klar schreiben: „Dies ist in keiner Weise ein Fehler von AWS, Moveworks oder Smartsheet, sondern lediglich Zugangsdaten, die wir nicht rotiert haben“, ist eine gute Klarstellung.
Cloudflare rotierte alle mehr als 5.000 Produktions-Zugangsdaten und trennte Test- und Staging-Systeme physisch, obwohl man glaubte und später bestätigte, dass der Zugriff des Angreifers begrenzt war; außerdem wurden 4.893 Systeme forensisch geprüft und alle Maschinen im weltweiten Netzwerk neu imaged und neu gestartet.
Auch der Versuch, auf den Konsolenserver des noch nicht in Produktion genommenen Rechenzentrums in São Paulo zuzugreifen, scheiterte. Trotzdem schickte Cloudflare die Ausrüstung des brasilianischen Rechenzentrums zur Forensik an den Hersteller zurück und ersetzte die Hardware, obwohl nichts gefunden wurde.
So weit hätten sie nicht gehen müssen, und es wäre leicht gewesen, es nicht zu tun; dass sie es tatsächlich getan haben, ist lobenswert.
In die frühe Phase des Aufbaus eines neuen Rechenzentrums einzudringen, ist fast der ultimative Exploit. Man stelle sich vor, jemand steht mitten in einem neuen Meet-Me-Room (https://en.wikipedia.org/wiki/Meet-me_room) und erhält dauerhaften Zugriff auf die Core-Switches.
Cloudflare-Rechenzentren sind oft Knotenpunkte für enorme Mengen an Datenverkehr. Dass der Angreifer den Wert eines „Vor-Produktions“-Rechenzentrums kannte, bedeutet wohl auch, dass Cloudflare erkannt hat: Wenn dort ein Brückenkopf entsteht, bevor die regulären Sicherheitsmechanismen eingerichtet sind, ist das zu 100 % Game Over. Wenn es jemandem gelingt, sich in einem Rechenzentrum einzunisten, das gerade aufgebaut und hochgefahren wird, kann das ein existenzbedrohender Vorfall für das Unternehmen sein.
Man muss auch bedenken, dass in der frühen Phase des Rechenzentrumsaufbaus alle Switches und Geräte mit Standardwerten oder leeren root-Passwörtern (admin/admin) laufen und die Firmware oft alt und voller Schwachstellen ist. Wenn so ein Angriff passiert, bevor die Automatisierung die gesamte Firmware patcht, ist das ein Vorfall der Kategorie: „Alle Geräte zurückschicken und den Hersteller neue liefern lassen.“
Wenn man annimmt, dass der Angreifer nur auf den nachweisbaren Zugriffsbereich zugegriffen hat, lässt man ihm Schlupflöcher zum Überleben. Um sagen zu dürfen, dass man das nicht tun muss, sollte es die Zustimmung eines Quorums mehrerer Personen brauchen.
Natürlich ist das die ideale Welt. Ich halte es schon für glücklich, wenn mein Team Zeit bekommt, Features zu implementieren, die keinen direkten finanziellen oder Nutzer-Nutzen haben.
Um bereit zu sein, eine solche Rotation von Zugangsdaten durchzuführen, braucht es Disziplin und Vorbereitung, und ehrlich gesagt investieren die meisten Teams nicht darin. Das gilt auch für kluge und gut ausgestattete Teams.
Wenn das Cloudflare-Security-Team entscheiden kann, alle Secrets zu rotieren und alle Maschinen neu zu imagen, und das dann in angemessener Zeit tatsächlich passiert, ist das ziemlich beeindruckend.
† https://twitter.com/badthingsdaily?lang=en
Der überraschendste Teil hier ist, dass Cloudflare Bitbucket nutzt.
Wenn Daten einmal nach außen gelangt sind, dann ist in diesem Fall der Quellcode praktisch dauerhaft draußen, und man hat keinerlei Kontrolle darüber, wer ihn bekommt.
Man kann nach dem Vorfall so viel härten, wie man will, und so viel darüber reden, wie man will: Das, was man verhindern wollte, ist bereits passiert. Ein aufgeschlagenes Ei bekommt man nicht wieder zurück.
In altem Code lassen sich außerdem andere Easter Eggs finden. Fast jedes Unternehmen hat undokumentierte Backdoors.
Ein Abfluss von Kundendaten wäre schlimmer, aber das hier ist wirklich nicht gut.
Die Kundendaten des nächsten Jahres sind auch nicht dieselben wie die Kundendaten dieses Jahres.
In Atlassians Confluence können sensible Informationen schon allein über die eingebaute Apache-Lucene-Suchmaschine nach außen dringen, und ein solcher Zugriff kann sehr schwer nachzuverfolgen und zu identifizieren sein.
Wenn sensible Informationen bereits auf der Suchergebnisseite angezeigt werden, muss der Angreifer die Confluence-Seite nicht einmal öffnen.
Die Passage „Ein Service-Token und drei Accounts wurden nicht rotiert, weil fälschlicherweise angenommen wurde, sie würden nicht genutzt“ ist merkwürdig. Nicht genutzte Zugangsdaten sollte man wahrscheinlich nicht rotieren, sondern löschen.
War das so eine Situation wie: „Was sind das für Accounts?“ „Ach, die werden nicht genutzt. Tauchen auch in keinen Logs auf.“ „Trotzdem sollten wir sie rotieren.“ „Nein, lassen wir einfach irgendwelche Accounts mit alten Zugangsdaten, die möglicherweise kompromittiert wurden, bestehen … aus irgendwelchen vage vorhandenen Gründen“?
Wenn man nach dem Okta-Vorfall die geleakten Zugangsdaten rotiert hat, hätte man meiner Meinung nach darüber einen Honeypot legen und abwarten sollen, was die Angreifer tun.
Ein Honeypot hat auch den Effekt, dass Angreifer aus Angst vor Entdeckung nicht weiter vorgehen.