- Während das Ausmaß von DDoS-Angriffen schnell zunimmt, hat Google im August 2023 einen Angriff mit einem Spitzenwert von 398 Millionen rps abgewehrt, der 7,5-mal größer war als der Rekord des Vorjahres von 46 Millionen rps
- Die Angreifer nutzten die Rapid Reset-Technik, die Stream-Multiplexing in HTTP/2 ausnutzt, und mehrere Unternehmen der Internet-Infrastruktur waren betroffen
- Die Angriffswelle begann Ende August 2023 und setzte sich bis in den September fort; zu den Zielen gehörten wichtige Infrastrukturanbieter, darunter Google-Dienste, die Google-Cloud-Infrastruktur und Kunden
- Google absorbierte den Angriff am Netzwerk-Edge und aktualisierte seine Abwehrsysteme; auch Kunden von Application Load Balancer und Cloud Armor profitieren vom Schutz auf derselben Grundlage
- Server, Proxys, Anwendungsserver und Load Balancer mit HTTP/2-Unterstützung können von CVE-2023-44487 betroffen sein; daher sind eine Prüfung auf Verwundbarkeit und das Einspielen von Hersteller-Patches erforderlich
Ausmaß des Angriffs und die Rapid-Reset-Technik
- Googles DDoS Response Team hat in den vergangenen Jahren einen exponentiellen Anstieg beim Ausmaß von DDoS-Angriffen festgestellt
- Der im August 2023 abgewehrte Angriff war 7,5-mal größer als der bisherige Höchstwert des Vorjahres
- Er erreichte einen Spitzenwert von 398 Millionen requests per second (rps)
- Der bis dahin größte DDoS-Angriff, der 2022 verzeichnet wurde, lag bei 46 Millionen rps
- Der zwei Minuten andauernde Angriff erzeugte mehr Anfragen als Wikipedia im gesamten September 2023 an Seitenaufrufen meldete
- Die zentrale Technik war das neue HTTP/2 Rapid Reset, das die Stream-Multiplexing-Funktion von HTTP/2 ausnutzt
Ziele des Angriffs und Auswirkungen auf Dienste
- Die jüngste Angriffswelle begann Ende August 2023 und wurde den gesamten September über weiter beobachtet
- Zu den Angriffszielen gehörten wichtige Infrastrukturanbieter
- Google-Dienste
- Google-Cloud-Infrastruktur
- Google-Kunden
- Google hielt seine Dienste mithilfe globaler Load-Balancing- und DDoS-Mitigation-Infrastruktur weiter in Betrieb
- In Zusammenarbeit mit Branchenpartnern wurde der Angriffsmechanismus analysiert und Gegenmaßnahmen zum Schutz von Google, seinen Kunden und dem Internet insgesamt abgestimmt
Googles Mitigation und Schutz für Cloud-Kunden
- Die Untersuchung ergab, dass der Angriff die Rapid-Reset-Technik nutzte, die die Stream-Multiplexing-Funktion des weit verbreiteten HTTP/2-Protokolls ausnutzt
- Google mitigierte den Angriff am Netzwerk-Edge
- Dank Investitionen in Edge-Kapazitäten blieben Google-Dienste und Kundendienste weitgehend unbeeinträchtigt
- Nach weiterer Analyse der Angriffsmethode wurden Gegenmaßnahmen entwickelt
- Durch Updates an Proxys und Systemen zur Abwehr von Denial-of-Service-Angriffen konnte diese Technik wirksam eingedämmt werden
- Der Application Load Balancer und Cloud Armor von Google Cloud verwenden dieselbe Hardware- und Software-Infrastruktur, die Google auch für eigene internetseitige Dienste einsetzt
- Internetseitige Web-Apps und Dienste von Cloud-Kunden, die diese Produkte nutzen, erhalten daher einen vergleichbaren Schutz
CVE-2023-44487 und die gemeinsame Reaktion der Branche
- Unmittelbar nachdem Google die ersten Angriffe im August erkannt hatte, wurden zusätzliche Mitigationsstrategien angewendet und eine branchenweite gemeinsame Reaktion mit Cloud-Anbietern und Software-Maintainern koordiniert, die den HTTP/2-Protokoll-Stack implementieren
- Während der laufenden Angriffe wurden Angriffsdetails und Mitigationsmethoden in Echtzeit geteilt
- Diese Zusammenarbeit führte zu Patches und Mitigationstechniken, die von mehreren großen Infrastrukturanbietern eingesetzt werden
- Die neue Angriffsmethode sowie potenzielle Schwachstellen in verschiedenen verbreiteten Open-Source- und kommerziellen Proxys, Anwendungsservern und Load Balancern wurden im Rahmen einer koordinierten Offenlegung veröffentlicht
- Die kollektive Schwachstelle für diesen Angriff wird unter CVE-2023-44487 geführt
- Schweregrad: High
- CVSS-Score: 7.5/10
Betroffene Systeme und erforderliche Maßnahmen
- Unternehmen und Einzelpersonen, die HTTP-basierte Workloads im Internet bereitstellen, können dem Risiko dieses Angriffs ausgesetzt sein
- Webanwendungen, Dienste und APIs auf Servern oder Proxys, die über HTTP/2 kommunizieren können, können verwundbar sein
- Organisationen sollten prüfen, ob ihre Server mit HTTP/2-Unterstützung nicht verwundbar sind
- Wer eigene Server mit HTTP/2-Unterstützung betreibt oder verwaltet, sollte einschlägige Hersteller-Patches unabhängig davon, ob es sich um Open Source oder kommerzielle Software handelt, sofort nach Verfügbarkeit einspielen
- Hersteller-Patches für CVE-2023-44487 sind Maßnahmen, um die Auswirkungen dieses Angriffsvektors zu begrenzen
Empfehlungen zur Abwehr in Google-Cloud-Umgebungen
- Die Abwehr groß angelegter DDoS-Angriffe ist schwierig, und um Dienste auch bei Angriffen mittlerer Größe oder größer unabhängig vom Patch-Status weiter betreiben zu können, sind erhebliche Infrastrukturinvestitionen erforderlich
- Organisationen, die Dienste auf Google Cloud betreiben, können ihre Anwendungen mit den global skalierten Kapazitätsinvestitionen von Cross-Cloud Network bereitstellen und schützen
- Google-Cloud-Kunden, die ihre Dienste über globale oder regionale Application Load Balancer veröffentlichen, sind durch Cloud Armor always-on DDoS protection geschützt
- Angriffe, die Schwachstellen wie CVE-2023-44487 ausnutzen, werden schnell mitigiert
- Auch wenn Cloud Armor always-on DDoS protection am Netzwerk-Edge von Google die meisten Anfragen in Höhe von Hunderten Millionen pro Sekunde absorbieren kann, können weiterhin mehrere Millionen unerwünschte Anfragen pro Sekunde durchkommen
- Für die Abwehr von Layer-7-Angriffen werden Cloud Armor custom security policies, proaktive Regeln für rate limiting und der Einsatz der KI-basierten Adaptive Protection empfohlen
- Technische Informationen zur aktuellen DDoS-Angriffswelle finden sich in der Analyse des HTTP/2 Rapid Reset DDoS-Angriffs
1 Kommentare
Meinungen auf Hacker News
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
Trotzdem verstehe ich nicht ganz, warum das immer wieder passiert, wenn das Ergebnis nur darin besteht, US-Tech-Unternehmen und ihre Kunden für ein paar Stunden zu stören.
Mit diesem Ruf lassen sie sich von weniger sauberen Auftraggebern bezahlen, die Konkurrenten angreifen wollen; manchmal ist dieser Auftraggeber eine Regierung, manchmal ein zwielichtiges Unternehmen. Im letzten Jahr gab es viele Fälle, in denen Krypto-Unternehmen gegenseitig ihre Websites angegriffen haben.
Die Leute, die so etwas tun, sind technisch sehr stark, haben aber aufgrund ihres Wohnorts oder ihres Umfelds oft nur wenige Möglichkeiten, mit diesen Fähigkeiten Geld zu verdienen.
Fortgeschrittene Angreifer testen dagegen Fähigkeiten und Reaktionen. Die Taliban haben früher Kinder dafür bezahlt, außerhalb von Stützpunkten Feuerwerkskörper zu zünden, um Verteidigungstaktiken, -techniken und -verfahren zu beobachten; außerdem hatte es den Effekt, dass man gegenüber Schüssen abstumpfte.
Ein wirklich guter Gegner kann Letzteres tun und es wie Ersteres aussehen lassen.
Beim Mirai-Botnet betrieben einige der Entwickler auch ein Unternehmen für DDoS-Mitigation. Sie verkauften also auf der einen Seite die Waffe und auf der anderen Seite die Verteidigung dagegen.
Manchmal sind auch Reputation, Streiche oder die Herausforderung, ein Botnet zu bauen, die Motivation.
Ob es nun um Internetinfrastruktur im großen Stil geht oder um Angriffe auf ein bestimmtes Unternehmen: Ich frage mich, ob jemand, der an solchen Angriffen beteiligt war, mutig oder verrückt genug wäre, einen Wegwerf-Account zu erstellen und seine Motivation zu erklären.
Sie wollten die Zielseite nicht unbedingt verlangsamen, aber sie versuchten, Daten mit einer Geschwindigkeit abzugreifen, bei der die Serverkosten für echte zahlende Kunden nicht mehr tragbar waren.
Solche Angriffe unterscheiden sich von echten DDoS-Angriffen, sind meiner Erfahrung nach aber viel häufiger und lassen sich mit Diensten wie Cloudflare oder Akamai relativ leicht abmildern; das empfehle ich Kunden dann auch.
Sind Leute von Cloudflare, Google und AWS in einer Echtzeit-Videokonferenz, koordinieren sich und mitigieren gemeinsam, oder beobachten alle aus der Ferne, was anderswo passiert, und konzentrieren sich darauf, ihr eigenes Problem zu lösen?
In diesem Fall haben alle erkannt, dass sie dasselbe sehen, und da die Auswirkungen auf kleinere Ziele sehr groß sein können, haben sie das Problem gemeinsam verstanden und die Sicherheitsreaktion mit allen Webserver-Anbietern koordiniert.
Geht es nur darum, genügend eingehende Bandbreite bereitzustellen, damit man ein paar Gb/s aushält und noch Reservekapazität für legitimen Traffic bleibt?
Viel DDoS-Traffic ist kein echtes HTTP, sondern Müll-Traffic, der die Leitung in Richtung einer IP-Adresse füllt. Größere Leitungen und mehrere geografisch verteilte Server helfen dabei. Es gibt auch Fälle wie TCP-SYN-Floods, bei denen nur TCP-Verbindungen geöffnet werden, um verfügbare Ports zu erschöpfen. Solche anomalen Requests lassen sich oft mit mehreren einfachen Reverse Proxys vor dem Server abfangen
Ausgefeiltere Anfragen, die nach außen wie normaler HTTP-Traffic aussehen, müssen letztlich verarbeitet werden. Etwa indem man aus dem Cache antwortet, ein CAPTCHA einfügt, um Angreifer auszubremsen und legitimen Traffic zu erkennen, oder Rate Limiting anwendet. Man möchte erkennen, ob ein Request legitim ist, bevor man ihn an den eigentlichen Server weiterleitet, und dafür lassen sich verschiedene Tools einsetzen
Der Server kann so konfiguriert werden, dass er alles verwirft, was nicht von Cloudflare kommt; das ist effizient
Im Allgemeinen ist Googles interner Traffic zwischen Rechenzentren viel größer als die Menge, die jemand per DDoS schicken könnte, sodass sich immer ein Weg findet, ihn zu bewältigen
Aber nicht jeder DDoS ist volumenbasiert. Manche missbrauchen grundlegende Protokollfunktionen, wie etwa Slowloris-Angriffe
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
In diesem Fall könnte das bedeuten, zu erkennen, ob ein Client Streams schnell zurücksetzt, und diesen Traffic auf eine langsamere Spur zu schicken oder ganz herauszufiltern
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
„Ein entscheidender Punkt bei dem rekordverdächtigen Angriff ist, dass ein mittelgroßes Botnetz aus rund 20.000 Maschinen beteiligt war“
Große Anbieter könnten das alle so machen und vor die nächste besuchte Cloudflare-Site eine kleine Turnstile-ähnliche Seite schalten
Wenn es in meinem Netzwerk ein infiziertes Gerät gibt, möchte ich das wissen, und derzeit habe ich kein echtes Monitoring, um so etwas zu erkennen. Es ist keine vollständige Lösung, aber Nutzer zumindest darauf hinzuweisen, dass es ein Problem gibt, wäre ein guter Anfang