Das Unternehmen Google verzeichnete den größten DDoS-Angriff auf seine Infrastruktur, dessen Intensität 398 Millionen Anfragen pro Sekunde betrug. Der neue Angriff übertrifft die Intensität des vorherigen Rekords DDoS-Angriffs um das Siebenfache, bei dem es den Angreifern gelang, einen Datenstrom von 47 Millionen Anfragen pro Sekunde zu erzeugen. Zum Vergleich: Der gesamte Datenverkehr im gesamten Web wird auf 1-3 Milliarden Anfragen pro Sekunde geschätzt. Neben Google waren auch Unternehmen wie Amazon und Cloudflare von dem Angriff betroffen. Die Möglichkeit eines neuen Angriffs hängt mit der Entdeckung einer Schwachstelle im HTTP/2-Protokoll (CVE-2023-44487) zusammen, die es ermöglicht, bei minimaler Belastung des Clients einen riesigen Anfragenstrom an den Server zu senden.
Die neue Angriffstechnik wird als „Rapid Reset“ bezeichnet und nutzt aus, dass die im HTTP/2-Protokoll bereitgestellten Multiplexing-Möglichkeiten es erlauben, einen Anfragenstrom innerhalb einer bereits bestehenden Verbindung zu erzeugen, ohne neue Netzwerkverbindungen zu öffnen und ohne auf die Bestätigung des Paketempfangs zu warten. Die Schwachstelle wird als Folge unzureichender Entwicklungen des HTTP/2-Protokolls angesehen, in der Spezifikation steht, dass bei dem Versuch, zu viele Streams zu öffnen, nur die Streams, die das Limit überschreiten, annulliert werden sollten, ohne dass die gesamte Netzwerkverbindung geschlossen wird.
Ähnlich wie bei früheren Methoden zur Durchführung von Angriffen auf HTTP/2 wird auch im neuen Angriff eine große Anzahl von Streams innerhalb einer einzigen Verbindung erzeugt. Der entscheidende Unterschied des neuen Angriffs besteht darin, dass anstelle des Wartens auf eine Antwort nach jeder gesendeten Anfrage ein Frame mit dem RST_STREAM-Flag gesendet wird, der die Anfrage sofort annulliert. Die frühzeitige Stornierung der Anfrage ermöglicht es, den Rückverkehr zum Client zu vermeiden und die auf HTTP-Servern bestehenden Einschränkungen hinsichtlich der maximal möglichen Anzahl von Streams, die innerhalb einer Verbindung über HTTP/2 geöffnet sind, zu umgehen. Auf diese Weise hängt das Volumen der an HTTP-Server gesendeten Anfragen im neuen Angriff nicht mehr von den Verzögerungen zwischen dem Senden der Anfrage und dem Erhalten der Antwort (RTT, round-trip time) ab, sondern vielmehr von der Bandbreite der Verbindung.
Da für einen Angriff auf der Client-Seite lediglich das Versenden von Anfragen ohne Erhalt von Antworten erforderlich ist, kann der Angriff mit minimalen Overheadkosten durchgeführt werden. Ein von Cloudflare dokumentierter Angriff mit 201 Millionen Anfragen pro Sekunde wurde mithilfe eines relativ kleinen Botnets von 20.000 Computern durchgeführt. Auf der Seite Server sind die Kosten für die Verarbeitung eingehender Anfragen erheblich höher, obwohl sie storniert werden, da Operationen wie die Zuordnung von Datenstrukturen für neue Streams, die Analyse der Anfrage, das Entpacken der Header und das Abgleichen der URL mit der Ressource erforderlich sind. Bei Angriffen auf Reverse-Proxys kann sich der Angriff auf die Backends ausweiten, da der Proxy die Anfrage möglicherweise an das Backend weiterleiten kann, bevor das RST_STREAM-Paket verarbeitet wird.
Ein Angriff kann nur auf verwundbare Server mit Unterstützung für HTTP/2 durchgeführt werden (ein Skript zur Überprüfung des Vorhandenseins von Schwachstellen in Servern, Tools zur Durchführung des Angriffs). Für HTTP/3 wurden bisher keine Angriffe dokumentiert, und die Möglichkeit ihrer Durchführung ist noch nicht vollständig analysiert, aber Google-Vertreter empfehlen Entwicklern, Server Schutzmaßnahmen in die Implementierung von HTTP/3 aufzunehmen, die mit den Maßnahmen zum Schutz vor Angriffen auf HTTP/2 vergleichbar sind.
Anfälligkeit für die Schwachstelle und vorhandene Patches für HTTP-Server und Proxys:
- nginx (Ankündigung, Erläuterung, dass die Schwachstelle in der Standardkonfiguration von nginx nicht vollständig ausgeprägt ist, da der Angriff an das Limit der Anfragen pro Verbindung stößt (d.h. nach jeweils 1000 Anfragen wird die Verbindung zurückgesetzt). Der Patch enthält zusätzlichen Schutz durch Limitierung der Anfragen über die Direktive "limit_req").
- In HAProxy wurde bereits 2018 ein effektiver Schutz gegen Überschreitungen des Limits der HTTP/2-Streams eingeführt und gilt seit Version 1.9-dev.
- Apache httpd (es wird eine gewisse Last auf httpd erzeugt, aber sie breitet sich nicht auf die Backends aus und ist auf die seit 2016 geltenden Limits für Clientverbindungen beschränkt).
- mod_h2 für Apache httpd.
- caddy
- envoy
- golang (Problem behoben in den Versionen Go 1.21.3 und 1.20.10).
- h2o (Patch).
- grpc-go
- hyper (die Schwachstelle tritt nicht auf).
- jetty (behoben in 12.0.2, 11.0.17, 10.0.17 und 9.4.53.v20231009).
- netty
- nghttp2 (behoben in Version 1.57.0).
- Facebook proxygen
- .NET und ASP.NET Core (die Schwachstelle betrifft den HTTP-Server ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (behoben in Version 1.28.0).
- Apache Tomcat (korrigiert in den Versionen 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (korrigiert im Zweig 9.2.x).
Quelle: opennet.ru
