Cloudbleed: Cloudflare verlor Daten

Cloudflare ist ein Content Delivery Network mit Millionen von Kunden. Durch einen Fehler in den Reverse Proxies sind nun sensible Daten geleakt. Per Zufall stieß Google-Mitarbeiter Tavis Ormandy von Project Zero auf das Leck, das jedoch schnell gestopft werden konnte.

Googles Project Zero sucht unter anderem mit Hilfe von Fuzzing nach Fehlern in Software, um so potenzielle Zero-Day-Exploits zu entdecken und die Lücken zu stopfen. Um den Fuzzer zu optimieren, greifen die Entwickler dazu auch auf öffentlich verfügbare Datensammlungen zurück. Dabei stießen sie auf eine ungewöhnliche Daten, die zu Teilen von nicht initialisiertem Speicher stammten, gemischt mit validen Daten.

Wie die Forscher des Projekts dann heraus fanden, stammten die geleakten Speicherdaten von einem Reverse Proxy von Cloudflare. Dieser spuckte sie jedes Mal unabsichtlich aus, wenn User HTML-Seiten mit bestimmten kaputten Tags anforderten. Dabei leakten auch Informationen anderer User, da sich mehrere Kunden diese Reverse Proxies teilen. Zu den Kunden von Cloudflare gehören OK Cupid, Digital Ocean, aber auch Subdomains des Bundestags. Eine Übersicht der Kunden bietet eine Github-Seite, allerdings dürfte nur ein Teil davon von Cloudbleed betroffen gewesen sein.

Konkret stießen die Forscher auf Cookies, Passwörter, Encryption Keys, POST-Daten sowie HTTPS-Anfragen an andere Seiten, die Cloudflare hostet. Auch private Nachrichten auf Dating-Websites, sowie Informationen zu konkreten Personen und Gesundheitsdaten waren darunter. Einige Suchmaschinen hatten die Daten bereits gecacht. Da ihn das Szenario an Heartbleed erinnerte, schrieb Tavis Ormandy zu Beginn seiner Schilderung: “Es kostete allergrößte Anstrengungen, das Problem nicht als Cloudbleed zu bezeichnen.” Im Gegensatz zu Heartbleed dürfte sich der Schaden allerdings in recht überschaubaren Grenzen halten, weil der Bug nicht so tief im System steckt und “nur” Cloudflare betrifft.

Die Admins des Unternehmens reagierten zunächst schnell auf die Meldung, Cloudflare brauchte aber eine Weile, um ein offizielles Statement zu dem Vorfall zu veröffentlichen, das laut Ormandy aber einige Sicherheitsrisiken für die Kunden herunterspielt.

Demnach rief der interne Ragel-Parser im Zusammenspiel mit einem neu konfigurierten Puffer das Leak hervor. Der Parser wandelt unverschlüsselten HTTP-Traffic nachträglich in verschlüsselten um. Dieses Feature deaktivierte Cloudflare ebenso wie die Email Obfuscation und serverseitige Excludes, was die Leaks stoppte. Deren größte Auswirkungen zeigten sich zwischen dem 13. und 18. Februar, wobei etwa eine von 3 Millionen HTTP-Requests ein Memory-Leak hervorrief.

Der konkrete Code, der dem Bug zugrunde lag, steckte im C-Code des Ragel-Parsers. Ein Pointer konnte fälschlich über das Ende des Puffers hinaus schreiben, technische Details liefert der Blogpost von Cloudflare.

E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Nach oben