01.03.2017 11:49

Wir werden alle an der Cloud verbluten .. oder so

Ich bin froh, dass mein Arbeitgeber nicht an Voodoo oder böse Geister glaubt, ansonsten hätte ich meinen Arbeitsplatz wohl schon längst verloren - denn ich dürfte kein Glück bringen. Die meisten der medial grossen Schwachstellen in den letzten Jahren, die auch uns viel Arbeit bereitet haben, wurden während einer Zeitspanne veröffentlicht, in welcher ich nicht im Büro war.

Das gilt für CVE-2014-0160 ("Heartbleed") und CVE-2014-6271 ("Shellshock"), ebenso für CVE-2015-1538 ("Stagefright"), und auch folgendes erblickte ich bei einem Kaffee in meinem Wohnzimmer, anstatt an meinem Schreibtisch:

Daraus wurde, wie wir jetzt wissen, "Cloudbleed". Andere Leute mit viel mehr Erfahrung und Fachwissen als meine Wenigkeit haben bereits über die verschiedensten Aspekte (Der offizielle Bugreport, Cloudflare selbst hat einen detaillierten Blogpost verfasst, es gibt einen Bericht aus IR-Perspektive, ..) des Vorfalls geschrieben und auch die Massenmedien sind auf den Zug aufgesprungen, teilweise in einem mehr als panischen Tonfall, quasi das technische Equivalent zu "Wir werden alle sterben!".

Fraglich ist, ob das in irgendeiner Weise hilfreich ist, ganz abgesehen davon bleibt die Frage offen, ob diese Herangehensweise ob des Problems gerechtfertigt ist - insbesondere im Angesicht der vorhandenen Fakten.

Der Name 'Cloudbleed' hat viele Seiten dazu verleitet, einen Vergleich zu 'Heartbleed' herzustellen. Ganz abgesehen davon, dass es sich hierbei um zwei technisch grundverschiedene Dinge handelt (Okay, es sind beides Softwareschwachstellen.), auch in dem Auswirkungsgrad unterscheiden sie sich enorm. Während Heartbleed es ermöglichte, aktiv private Daten aus dem Speicher von Serversystemen abzusaugen, so ist Cloudbleed wesentlich subtiler.

Ein Versuch, Fakten zu sammeln

In dem oben verlinkten Incident Report schreibt Cloudflare selbst:

The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that's about 0.00003% of requests).

(Tavis Ormandy spricht von einer potentiell längeren Zeitspanne.) Auf den ersten Blick wirkt das wie ein winziger Prozentsatz, bedenkt man aber, dass die Anzahl der Requests, die Cloudflare in der Sekunde bearbeitet, wohl in die höheren Millionen geht, dann sieht das Bild schon wieder etwas anders aus.

Wiederum: Nicht jeder dieser 0.00003% geleakten Requests beinhaltet wohl sensible Daten. Statischer Content (Bilder, CSS, ..) macht einen viel grösseren Anteil aus, als beispielsweise Passwörter, welche sich vielleicht nur in jedem zehten oder hundertsten Request befinden, was das Risiko weiter minimiert. Auf der anderen Seite beinhaltet jede Anfrage an eine Seite, die Authorisierung verlangt, wohl einen entsprechenden Auth-Token. Deren Anzahl ist also, im Vergleich, wesentlich grösser.

Doch selbst, wenn die Anfragen zu der eigenen Seite nicht leaken, bedeutet das nicht, dass das nicht durch andere Seiten passiert:

Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site.

Cloudflare selbst hat versucht anhand von Caches von Suchmaschinen zu etablieren, wie viele Seiten definitiv betroffen waren:

The infosec team worked to identify URIs in search engine caches that had leaked memory and get them purged. With the help of Google, Yahoo, Bing and others, we found 770 unique URIs that had been cached and which contained leaked memory. Those 770 unique URIs covered 161 unique domains. The leaked memory has been purged with the help of the search engines.

Das ist allerdings nur ein absolutes Minimum, da Cloudflare wohl nicht die Kooperation aller Suchmaschinen hatte, und es hunderttausende 'unabhängige' Crawler gibt, die das Netz nach den verschiedensten Dingen durchforsten. Die Chancen stehen also gut, dass die 'Dunkelziffer' der Seiten, deren Requests geleakt sind, noch wesentlich höher ist.

Auf Github, Pastebin und diversen anderen Seiten finden sich Listen von Seiten welche, mal verifiziert, mal nicht, das CDN von Cloudflare nutzen und dementsprechend angeblich bedroht oder betroffen waren. Gänzlich abgesehen davon, dass manche dieser Listen von fragwürdiger Qualität sind, sagt die Verwendung von Cloudflare recht wenig über die Sensibilität der darauf gehosteten Daten aus. Es gibt genügend statische Seiten ohne jegliche Benutzereingaben, oder Seiten, die auf DNS-Ebene auf andere Seiten verweisen, die wiederum im Netz von Cloudflare sitzen.

Im Grossen und Ganzen gibt es einfach keinerlei Möglichkeit, die Auswirkungen dieser Schwachstelle mit statistisch sauber verwertbaren Daten abzuschätzen. Da wo Beispieldaten vorhanden sind, kann ein Leak nachgewiesen werden. Aber die Abwesenheit von geleakten Daten ist gleichzeitig nicht die Anwesenheit von Gewissheit oder Sicherheit. Die Anzahl an Unbekannten ist einfach viel zu gross.

Was also tun? Rational bleiben und sich nicht von etwaiger Panik anstecken lassen. Ja, der Vorfall ist auf höherer Ebene und etwas abstrakt betrachtet nicht schön und definitiv nicht zu unterschätzen, als Seitenbetreiber ist es vielleicht eine gute Idee, proaktiv alle aktiven Sessions zu invalidieren (Google hat das in direktem zeitlichen Zusammenhang mit der Veröffentlichung getan, ein Schelm wer da Böses denkt!).

Für den 'normalen' Internetnutzer ist die Gefahr, die von dieser Schwachstelle ausgeht, aber als gering einzustufen. Die Chance, sich durch veraltete Browserplugins mit Malware zu identifizieren oder sein Passwort im WLAN von Starbucks durch einen Dritten gestohlen zu sehen ist um viele Potenzen höher und realistischer. Selbst ein Lottogewinn ist (wieder: statistisch betrachtet) wesentlich wahrscheinlicher.

Natürlich ist es wie immer ein guter Anlass zu überlegen, ob man Passwörter wiederverwendet (und damit aufzuhören) und seine Sicherheitspraktiken durchzugehen. Aber wir werden nicht alle sterben. Zumindest nicht daran.

Last but not least sei mir noch ein kleiner Seitenhieb in Richtung der Twittersphäre (tm) gestattet: Wenn Mensch so viel Zeit damit verbringen würde, selbst Bugs in hochkomplexen Systemen zu suchen, beziehungsweise diese zu betreiben, anstatt Tavis Ormandy aufgrund von Kleinigkeiten zu kritisieren oder Cloudflare unreflektiert zu bashen .. die Welt wäre wohl ein besserer Ort.

Autor: Alexander Riepl