Google verzeichnete den größten DDoS-Angriff auf seine Infrastruktur, dessen Intensität 398 Millionen Anfragen pro Sekunde betrug. Der neue Angriff ist siebenmal intensiver als der vorherige rekordverdächtige DDoS-Angriff, bei dem es den Angreifern gelang, einen Fluss von 7 Millionen Anfragen pro Sekunde zu generieren. Zum Vergleich: Der gesamte Datenverkehr im gesamten Web wird auf 47–1 Milliarden Anfragen pro Sekunde geschätzt. Neben Google waren auch Amazon und Cloudflare einem Angriff ausgesetzt. Die Möglichkeit eines neuen Angriffs ist mit der Identifizierung einer Schwachstelle im HTTP/3-Protokoll (CVE-2-2023) verbunden, die es ermöglicht, eine große Anzahl von Anfragen an den Server zu senden, ohne den Client zu belasten.
Die neue Angriffstechnik heißt „Rapid Reset“ und macht sich die Tatsache zunutze, dass die in HTTP/2 bereitgestellten Mittel zum Multiplexen von Kommunikationskanälen es ermöglichen, einen Stream von Anfragen innerhalb einer bereits bestehenden Verbindung zu generieren, ohne neue Netzwerkverbindungen zu öffnen und ohne Warten auf die Bestätigung des Paketempfangs. Die Schwachstelle gilt als Folge eines Fehlers im HTTP/2-Protokoll, dessen Spezifikation besagt, dass beim Versuch, zu viele Flows zu öffnen, nur die Flows abgebrochen werden sollen, die das Limit überschreiten, nicht aber das gesamte Netzwerk Verbindung.
Ähnlich wie bisher verwendete Angriffsmethoden auf HTTP/2 erzeugt auch der neue Angriff eine große Anzahl von Threads innerhalb einer einzelnen Verbindung. Der Hauptunterschied des neuen Angriffs besteht darin, dass nicht auf eine Antwort gewartet wird, sondern auf jede gesendete Anfrage ein Frame mit dem RST_STREAM-Flag folgt, der die Anfrage sofort abbricht. Durch das frühzeitige Abbrechen einer Anfrage können Sie den umgekehrten Datenverkehr zum Client beseitigen und die Beschränkungen hinsichtlich der maximal möglichen Anzahl von Streams umgehen, die gleichzeitig innerhalb einer einzelnen HTTP/2-Verbindung auf HTTP-Servern geöffnet werden können. Somit hängt bei dem neuen Angriff das Volumen der an den HTTP-Server gesendeten Anfragen nicht mehr von den Verzögerungen zwischen dem Senden der Anfrage und dem Empfangen der Antwort (RTT, Roundtrip-Zeit) ab, sondern hängt nur noch von der Bandbreite des Kommunikationskanals ab.
Da ein clientseitiger Angriff lediglich das Senden von Anfragen ohne Empfang von Antworten erfordert, kann er mit minimalem Aufwand durchgeführt werden. Beispielsweise wurde der von Cloudflare registrierte Angriff mit 201 Millionen Anfragen pro Sekunde mithilfe eines vergleichsweise kleinen Botnetzes von 20 Computern durchgeführt. Server Die Kosten für die Verarbeitung eingehender Anfragen sind trotz deren Abbruch deutlich höher, da Operationen wie die Zuweisung von Datenstrukturen für neue Datenströme, das Parsen der Anfrage, das Entpacken des Headers und der Abgleich der URL mit der Ressource durchgeführt werden müssen. Bei Angriffen auf Reverse-Proxys kann sich der Angriff auf Backends ausbreiten, da der Proxy die Anfrage möglicherweise an das Backend weiterleitet, bevor der RST_STREAM-Frame verarbeitet wurde.
Der Angriff kann nur auf anfälligen Servern durchgeführt werden, die HTTP/2 unterstützen (Skript zur Überprüfung von Serverschwachstellen, Angriffswerkzeuge). Bisher wurden keine Angriffe auf HTTP/3 entdeckt, und deren Durchführbarkeit wurde noch nicht vollständig analysiert. Google-Vertreter empfehlen Entwicklern jedoch, HTTP/2 zu verwenden. Server Ergänzen Sie HTTP/3-Implementierungen um Schutzmaßnahmen, die denen ähneln, die zum Blockieren von Angriffen auf HTTP/2 implementiert wurden.
Gefährdung durch Sicherheitslücken und Verfügbarkeit von Korrekturen für HTTP-Server und -Proxys:
- nginx (Ankündigung, Klarstellung, dass sich die Schwachstelle in nginx in der Standardkonfiguration nicht vollständig manifestiert, da der Angriff durch die Begrenzung der Anzahl der Anfragen pro Verbindung begrenzt wird (d. h. nach jeweils 1000 Anfragen wird die Verbindung zurückgesetzt). Der Patch fügt zusätzlichen Schutz hinzu, um die Intensität der Anfragen durch die „limit_req“-Direktive zu begrenzen.
- In HAProxy wurde bereits 2 ein wirksamer Schutz gegen das Überschreiten der Anzahl der HTTP/2018-Threads hinzugefügt, der seit Version 1.9-dev in Kraft ist.
- Apache httpd (auf httpd entsteht eine gewisse Belastung, die jedoch nicht für die Backends gilt und durch die seit 2016 geltenden Beschränkungen für Clientverbindungen begrenzt ist).
- mod_h2 für Apache httpd.
- Caddie
- Gesandte
- golang (Problem in den Versionen Go 1.21.3 und 1.20.10 behoben).
- H2O (Pflaster).
- grpc-go
- hyper (Sicherheitslücke erscheint nicht).
- Steg (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 (der ASP.NET Core Kestrel-HTTP-Server ist anfällig).
- Node.js
- Proxygen
- Swift-nio-http2 (behoben in Version 1.28.0).
- Apache Tomcat (behoben in den Versionen 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (im 9.2.x-Zweig behoben).
Source: opennet.ru
