Cloudflare Fixes Containerversagen, die es erlaubt, Restdaten auf freigegebenen Festplatten zu lesen

Cloudflare korrigierte eine Schwachstelle in seinem Container-Service, die es einem autorisierten Client erlaubt, Restdaten von anderen Kunden Containern auf freigegebenen Festplatten zu lesen, nach dem Unternehmen und den Forschern, die den Ausfall gemeldet. Das Problem beinhaltete nicht den Zugang zu laufenden Prozessen anderer Kunden oder die Fähigkeit zu wählen, wer zu den wiederhergestellten Informationen gehört, aber es ließ Speicherblöcke mit Datei bleibt - Verzeichnisse, Datenbankseiten und komplette SQLite Basen, nach der Zählung -, dass ein Angreifer mit Zugriff auf den Container in der Lage war zu extrahieren.

Konfirmierte Tatsachen: der Forscher Oren Yomtov, der Firma Accomplish, berichtete am 4. September den Ausfall von Cloudflare; die technische Ursache war die Neukonfiguration von Festplatten im "din Provisioning" Modus (Granulat der Zuordnung in Blöcken von 64 KB), so dass, durch Rückgabe von Blöcken in den gemeinsamen Pool, das System nicht reinigen, bevor sie wiederzuordnen; Cloudflare reaktivierte die Löschung von neuen Einheiten. Die Ermittler überprüften den Patch am 14. September und bestätigten, dass ihr Konzepttest nicht mehr funktioniert.

Wie es technisch funktioniert (Erklärung): Die den Behältern zugeordneten Scheiben werden durch eine Vorrichtung des Typs Dünne Bereitstellung erzeugt, die Platz in Blöcken von 64 KB zuweist. Wenn ein Container zerstört wird, kehrten seine Blöcke in den allgemeinen Pool zurück. Durch eine Konfiguration, die beim Rücktritt von Blöcken auf die Reinigung verzichtete (Breite / Null), konnte der nächste Container, der diesen Block erhielt, nur 4 KB innerhalb der 64 KB schreiben und dann den Block auf einem Bruttoniveau lesen; der Rest der 60 KB blieb bei den Bytes des vorherigen Mieters. Die Forscher nutzten genau das: Sie schrieben ein kleines Fragment und las den gesamten Block aus der Rohblockebene, um Restdaten zurückzugewinnen. Dieser Vektor greift die unsichere Wiederverwendung von Blöcken an, nicht den heißen Speicher und die Integrität der laufenden Prozesse.

Welche Systeme und Kunden betroffen waren: Container mit Cloudflare und sein Produkt In den Warenkorb(eine Schicht, die für den unzuverlässigen Code ausgelegt ist, einschließlich IA-Agenten) wurde als betroffen identifiziert. Die Forscher merkten auch an, dass die gleiche Festplattenkonfiguration das Browser Run Produkt beeinflusste, obwohl Cloudflare nur Container und Sandboxen in seiner Veröffentlichung benannte. Cloudflare steuert die physische Zuordnung von Servern und Festplatten, so dass die Belichtung von der Seite des Lieferanten und nicht von der Wahl des Kunden kam.

Umfang von Forschern und von Cloudflare beobachtet: In kontrollierten Produktionstests erholten die Forscher Restmaterial in 18 von 24 Versuchen auf Servern ausgewählt von Cloudflare, und in 20 von 22 physischen Maschinen verteilt auf vier Kontinenten; die Reste enthalten Verzeichnisse, Browser-Profile (Chromium), .env Dateien, Anmeldedateien und SQLite Basen, nach dem Bericht der Forscher und der teilweisen Bestätigung von Cloudflare. Cloudflare sagt, dass seine internen Untersuchungen - basierend auf Signaturen, die aus dem Konzepttest erstellt wurden - nur autorisierte Aktivitäten (die von den Forschern und ihren Mitarbeitern) in den gespeicherten Aufzeichnungen gefunden haben.

Was bestätigt wird und was noch unsicher ist: Es wird bestätigt, dass es eine Restdatenbelichtung in zurückgeordneten Festplattenblöcken gab und dass Cloudflare zwei Abhilfemaßnahmen angewendet hat (die Löschung durch Zuweisung neuer Blöcke aktivieren und Discs und Caches in der Produktion ersetzen). Es ist eine vernünftige Schätzung - obwohl nicht mathematisch öffentlich bewiesen -, dass die Überreste nützliche Geheimnisse (Token, Schlüssel, Anmeldeinformationen) als .env und Datenbanken erschienen. Die Ungewissheit ist das gesamte Belichtungsfenster: Cloudflare hat nicht spezifiziert, da, wenn die unsichere Konfiguration aktiv war oder wie lange in absoluten Begriffen, so kann es nicht mit Sicherheit festgestellt werden, wie viele Kunden möglicherweise exponiert wurden oder für welchen genauen Zeitraum.

Reale Risiken für Kunden und praktische Konsequenzen: Die wiederhergestellten Informationen können Anmeldeinformationen, Tokens API, Konfigurationsgeheimnisse oder Datenbanken-Abschnitte umfassen, die spätere Angriffe ermöglichen (Wiederverwendung von Anmeldeinformationen, Out-of-Umwelt-Klettern, Zugang zu verbundenen Dienstleistungen). Obwohl es keine öffentlichen Beweise für Missbrauch von Drittanbietern gibt, kann die Kombination von teilweise wiederhergestellten Daten und automatisierten Analysemechanismen den Wiederaufbau von Geheimnissen erleichtern. Darüber hinaus kann für Organisationen, die den Regulierungs- oder Compliance-Anforderungen unterliegen, die bloße Möglichkeit der Exfiltration von Daten in einem mehrstufigen Umfeld interne Meldungen oder Überprüfungen erfordern.

Spezifische Maßnahmen, die von betroffenen oder gefährdeten Kunden getroffen werden sollen: Erstens, identifizieren Sie, ob Sie Container, Sandboxes oder Browser Run verwenden und welche Bilder oder Behälter Geheimnisse auf Festplatte oder in Bildschichten enthalten können. Dann, rollen Sie sofort alle Anmeldeinformationen, die in diesen Containern: API-Token, Datenbankschlüssel, .env-Datei-Geheimnisse und SSH-Tasten. Warten Sie nicht allein auf die Bestätigung des Lieferanten; proaktive Rotation ist eine kostengünstige Risikoaktion. Die Ablehnung von Token und die Regeneration von Anmeldeinformationen in verbundenen Diensten (Datenbanken, Cloud-Dienste, APIs von Drittanbietern) ist die direkteste Maßnahme, um möglichen Missbrauch zu mindern.

Weitere empfohlene technische Aktionen: Stoppen Sie die Speicherung von Geheimnissen im persistenten Container-Dateisystem; verwenden Sie geheimes Management (Vaults) oder geheime Managementmechanismen, die Werte in der laufenden Zeit injizieren, ohne sie auf Festplatte zu schreiben; montieren Sie Geheimnisse in Speicher (tmpfs), wenn möglich; Verschlüsseln Sie sensible Daten auf Anwendungsebene, bevor Sie diese auf Festplatte schreiben, so dass die Block-Exposition keine eindeutigen Schlüssel lesen lässt. Siehe bewährte Praktiken im Geheimmanagement: OWASP Secrets Management Cheat Sheet.

Überprüfung und Überwachung: Überprüfung von Protokollen und ungewöhnlichen Aktivitäten in den Diensten, die die betroffenen Container verwenden; Suche nach Zugang von PIs oder unerwarteten Mustern und Alarme auf anormale Schlüsselnutzung. Obwohl Cloudflare berichtete, dass sie Signatur-basierte Erkennung durchgeführt hat, ist es angebracht, ihre eigene Erkennung von Anomalien in kritischen Diensten anzuwenden und Bilder und Schichten von Containern auf der Suche nach eingebetteten Geheimnissen zu prüfen.

Zusätzlicher technischer Kontext und Referenzen: Dieses Problem ist ein Beispiel dafür, wie Leistungsoptimierung und Low-Level-Speicherkonfiguration (d.h. Bereitstellung und Layer Caching) Datenleckagevektoren in multi-Tenant-Umgebungen einführen können. Um den Thin Bereitstellungsmechanismus und seine technischen Risiken zu verstehen, siehe die Linux-Kernel-Dokumentation über Device Mapper Thin Bereitstellung: Kernel. Für praktische Anleitungen zur Verwaltung von Containergeheimnissen und zur Verringerung dieses Risikos ist die Dokumentation der guten Praxis von Plattformen und Orchestratoren nützlich (z.B. Docker und Kubernetes Praktiken und geheimes Management).

Schlussfolgerung: Cloudflare hat den erkannten Angriffsweg geschlossen und die Ressourcen in der Produktion gereinigt, und es gibt jetzt keine öffentlichen Anzeichen von Massenmißbrauch. Die Art des Ausfalls - das Lesen von Restdaten auf freigegebenen Festplatten - bedeutet jedoch, dass jeder Client, der Geheimnisse auf Bildern oder Container-Disks gehalten hat, Anmeldedaten drehen und geheime Management-Praktiken überprüfen sollte. Die operative Lektion ist klar: In mehrstufigen Umgebungen muss die Verteidigung sowohl Lieferantenkontrollen als auch strenge Entwicklerpraktiken umfassen, um Geheimnisse auf Festplatte nicht zu verlassen oder sich ausschließlich auf physische oder Hyperviewer-Sicherheit zu verlassen.

Zusätzliche Quellen und Lesen: Die Kommunikation und Nachverfolgung des Lieferanten sind auf dem Cloudflare Blog verfügbar https: / / blog.cloud, und die technische Erläuterung der dünnen Bereitstellung in Linux finden Sie in der offiziellen Dokumentation des Kernels: https: / / www.kernel.org / doc / html / aktuell / admin-guide / device-mapper / Thin-provising. html.