Hallo,
pcgameshardware.de war, wie auch pcgames.de und buffed.de und alle anderen ca. 4,3 Millionen Domains, die das CloudFlare-CDN nutzen, potentiell vom Leak betroffen. Da die Berichterstattung gerade mal wieder eher auf reißerische Click-Bait-Headlines als auf realistische Information abfährt, möchten wir hier betonen, dass die Wahrscheinlichkeit, dass tatsächlich irgendwelche sensiblen Informationen auch nur eines einzigen Users an Dritte gelangt und von denen auch wahrgenommen und genutzt werden konnten, extrem gering sind. Es besteht unseres Erachtens kein großartiger Anlass zu Panik.
Wir halten es dennoch für sinnvoll, den Sachverhalt an dieser Stelle genauer zu erklären, damit sich jeder ein eigenes Bild machen kann - so er denn gewillt ist, diesen doch etwas längeren Text zu lesen
Unsere Websites pcgames.de, pcgameshardware.de und buffed.de nutzen wie Millionen von anderen Seiten das Content Delivery Network (CDN) CloudFlare. Die meisten Subdomains dieser drei Sites, darunter auch
www.* und login.*, werden daher über die Server von CloudFlare geleitet, d.h. sowohl Antworten von als auch Anfragen zu unseren Sites gehen über dieses CDN. Die CDN-Server welche in direktem Kontakt mit den Clients (also dem Browser) stehen, werden als Edge-Server bezeichnet.
Am Freitag, den 17.02. wurde CloudFlare von Googles Project Zero über ein Sicherheitsproblem mit eben diesen Edge-Servern in Kenntnis gesetzt. CloudFlare konnte dieses Problem innerhalb von sieben Stunden nach Kenntnisnahme global beheben. Im Zeitraum vom 22.09.2016 bis zum 18.02.2017 konnten Antworten der Edge-Server von CloudFlare unter ganz bestimmten Umständen auch Daten völlig anderer Websites enthalten, somit möglicherweise auch Passwörter oder Session-Cookies. Die Wahrscheinlichkeit für eine solche fehlerhafte Antwort eines Edge-Servers war allerdings bis zum 13.02.2017 noch extrem gering, in der Zeit zwischen dem 13.-18.02.2017 waren dann immerhin 0,00003% aller Anfragen an CloudFlare betroffen (genauer: durchschnittlich eine von 3,3 Millionen). Da zu den Voraussetzungen für den Memory-Leak eine ganz bestimmte Seiten-Konfiguration bei CloudFlare gehörte, haben jedoch nur 3.438 Domains solche Informationen geleaked - unsere Domains waren da nicht dabei.
Unter bestimmten Umständen haben diese Server bei einer Antwort an den anfragenden Client bei einer dieser 3.438 Domains ein bisschen mehr ausgeliefert als sie sollten. Ein solches Problem bezeichnet man als Memory Leak – wenn ein Rechner nach einem bestimmten Daten-Objekt gefragt wird, dann holt er es aus seinem Hauptspeicher; üblicherweise wird der benötigte Abschnitt im Hauptspeicher welcher das gesuchte Daten-Objekt enthält über eine Anfangs-Adresse und die Länge des gewünschten Daten-Objekts angesprochen. Wenn die übergebene Länge des Daten-Objekts aus irgendeinem Grund fehlerhaft ist und eine zu große Länge angegeben wird, dann holt das Programm eben auch noch andere Daten aus dem Hauptspeicher, die mit dem eigentlich gesuchten Objekt nichts zu tun haben.
In diesem Fall konnte eine solche fehlerhafte Antwort daher auch Teile anderer Webserver-Antworten für ganz andere Webseiten, somit möglicherweise auch vollständige oder teilweise HTTP-Request-Header von anderen Sites ausliefern, die in diesem Moment gerade parallel bearbeitet wurden. In Request-Headern werden beim Login-Vorgang neben dem Ziel-Host (z.B. login.pcgames.de) auch der Nutzername und das Passwort übertragen; bei normalen Anfragen auf unsere Seiten werden Cookie-Daten vom Browser über den Edge-Server an uns geschickt, die auch die Login-Session-Info enthalten. Hat man die Zugangsdaten eines Users, so kann man sich als dieser Nutzer einloggen. Hat man das vollständige Session-Cookie, so bekommt man zwar nicht das Passwort, kann sich aber dennoch zumindest bis zum Logout für diese Session als eingeloggter User auf der betreffenden Webseite bewegen.
Dieser unerwünschte Ballast wurde dann eben irgendwo in die Antwort für eine Anfrage auf die besagten 3.438 Domains eingebaut. Nutzdaten haben natürlich einen immens höheren Anteil am Gesamt-Datenaufkommen als solche Header-Daten und es wurden eben nicht gezielt sensible Informationen geleaked, sondern einfach mehr oder weniger beliebige Fragmente von parallelen Requests, also vornehmlich Binär-Schrott von Bildern (mutmaßlich viel Pink dabei...), dazu HTML-Snippets, CSS, Javascript - aber eben potentiell auch die besagten HTTP-Header. Da das Leak-Fenster nur recht klein war, waren diese Fragmente in der Regel sicher nicht vollständige Informationseinheiten, sondern eben Bruchstücke. Mit sehr viel Pech/Glück waren da aber eben auch sensible Informationen darunter.
Die Wahrscheinlichkeit überhaupt bei einem Request an irgendwelche geleakten Daten zu kommen betrug laut CloudFlare zur Hochzeit des Problems zwischen dem 13.02.-18.0.2 1:3,3 Millionen. „Treffer“ lieferten irgendetwas zurück, nicht notwendigerweise sensible Informationen und selbst wenn sensible Informationen geliefert wurden, waren diese in der Regel kaum vollständig.
Hinzu kommt, dass CloudFlare insbesondere im von uns genutzten Business-Plan geographisch nahe Rechenzentren für die Edge-Server nutzt - in unserem Fall werden da z.B. häufig Knoten in Frankfurt genutzt. Der DACH-Raum (unser vornehmliches Einzugsgebiet, d.h. Deutschland, Österreich und die Schweiz) ist allerdings nicht der Nabel des Internets und CloudFlare arbeitet global, d.h. das CDN wird überwiegend aus dem außereuropäischen Ausland genutzt. Da daher die betroffenen 3.438 Domains mutmaßlich gleichermaßen größtenteils aus dem Ausland aufgerufen wurden, ist allein schon die Wahrscheinlichkeit, dass überhaupt ein Request auf unsere Seiten gleichzeitig mit einem Leak-Request auf die betroffenen Domains auf ein und demselben Edge-Server ausgeführt wurde, äußerst gering.
Login-Vorgänge auf unseren Webseiten sind dazu verhältnismäßig selten. Damit also ein Passwort kompromittiert werden kann, muss man sich zunächst auf einer der betroffenen 3.438 Domains bewegen, dann muss man die 1:3,3 Millionen-Hürde nehmen während exakt gleichzeitig der Login-Vorgang vom selben CloudFlare-Edge-Server bearbeitet wird UND man muss das Glück haben, dass eben dieser POST-Header für den Login-Vorgang des Users exakt neben dem Speicherbereich für die 1:3,3-Millionen-Antwort liegt UND dass von diesem auch noch alle wichtigen Teile vollständig im Leak-Bereich liegen. Für gezielte Angriffe hat sich diese Sicherheitslücke daher niemals geeignet, die Wahrscheinlichkeit gleichzeitig von einem Meteoriten und einem Blitz erschlagen zu werden während man von seinem Lotto-Gewinn erfährt, dürfte vermutlich deutlich höher sein.
Das Risiko für geleakte Session-Cookies ist etwas höher, da diese Cookies notwendigerweise bei jedem einzelnen Request vom Browser zum Server übertragen werden. Es gilt weiterhin die Einschränkung über die Wahrscheinlichkeit, dass eben der fehlerhafte Request (0,00003% Wahrscheinlichkeit) gleichzeitig auf demselben Edge-Server ausgeführt wird wie der zu kompromitierende und dass die Cookie-Header-Daten im Speicher direkt neben den Daten des fehlerhaften Requests liegen und die Cookie-Daten vollständig ins Leak-Fenster passen. Damit wäre Session-Hijacking, d.h. die Übernahme einer bestehenden Sitzung möglich, man könnte sich also bis zum Logout des Users als eben dieser eingeloggte User auf der Seite bewegen. Das Szenario ist mutmaßlich immer noch wesentlich unwahrscheinlicher als ein Lotto-Gewinn.
Einmal Aus- und wieder Einloggen schiebt dem aber zuverlässig einen Riegel vor.
Hatte man nun so einen Leak-Request erwischt und waren auch sensible Daten darin enthalten, so musste man die auch noch als solche erkennen; die Leak-Fragmente wurden irgendwo im Quelltext (genauer: zum Ende eines Buffer-Segments) eingebaut, waren daher nicht notwendigerweise im Browser sichtbar.
Es besteht ein gewisses erhöhtes Risiko durch den Umstand, dass auch Crawler-Anfragen von Google, Yahoo, Bing & Co. fehlerhaft beantwortet und dadurch sensible Daten in Web-Caches gelangt sein könnten. CloudFlare hat dies allerdings in Zusammenarbeit mit den Cache-Betreibern adressiert und versichert, dass die Fundstellen (insgesamt 770 URLs mit geleakten Snippets von 161 Domains von rund 150 CloudFlare-Kunden) inzwischen bereits beseitigt wurden. CloudFlare hat versichert, dass die betroffenen Kunden direkt kontaktiert werden. Da wir (noch?) nicht kontaktiert wurden, gehen wir derzeit davon aus, dass wir zumindest von diesem Web-Cache-Problem nicht betroffen sind. Sollte das dennoch der Fall sein, so betrifft auch das nur einen oder sehr, sehr wenige Requests, mit Sicherheit jedoch eben nicht eine größere Anzahl unserer User.
Wir hatten gestern früh als wir von dem Vorfall erfahren haben die einschlägigen Webcaches von Google, DuckDuckGo und Bing selbst nach möglichen Treffern für unsere Domains durchsucht und damit nichts gefunden. Angesichts der statistischen Wahrscheinlichkeit für einen Treffer wären wir auch wirklich sehr überrascht gewesen.
Also: Auch wenn das Thema gerade in diversen Newstickern sehr weit oben steht und einen hübsch griffigen Namen bekommen hat, handelt es sich hier nicht um eine Sicherheitslücke, über die massenhaft gezielt sensible Daten von einzelnen Seiten angreifbar waren. Das ganze ist eher vergleichbar mit einem Aktenvernichter-Unternehmen, welches ein paar Schnipsel in der Innenstadt verstreut hat - sicher nicht ideal und wir hätten uns auch sehr gewünscht, dass so etwas nicht passiert wäre, aber in aller Wahrscheinlichkeit hatte der Vorfall praktisch keine negativen Auswirkungen.
Mehr Infos gibt’s auch im CloudFlare-Blog:
Incident report on memory leak caused by Cloudflare parser bug
Viele Grüße
Markus
