Sicherheitsvorfall an Thanksgiving 2023

Sicherheitsvorfall an Thanksgiving 2023

• Am 23. November 2023, dem Thanksgiving-Feiertag, entdeckte Cloudflare einen Bedrohungsakteur auf selbst gehosteten Atlassian-Servern.
• Das Security-Team leitete sofort eine Untersuchung ein und blockierte den Zugriff des Bedrohungsakteurs.
• Am 26. November wurde das Forensik-Team von CrowdStrike für eine unabhängige Analyse hinzugezogen.
• CrowdStrike schloss die Untersuchung ab, und Cloudflare teilt in diesem Blogpost die Details des Sicherheitsvorfalls.
• Cloudflare betont, dass Kundendaten oder Systeme von Cloudflare durch diesen Vorfall nicht betroffen waren.
• Zugriffskontrollen, Firewall-Regeln und die erzwungene Nutzung harter Sicherheitsschlüssel mit Zero-Trust-Tools begrenzten die Fähigkeit des Bedrohungsakteurs zur lateralen Bewegung.

Wiederherstellung und Härtung unter „Code Red“

• Nachdem der Bedrohungsakteur aus der Umgebung entfernt worden war, mobilisierte das Security-Team im gesamten Unternehmen alle erforderlichen Personen, um die Untersuchung des Eindringens und die Unterbindung des Zugriffs abzuschließen.
• Ab dem 27. November wurden technische Fachkräfte gebündelt und auf ein Projekt mit dem Namen „Code Red“ konzentriert.
• Ziel dieses Projekts war es, alle Kontrollen in der Umgebung zu härten und zu validieren, um sich auf künftige Eindringversuche vorzubereiten und zu verhindern, dass der Bedrohungsakteur erneut Zugriff auf die Umgebung erhält.
• CrowdStrike führte eine unabhängige Bewertung des Umfangs und Ausmaßes der Aktivitäten des Bedrohungsakteurs durch.

Zeitlinie des Angriffs

• Der Angriff begann mit der Sicherheitsverletzung bei Okta im Oktober; ab Mitte November zielte der Bedrohungsakteur mit Zugangsdaten, die durch den Okta-Vorfall erlangt worden waren, auf die Systeme von Cloudflare.
• Durch den Okta-Vorfall am 18. Oktober erhielt der Bedrohungsakteur Zugriff auf Zugangsdaten.
• Ab dem 14. November begann der Bedrohungsakteur mit der Erkundung der Systeme und mit Zugriffsversuchen.
• Am 15. November gelang der Zugriff auf Atlassian Jira und Confluence.
• Am 16. November wurde ein Atlassian-Benutzerkonto erstellt.
• Vom 17. bis 20. November erfolgte kein Zugriff auf Cloudflare-Systeme.
• Am 22. November wurde das Sliver Adversary Emulation Framework installiert, um dauerhaften Zugriff zu sichern.
• Am 23. November erkannte das Security-Team die Präsenz des Bedrohungsakteurs und begann damit, den Zugriff zu unterbinden.

Fazit

• Es wird vermutet, dass dieser Vorfall auf einen staatlich unterstützten Angreifer zurückgeht, und Cloudflare hat erhebliche Anstrengungen unternommen, um die Auswirkungen zu begrenzen und sich auf künftige Angriffe vorzubereiten.
• Das Engineering-Team von Cloudflare schützte die Systeme, analysierte den Zugriff des Bedrohungsakteurs, ging unmittelbare Prioritäten an und entwickelte einen Plan zur Verbesserung der allgemeinen Sicherheit.
• CrowdStrike führte eine unabhängige Bewertung durch, und nach Abschluss des Abschlussberichts veröffentlichte Cloudflare diesen Blogpost in dem Vertrauen, die interne Analyse und die Maßnahmen zum Eindringen fundiert abgeschlossen zu haben.

GN⁺-Meinung:

1. Dieser Vorfall unterstreicht die Bedeutung der Zero-Trust-Architektur von Cloudflare. Sie funktioniert so, dass durch die Isolierung zwischen Systemen die Ausbreitung von Bedrohungen auf die gesamte Organisation begrenzt wird.
2. Die schnelle Reaktion von Cloudflare und die Bemühungen zur Härtung der Sicherheit im Rahmen des Projekts „Code Red“ bieten Einblicke darin, wie Unternehmen auf Cybersecurity-Bedrohungen reagieren.
3. Dieser Beitrag dient als nützliches Fallbeispiel dafür, wie Organisationen auf Cybersecurity-Vorfälle reagieren und welche Maßnahmen sie ergreifen sollten.

[GN⁺]

Hacker-News-Kommentare

• Warum Handlungen wie der Blogpost von Cloudflare Vertrauen schaffen

  • Cloudflare ist nicht perfekt, wirkt aber aufgrund seiner technischen Denkweise und seines Umgangs mit ernsten Problemen vertrauenswürdig.
  • Ausdruck von Dankbarkeit für den Blogpost.

• Das Problem von Datenlecks

  • Sobald Daten einmal abgeflossen sind, sind sie dauerhaft nicht mehr kontrollierbar.
  • Härtungsmaßnahmen und Gespräche nach dem Vorfall sind wichtig, können aber nicht verhindern, was bereits geschehen ist.

• Sicherheitsprobleme im Okta-System

  • Sorge darüber, dass das Okta-System zum zweiten Mal betroffen war.

• Nicht rotierte Service-Token und Accounts

  • Sie wurden nicht rotiert, weil man fälschlich davon ausging, dass sie nicht verwendet würden.
  • Frage, warum sie nicht vollständig widerrufen wurden.

• Begrenzter Zugriff der Angreifer und Reaktionsmaßnahmen

  • Man ging davon aus, dass der Zugriff der Angreifer begrenzt war, ergriff aber dennoch umfassende Maßnahmen wie die Rotation aller Produktionszugangsdaten, forensische Analysen der Systeme sowie Re-Imaging und Neustarts.
  • Ein Zugriffsversuch auf neue Systeme im brasilianischen Rechenzentrum scheiterte; die Geräte wurden zur Untersuchung an den Hersteller zurückgeschickt und ersetzt.

• Analyse der Ziele der Angreifer

  • Die Analyse von Wiki-Seiten, Bug-Datenbanken und Source-Code-Repositories deutet darauf hin, dass sie nach Informationen über Cloudflares globale Netzwerkarchitektur, Sicherheit und Verwaltung suchten.

• Überraschung über Cloudflares Nutzung von BitBucket

  • Ausdruck von Überraschung darüber, dass Cloudflare BitBucket verwendet.

• Umgang mit ungenutzten Zugangsdaten

  • Bei Zugangsdaten, die als ungenutzt galten, wäre Löschen statt Rotation angemessener gewesen.

• Vorschlag zu Credential-Rotation und Honeypot nach dem Okta-Vorfall

  • Nach der Rotation kompromittierter Zugangsdaten wird vorgeschlagen, einen Honeypot einzusetzen, um das Verhalten der Angreifer zu beobachten.

• Zweifel an Zero Trust (ZT)

  • Es wird darauf hingewiesen, dass der Zugriff auf Anwendungen mit einem einzelnen Bearer-Token nicht der Definition von Zero Trust entspricht.

Hintergrundwissen: Cloudflare ist ein Unternehmen, das Internet-Sicherheitsdienste und verteilte Domain-Name-Server-Dienste anbietet, Okta bietet Identitäts- und Zugriffsmanagement-Dienste an. Zero Trust ist ein Modell der Netzwerksicherheit, bei dem grundsätzlich keinem Benutzer und keinem Gerät vertraut wird und alles verifiziert werden muss.