Tavis Ormandy von Googles Project Zero hatte vor einer Woche eine massive Sicherheitslücke bei Cloudflare entdeckt.

Cloudflare ist ein Denial-of-Service-(DoS-)Protection- und Content-Delivery-Network (CDN), ein Dienstleister, der zwischen der eigentlichen Website und dem Besucher sitzt und damit zum Beispiel die Website vor DDoS-Überlastungsangriffen schützen kann. Gefühlt das halbe World Wide Web verwendet Cloudflare (und gibt somit seine Dezentralität und Unabhängigkeit auf und erschwert außerdem Nutzern des anonymisierenden Tor-Netzwerks den Zugriff), Cloudflare nennt fünf Millionen Websites als Kunden.

Tavis Ormandy schrieb im Project-Zero-Bugtracker:

I didn’t realize how much of the internet was sitting behind a Cloudflare CDN until this incident. […] I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.

(Hervorhebungen von mir.)

Zur Erklärung, was Ursache sein könnte, schrieb Ormandy:

It looked like that if an html page hosted behind cloudflare had a specific combination of unbalanced tags, the proxy would intersperse pages of uninitialized memory into the output (kinda like heartbleed, but cloudflare specific and worse for reasons I’ll explain later). My working theory was that this was related to their “ScrapeShield” feature which parses and obfuscates html – but because reverse proxies are shared between customers, it would affect all Cloudflare customers.

Cloudflare erklärt die Ursache ausführlich in einem Blogpost:

[…] three minor Cloudflare features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) that were all using the same HTML parser chain that was causing the leakage.

Es wird in dem Posting sogar etwas Ragel-Parser- und C-Code gezeigt. (Manchmal fehlt mir da allerdings etwas Kontext: fhold? Warum sind die verwendeten Buffer im Nginx-Modul unterschiedlich, speziell der Wert der Variable last_buf, je nachdem ob zum alten Ragel-Parser der neue cf-html-Parser dazukommt oder nicht?)

Das Problem entstand durch – meiner Meinung nach unnötige – HTML verändernde Features von Cloudflare, die mit Cloudflares eigentlichen, wichtigen Diensten wie DDoS-Abwehr oder vielleicht auch noch Geschwindigkeitsverbesserungen durch das CDN nichts zu tun haben. Wenn beispielsweise eine Website die auf ihr genannten E-Mail-Adressen zum Schutz vor Spammern verschleiern möchte, dann sollte das die ursprüngliche Website machen und nicht Cloudflare als »Man in the Middle«.

Einige Websites nutzen diese Zusatzfeatures von Cloudflare, bei denen HTML umgeschrieben wird. Wenn weitere Bedinungen zutrafen, konkret eine Webseite mit bestimmten HTML-Start-Tags und deren Attributen (ohne Werten) endet, dann konnten durch den Fehler andere Buffer im Speicher des Cloudflare-Webservers gelesen und in die ausgelieferte veränderte Webseite geschrieben werden. Dabei konnten das beliebige Daten von auch völlig anderen Cloudflare-nutzenden Websites sein, die gerade zufällig im Speicher waren. Es half nicht einmal, wenn die Websites HTTPS-Verschlüsselung nutzten, denn Cloudflare sitzt für das HTML-Parsen ja als »Man in the Middle« dazwischen und verwendet bei sich lokal unverschlüsselte Daten.

Nicht nur Google hat mit seiner Suchmaschine jede Menge der durch Cloudflare geleckten Daten gespeichert (und nach der Entdeckung gelöscht), sondern jeder Webcrawler und auch normale Nutzer, die von Cloudflare ausgelieferte Websites abspeichern, könnten solche Daten haben.

Fazit

Von der im April 2014 bekanntgewordenen Heartbleed-Sicherheitslücke in OpenSSL war auch mindestens das halbe Internet betroffen. Wenn eine bestimmte Software oder Infrastruktur großflächig verwendet wird, dann betrifft ein Fehler darin auch sehr viele Nutzer.

Im Falle von Cloudflare ist es aber gar nicht notwendig, daß so viele Websites diesen »Man in the Middle« verwenden – es reicht, wenn man im Falle eines Denial-of-Service-Angriffs unter dessen Schutzschild schlüpft, und auch dann gibt es noch mehrere Alternativen. Und einmal mehr – ähnlich wie bei Heartbleed mit der Heartbeat-Erweiterung für TLS/DTLS – sind eigentlich unnötige, sekundäre Features Grund für eine Sicherheitslücke.

Ein Internetnutzer hat allerdings keine Chance, sich gegen diese Sicherheitslücken in der Infrastruktur – ob sie nun zentral oder dezentral angelegt ist – zu schützen. Im konkreten Fall war man zum Beispiel etwas weniger betroffen, wenn man seine Kennwörter in einem lokalen Paßwortmanager gespeichert hat und nicht in »der Cloud« (bei einem Cloudflare-nutzenden Dienst). Aber auf Kommunikation und Datenaustausch, Websites und Apps wird man nicht allgemein verzichten wollen; egal ob die hinter Cloudflare oder anderen Anbietern oder anderer mehr oder weniger sicherer Software laufen oder nicht.

Nachtrag vom 2017-03-03: Wie eine veränderte HTML-Seite mit fremden Speicherinhalt an deren Ende ausgesehen haben kann, zeigt ein Screenshot im Cloudflare-Blog-Eintrag Quantifying the Impact of “Cloudbleed”. Dort wird auch noch einmal der Fehler schnell erklärt und dann analysiert, wie verbreitet und gefährlich er war und ob er absichtlich ausgenutzt wurde.