Google: Schwachstelle in HTTP/2 mündet in neuem DDoS-Rekord

Marc Stöckel
30 Kommentare
Google: Schwachstelle in HTTP/2 mündet in neuem DDoS-Rekord
Bild: Pexels: Brett Jordan

DDoS-Angriffe machen Anbietern von Online-Diensten regelmäßig das Leben schwer. Unter Ausnutzung einer neu entdeckten Zero-Day-Schwachstelle im HTTP/2-Protokoll kam es erst kürzlich zu einer Reihe rekordverdächtiger Attacken. Den bislang größten DDoS-Angriff aller Zeiten durfte Google abwehren.

Bis zu 398 Millionen Anfragen pro Sekunde

Böswillige Akteure haben seit August eine neue DDoS-Angriffstechnik eingesetzt, um die Erreichbarkeit diverser Onlinedienste zu gefährden. Cloud-Anbieter wie Google, Amazon und Cloudflare haben dadurch in den vergangenen Wochen neue Rekord-Angriffe verzeichnet, die allesamt auf einer „Rapid Reset“ genannten Zero-Day-Schwachstelle im HTTP/2-Protokoll beruhen.

Der Softwarekonzern Google hat dabei offenbar einen neuen Weltrekord erfasst: In der Spitze habe das Unternehmen etwa 398 Millionen Anfragen pro Sekunde (RPS) abgewehrt. Der Angreifer habe innerhalb von nur zwei Minuten mehr Anfragen generiert „als die Gesamtzahl der von Wikipedia gemeldeten Artikelaufrufe während des gesamten Monats September 2023“.

Auch Cloudflare, Amazon und Microsoft melden sich zu Wort

Ein von Cloudflare abgewehrter DDoS-Angriff auf Basis von Rapid Reset ist aber nicht minder beeindruckend. Bis zu 201 Millionen RPS habe der Anbieter erfasst. Ausgegangen sei dieser Angriff von einem vergleichsweise kleinen Botnetz mit lediglich 20.000 Teilnehmern. In diesem Zuge warnt der Konzern auch vor dem Potenzial der ausgenutzten HTTP/2-Schwachstelle, denn schließlich gebe es Botnetze, die noch weitaus größer seien und Hunderttausende oder gar Millionen von Rechnern umfassen. „Die Tatsache, dass ein relativ kleines Botnetz eine so große Menge an Anfragen ausgeben konnte, mit dem Potenzial, nahezu jeden Server oder jede Anwendung, die HTTP/2 unterstützt, lahmzulegen, unterstreicht, wie bedrohlich diese Schwachstelle für ungeschützte Netzwerke ist“, warnt Cloudflare.

Obendrein hat das Unternehmen seit Ende August nach eigenen Angaben noch weitaus mehr DDoS-Angriffe beeindruckenden Ausmaßes abgewehrt. Insgesamt 184 Angriffe seien größer gewesen als der zuvor von Cloudflare verzeichnete Rekordangriff mit 71 Millionen RPS. Über 1.100 DDoS-Angriffe seien immerhin auf mehr als 10 Millionen Anfragen pro Sekunde gekommen.

Auch Amazon Web Services (AWS) will Ende August einen Angriff mit bis zu 155 Millionen RPS erkannt haben. Microsoft hat ebenfalls einen Blogbeitrag zu dem Thema veröffentlicht, nennt dort aber keine Details hinsichtlich erfolgter Angriffe. Stattdessen erklärt der Redmonder Konzern, er habe „umgehend Abhilfemaßnahmen für IIS (HTTP.sys), .NET (Kestrel) und Windows geschaffen“. Diese seien Teil der gestern veröffentlichten Microsoft-Sicherheitsupdates. Betreiber von Onlinediensten finden in Microsofts Bericht außerdem ein paar Hinweise auf mögliche Schutzmaßnahmen gegen Rapid Reset.

Angriffe entstehen durch wiederholt abgebrochene Streams

Google hat derweil noch einen separaten Blogbeitrag veröffentlicht, in dem der Konzern näher auf die Hintergründe der ausgenutzten und als CVE-2023-44487 registrierten Schwachstelle eingeht. Im Grunde handelt es sich bei Rapid Reset wohl um einen missbräuchlichen Einsatz sogenannter RST_STREAM-Frames innerhalb einer TCP-Verbindung. Durch diesen Frame könne ein Client einen zuvor geöffneten HTTP/2-Stream abbrechen, den er zu einem Server aufgebaut habe. Infolgedessen lasse sich eine Überlastung des Zielsystems auslösen, indem ein Angreifer kontinuierlich neue Streams öffne und wieder abbreche.

Rapid Reset
Rapid Reset (Bild: Google)

Das Protokoll verlangt nicht, dass der Client und der Server den Abbruch in irgendeiner Weise koordinieren, der Client kann dies einseitig tun“, erklärt Google. Die Anfrage werde daraufhin zwar abgebrochen, die HTTP/2-Verbindung bleibe aber offen. Erschwerend komme hinzu, dass in Bezug auf die Verarbeitung der Anfragen „eine ausnutzbare Kostenasymmetrie zwischen dem Server und dem Client“ bestehe. Denn während einem Client für das Senden einer Anfrage fast keine Kosten entstehen, müsse der Server selbst abgebrochene Anfragen noch zu einem gewissen Grad verarbeiten. Dazu gehöre etwa das Parsen der Anfrage, die Dekomprimierung der Header, die Zuordnung der URL zu einer Ressource sowie die Zuweisung neuer Stream-Datenstrukturen.