Heute hat Cloudflare zusammen mit Google und Amazon AWS die Existenz einer neuartigen Zero-Day-Schwachstelle bekannt gegeben, die als „HTTP/2 Rapid Reset“-Angriff bezeichnet wird. Dieser Angriff nutzt eine Schwachstelle im HTTP/2-Protokoll aus, um enorme, hypervolumetrische Distributed Denial of Service (DDoS)-Angriffe zu generieren. Cloudflare hat in den letzten Monaten eine Flut dieser Angriffe abgewehrt, einschließlich eines Angriffs, der dreimal so groß war wie der größte Angriff, den wir bisher jemals verzeichnet hatten, und der 201 Millionen Anfragen pro Sekunde (rps) überstieg. Seit Ende August 2023 hat Cloudflare mehr als 1.100 weitere Angriffe mit über 10 Millionen rps abgewehrt – und 184 Angriffe, die unseren bisherigen DDoS-Rekord von 71 Millionen rps übertrafen.

Sie werden angegriffen oder benötigen zusätzlichen Schutz? Klicken Sie hier, um Hilfe zu erhalten.

Diese Zero-Day-Schwachstelle gab den Bedrohungsakteuren ein wichtiges neues Werkzeug in ihrem Werkzeugkasten an Schwachstellen an die Hand, mit dem sie ihre Opfer in einem noch nie dagewesenen Ausmaß ausnutzen und angreifen können. Diese Angriffe waren mitunter komplex und schwierig zu bekämpfen. Cloudflare bot sich dadurch jedoch die Gelegenheit, eine speziell konzipierte Technologie zu entwickeln, um die Auswirkungen der Zero-Day-Schwachstelle abzuwehren.

Wenn Sie Cloudflare für die HTTP-DDoS-Abwehr nutzen, sind Sie geschützt. Im Folgenden finden Sie weitere Informationen zu dieser Sicherheitslücke sowie Ressourcen und Empfehlungen, was Sie tun können, um sich zu schützen.

Alle Einzelheiten zum Angriff: Was jeder CSO wissen muss

Ende August 2023 entdeckte unser Team bei Cloudflare eine neue Zero-Day-Sicherheitslücke, die von einem unbekannten Bedrohungsakteur entwickelt wurde und das Standard-HTTP/2-Protokoll ausnutzt – ein grundlegendes Protokoll, das entscheidend dafür ist, wie das Internet und alle Websites funktionieren. Dieser neuartige Angriff auf eine Zero-Day-Sicherheitslücke namens „Rapid Reset“ nutzt die Stream-Abbruchfunktion von HTTP/2 aus, indem er eine Anfrage sendet und diese sofort wieder abbricht.  

Durch die Automatisierung dieses trivialen Musters von „Anfrage, Abbruch, Anfrage, Abbruch“-Musters im großen Stil sind Bedrohungsakteure in der Lage, eine Denial-of-Service-Situation herbeizuführen und jeden Server oder jede Anwendung, auf dem/der die Standardimplementierung von HTTP/2 läuft, lahmzulegen. Ein wichtiger Aspekt des Rekordangriffs ist die Tatsache, dass es sich um ein Botnetz von bescheidener Größe handelte, das aus etwa 20.000 Rechnern bestand. Cloudflare entdeckt regelmäßig Botnets, die um Größenordnungen größer sind als diese – sie bestehen aus Hunderttausenden und sogar Millionen von Rechnern. Die Tatsache, dass ein relativ kleines Botnet eine so große Menge an Anfragen ausgeben kann, die das Potenzial haben, nahezu jeden Server oder jede Anwendung, die HTTP/2 unterstützt, lahmzulegen, unterstreicht, wie bedrohlich diese Sicherheitslücke für ungeschützte Netzwerke ist.

Bedrohungsakteure nutzten Botnets in Verbindung mit der HTTP/2-Schwachstelle, um Anfragen in einem noch nie dagewesenen Ausmaß zu verstärken. Infolgedessen erlebte unser Team bei Cloudflare eine zeitweilige Instabilität der Edge. Obwohl unsere Systeme die meisten eingehenden Angriffe abwehren konnten, überlastete das Volumen einige Komponenten in unserem Netzwerk und beeinträchtigte die Performance einer kleinen Anzahl von Kunden mit zeitweiligen 4xx- und 5xx-Fehlern, die alle schnell behoben werden konnten.

Nachdem wir diese Probleme erfolgreich abgewehrt und potenzielle Angriffe für alle Kunden gestoppt hatten, leitete unser Team sofort einen Prozess zur verantwortungsvollen Offenlegung ein. Wir haben Gespräche mit Branchenkollegen aufgenommen, um herauszufinden, wie wir zusammenarbeiten können, um unser Ziel voranzubringen und den großen Anteil des Internets zu schützen, der auf unser Netzwerk angewiesen ist, bevor wir diese Schwachstelle der Öffentlichkeit bekannt geben.

Auf die technischen Details des Angriffs gehen wir in einem separaten Blogartikel näher ein: Alle Einzelheiten über HTTP/2 Rapid Reset.

Wie wehren Cloudflare und die Branche diesen Angriff ab?

Eine „perfekte Offenlegung“ gibt es nicht. Die Bekämpfung von Angriffen und die Reaktion auf neue Vorfälle erfordert von Unternehmen und Sicherheitsteams eine Denkweise, die einen Datenverstoß annimmt – denn es wird immer wieder neue Zero-Day-Angriffe, neue Gruppen von Bedrohungsakteuren und noch nie dagewesene neue Angriffe und Techniken geben.

Diese Denkweise ist eine wichtige Grundlage für den Informationsaustausch und gewährleistet in Fällen wie diesem, dass das Internet sicher bleibt. Während Cloudflare diese Angriffe verzeichnete und abwehrte, arbeiteten wir auch mit Branchenpartnern zusammen, um zu gewährleisten, dass die Branche als Ganzes diesem Angriff standhalten konnte.  

Im Zuge der Abwehr dieses Angriffs entwickelte unser Cloudflare-Team eine neue Technologie, um diese DDoS-Angriffe zu stoppen und unsere eigenen Abwehrmaßnahmen für diesen und andere zukünftige Angriffe großen Ausmaßes weiter zu verbessern. Diese Bemühungen haben unsere allgemeinen Abwehrmöglichkeiten und unsere Ausfallsicherheit insgesamt erheblich verbessert. Wenn Sie Cloudflare verwenden, sind wir sicher, dass Sie geschützt sind.

Unser Team hat auch Webserver-Softwarepartner benachrichtigt, die Patches entwickeln, um sicherzustellen, dass diese Sicherheitslücke nicht ausgenutzt werden kann – weitere Informationen finden Sie auf deren Websites.

Die Offenlegung ist nie ein Selbstläufer. Die Hauptaufgabe von Cloudflare ist es, für ein besseres Internet zu sorgen – genau das erreichen Fälle wie diese. Wenn wir die Möglichkeit haben, mit unseren Branchenpartnern und Behörden zusammenzuarbeiten, um sicherzustellen, dass es keine weitreichenden Auswirkungen auf das Internet gibt, tragen wir dazu bei, die Ausfallsicherheit jedes Unternehmens zu erhöhen, unabhängig von dessen Größe oder Branche.

Um ein besseres Verständnis der Abwehrtaktiken und der nächsten Schritte beim Patching erfahren möchten, registrieren Sie sich für unser Webinar.

Was sind die Ursprünge des HTTP/2 Rapid Reset und dieser rekordverdächtigen Angriffe auf Cloudflare?

Es mag seltsam erscheinen, dass Cloudflare eines der ersten Unternehmen war, das von diesen Angriffen betroffen war. Warum sollten Bedrohungsakteure ein Unternehmen angreifen, das über einige der weltweit robustesten Abwehrmechanismen gegen DDoS-Angriffe verfügt?  

Tatsächlich verzeichnet Cloudflare Angriffe oft, bevor sie auf anfälligere Ziele gerichtet werden. Bedrohungsakteure müssen ihre Tools entwickeln und testen, bevor sie sie in freier Wildbahn einsetzen. Bedrohungsakteure, die über rekordverdächtige Angriffsmethoden verfügen, können nur schwer testen und nachvollziehen, wie groß und effektiv sie sind, da sie nicht über die Infrastruktur verfügen, um die Angriffe, die sie starten, aufzufangen. Aufgrund der Transparenz, die wir in Bezug auf unsere Netzwerk-Performance bieten, und der Messungen der Angriffe, die sie aus unseren öffentlichen Performance-Diagrammen ablesen konnten, nahm dieser Bedrohungsakteur wahrscheinlich uns ins Visier, um das Potenzial des Exploits zu verstehen.

Aber diese Tests und die Möglichkeit, Angriffe frühzeitig zu erkennen, helfen uns, Abwehrmaßnahmen zu entwickeln, die sowohl unseren Kunden als auch der gesamten Branche zugute kommen.

Von CSO zu CSO: Was sollten Sie tun?

Ich bin seit über 20 Jahren CSO und habe unzählige Offenlegungen und Ankündigungen wie diese miterlebt. Aber ob Log4J, Solarwinds, EternalBlue WannaCry/NotPetya, Heartbleed, oder Shellshock, alle diese Sicherheitsvorfälle haben etwas gemeinsam. Eine gewaltige Explosion, die sich über die ganze Welt ausbreitet und die Gelegenheit bietet, alle von mir geleiteten Organisationen völlig aus dem Gleichgewicht zu bringen – unabhängig von der Branche oder der Größe.

Viele davon waren Angriffe oder Schwachstellen, die wir möglicherweise nicht kontrollieren konnten. Aber unabhängig davon, ob das Problem durch etwas entstanden ist, das in meinem Einflussbereich lag oder nicht: Was jede erfolgreiche Initiative, die ich geleitet habe, von denen unterschied, die nicht zu unseren Gunsten ausfielen, war die Fähigkeit, rasch zu reagieren, wenn Zero-Day-Schwachstellen und Exploits wie diese entdeckt wurden.    

Ich wünschte, ich könnte sagen, dass es bei Rapid Reset diesmal anders sein könnte, aber das ist nicht der Fall. Ich rufe alle CSOs auf – ganz gleich, ob Sie die jahrzehntelangen Sicherheitsvorfälle miterlebt haben, die ich erlebt habe, oder ob dies Ihr erster Tag im Job ist – jetzt ist der richtige Zeitpunkt, um sicherzustellen, dass Sie geschützt sind, und Ihr Team zur Vorfallsreaktion aufzustellen.

Wir haben die Informationen bis heute unter Verschluss gehalten, um möglichst vielen Sicherheitsanbietern die Möglichkeit zu geben, zu reagieren. Irgendwann ist es jedoch verantwortungsvoll, Zero-Day-Bedrohungen wie diese bekannt zu machen. Heute ist es soweit. Das bedeutet, dass die Bedrohungsakteure nach dem heutigen Tag weitgehend über die HTTP/2-Schwachstelle Bescheid wissen werden; und es wird unweigerlich trivial werden, sie auszunutzen. Dadurch beginnt der Wettlauf zwischen Verteidigern und Angreifern – patcht das Unternehmen schneller – oder werden die Angreifer noch schneller zuschlagen? Unternehmen sollten davon ausgehen, dass die Systeme getestet werden, und proaktive Maßnahmen ergreifen, um den Schutz zu gewährleisten.

Für mich erinnert dies an eine Schwachstelle wie Log4J, da täglich zahlreiche Varianten auftauchen und in den kommenden Wochen, Monaten und Jahren noch weitere hinzukommen werden. Wenn mehr Forscher und Bedrohungsakteure mit der Schwachstelle experimentieren, werden wir möglicherweise verschiedene Varianten mit noch kürzeren Ausnutzungszyklen finden, die noch fortschrittlichere Umgehungen enthalten.  

Und genau wie bei Log4J ist die Bewältigung solcher Vorfälle nicht einfach mit der Ausführung eines Patches zu bewerkstelligen. Sie müssen das Störfallmanagement, das Patchen und die Weiterentwicklung Ihrer Sicherheitsvorkehrungen zu kontinuierlichen Prozessen machen – denn die Patches für jede Variante einer Schwachstelle verringern Ihr Risiko, aber sie beseitigen es nicht.

Ich will keine Panikmache betreiben, aber ich sage es ganz direkt: Sie müssen das ernst nehmen. Behandeln Sie dies als aktiven Vorfall, um sicherzustellen, dass Ihrem Unternehmen nichts passiert.

Empfehlungen für einen neuen Veränderungsprozess

Kein Sicherheitsvorfall gleicht dem anderen, aber es gibt Lehren, die man daraus ziehen kann. Werte CSOs: Hier sind meine Empfehlungen, die sofort umgesetzt werden müssen. Nicht nur in diesem Fall, sondern auch in den kommenden Jahren:

• Machen Sie sich mit der externen Konnektivität Ihres externen Netzwerks und des Netzwerks Ihrer Partner vertraut, um alle Systeme, die mit dem Internet verbunden sind, mit den nachstehenden Abwehrmaßnahmen zu schützen.
• Machen Sie sich ein Bild von Ihrem bestehenden Sicherheitsschutz und den Möglichkeiten, die Sie zum Schutz, zur Erkennung und zur Reaktion auf einen Angriff haben, und beheben Sie sofort alle Probleme in Ihrem Netzwerk.
• Stellen Sie sicher, dass sich Ihr DDoS-Schutz außerhalb Ihres Rechenzentrums befindet, denn wenn der Traffic in Ihr Rechenzentrum gelangt, wird es schwierig sein, den DDoS-Angriff abzuwehren.
• Stellen Sie sicher, dass Sie über DDoS-Schutz für Anwendungen (Layer 7) und über Web Application Firewalls verfügen. Stellen Sie außerdem sicher, dass Sie über einen vollständigen DDoS-Schutz für DNS, Netzwerk-Traffic (Layer 3) und API-Firewalls verfügen, um eine optimale Vorgehensweise zu gewährleisten.
• Stellen Sie sicher, dass Webserver- und Betriebssystem-Patches auf allen internetfähigen Webservern installiert sind. Stellen Sie außerdem sicher, dass alle Automatisierungen wie Terraform-Builds und -Images vollständig gepatcht sind, damit ältere Versionen von Webservern nicht versehentlich über die sicheren Images in der Produktion eingesetzt werden.
• Als letzten Ausweg können Sie HTTP/2 und HTTP/3 (wahrscheinlich ebenfalls anfällig) deaktivieren, um die Bedrohung abzuwehren. Dies ist nur ein letzter Ausweg, da es zu erheblichen Performance-Problemen kommen wird, wenn Sie auf HTTP/1.1 zurückstufen.
• Ziehen Sie einen sekundären, cloudbasierten DDoS-L7-Anbieter am Perimeter in Betracht, um die Ausfallsicherheit zu erhöhen.

Cloudflare hat es sich zur Aufgabe gemacht, ein besseres Internet zu schaffen. Wenn Sie mit Ihrem aktuellen DDoS-Schutz nicht zufrieden sind, stellen wir Ihnen gerne kostenlos unsere DDoS-Fähigkeiten und Ausfallsicherheit zur Verfügung, um alle Versuche eines erfolgreichen DDoS-Angriffs abzuwehren. Wir kennen den Stress, dem Sie ausgesetzt sind, denn wir haben diese Angriffe in den letzten 30 Tagen abgewehrt und unsere ohnehin schon erstklassigen Systeme noch weiter verbessert.

Wenn Sie mehr erfahren möchten, sehen Sie sich unser Webinar an. Darin erfahren Sie mehr über den Zero-Day und wie Sie darauf reagieren können. Kontaktieren Sie uns, wenn Sie sich nicht sicher sind, ob Sie geschützt sind, oder wenn Sie wissen möchten, wie Sie sich schützen können. Weitere technische Details zu dem Angriff finden Sie in einem eigenen Blogbeitrag: Alle Einzelheiten über HTTP/2 Rapid Reset. Noch etwas: Falls Sie angegriffen werden oder sofortigen Schutz benötigen, wenden Sie sich bitte an einen unserer Cloudflare-Mitarbeitenden vor Ort oder besuchen Sie https://www.cloudflare.com/de-de/under-attack-hotline/.

Via Cloudflare.com