Google hat den größten DDoS-Angriff auf seine Infrastruktur gemeldet, der mit einer Intensität von 398 Millionen Anfragen pro Sekunde durchgeführt wurde. Dieser neue Angriff übertrifft die vorherige Rekord-DDoS-Attacke um das Siebenfache, bei der Angreifer einen Verkehr von 47 Millionen Anfragen pro Sekunde erzeugen konnten. Zum Vergleich: Der gesamte Traffic im 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 einer Schwachstelle im HTTP/2-Protokoll (CVE-2023-44487) zusammen, die es ermöglicht, mit minimaler Belastung für den Client einen riesigen Strom von Anfragen an den Server zu senden.
Eine neue Angriffstechnik trägt den Namen „Rapid Reset“ und nutzt die in HTTP/2 bereitgestellten Multiplexing-Funktionen aus, um eine Anfrageströmung 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 eines Fehlers im HTTP/2-Protokoll betrachtet, in dem spezifiziert ist, dass bei dem Versuch, eine zu große Anzahl von Streams zu öffnen, nur die Streams, die das Limit überschreiten, annulliert werden sollen, das gesamte Netzwerkverbindung jedoch nicht geschlossen werden darf.
Ähnlich wie bei früheren Methoden zur Durchführung von Angriffen auf HTTP/2 werden auch bei diesem neuen Angriff viele Streams innerhalb einer einzigen Verbindung generiert. Der entscheidende Unterschied bei diesem Angriff besteht darin, dass anstelle des Wartens auf eine Antwort nach jeder gesendeten Anfrage ein Frame mit dem Flag RST_STREAM gesendet wird, der die Anfrage sofort abbricht. Das frühzeitige Abbrechen der Anfrage ermöglicht es, den Rückverkehr zum Client zu vermeiden und die auf HTTP-Servern vorhandenen Einschränkungen bezüglich der maximalen Anzahl gleichzeitig in einer HTTP/2-Verbindung geöffneten Streams zu umgehen. Dadurch hört der Umfang der an den HTTP-Server gesendeten Anfragen auf, von den Verzögerungen zwischen dem Senden der Anfrage und dem Empfang der Antwort (RTT, round-trip time) abhängig zu sein und richtet sich nur noch nach der Bandbreite der Verbindung.
Da für einen Angriff auf der Client-Seite lediglich das Versenden von Anfragen ohne Antworten erforderlich ist, kann ein Angriff mit minimalen Kosten durchgeführt werden. So wurde beispielsweise ein von Cloudflare registrierter Angriff mit 201 Millionen Anfragen pro Sekunde mithilfe eines relativ kleinen Botnets mit 20.000 Computern durchgeführt. Auf der Seite Server sind die Kosten für die Verarbeitung eingehender Anfragen deutlich höher, obwohl sie abgebrochen werden, da Operationen wie das Zuweisen von Datenstrukturen für neue Datenströme, das Parsen der Anfrage, das Entpacken der Header und die Zuordnung der URL zu den Ressourcen erforderlich sind. Bei einem Angriff auf Reverse Proxys kann der Angriff auf die Backends ausgeweitet werden, da der Proxy die Anfrage möglicherweise an das Backend weiterleiten kann, bevor das RST_STREAM-Frame bearbeitet wird.
Ein Angriff kann nur auf anfällige Server mit HTTP/2-Unterstützung durchgeführt werden (ein Skript zur Überprüfung der Anfälligkeit von Servern, ein Toolkit zur Durchführung des Angriffs). Angriffe auf HTTP/3 sind bisher nicht dokumentiert, und die Möglichkeit, sie durchzuführen, wurde vollständig nicht analysiert, jedoch empfehlen Vertreter von Google Entwicklern Server Implementierung von HTTP/3-Schutzmaßnahmen, ähnlich denen zur Abwehr von Angriffen auf HTTP/2, hinzufügen.
Anfälligkeit für Schwachstellen und Verfügbarkeit von Patches für HTTP-Server und Proxys:
- nginx (Ankündigung, Erklärung, dass die Schwachstelle in der Standardkonfiguration von nginx nicht vollständig ausgenutzt werden kann, da der Angriff an das Limit der Verbindungsanfragen stößt (d.h. nach jeweils 1000 Anfragen wird die Verbindung zurückgesetzt). Im Patch wurde zusätzlicher Schutz durch Begrenzung der Anfrageintensität mittels der Direktive „limit_req“ eingeführt).
- In HAProxy wurde bereits 2018 ein effektiver Schutz gegen Überschreitung des Limits für HTTP/2-Streams eingeführt, der ab Version 1.9-dev wirksam ist.
- Apache httpd (es entsteht eine gewisse Last auf httpd, die jedoch nicht auf die Backend-Server übertragen wird und durch die seit 2016 geltenden Limits für Clientverbindungen begrenzt ist).
- mod_h2 für Apache httpd.
- Caddy
- Envoy
- Golang (Problem wurde in den Versionen Go 1.21.3 und 1.20.10 behoben).
- h2o (Patch).
- grpc-go
- Hyper (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 (anfällig ist der HTTP-Server ASP.NET Core Kestrel).
- Node.js
- Proxygen
- swift-nio-http2 (korrigiert 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 in der Versionsreihe 9.2.x).
Quelle: opennet.ru
