Eine als „Rapid Reset“ bezeichnete Schwachstelle im HTTP/2-Protokoll hat in den vergangenen Monaten zu rekordverdächtigen DDoS-Angriffen auf Webserver geführt. Google, AWS und Cloudflare haben die Angriffe und die Schwachstelle heute gemeinsam offengelegt, wiesen jedoch darauf hin, dass jeder moderne Webserver weiterhin für diese Angriffstechnik anfällig ist. Anbieter und Projekte im Webserver-Bereich kündigten ebenfalls Gegenmaßnahmen und Pläne für Sicherheitsupdates an.
Google zufolge erreichten die Angriffe ihren Höchststand bei 398 Millionen Anfragen pro Sekunde (RPS) – mehr als das Fünffache des bisherigen Rekords vom Februar 2023 – und in zwei Minuten wurde mehr Webtraffic erzeugt, als Wikipedia im gesamten September verzeichnete. Cloudflare zufolge erreichten die Angriffe einen Höchststand von etwas mehr als 201 Millionen Anfragen pro Sekunde.
Google, AWS und Cloudflare erklärten, dass sie in der Lage waren, den durch die Angriffe verursachten Schaden zu begrenzen. „Während wir zunächst gewisse Auswirkungen auf den Datenverkehr unserer Kunden beobachteten – in der ersten Angriffswelle waren rund 1 % der Anfragen betroffen –, konnten wir unsere Gegenmaßnahmen inzwischen so verfeinern, dass der Angriff für jeden Cloudflare-Kunden gestoppt wird, ohne unsere Systeme zu beeinträchtigen“, erklärte Cloudflare.
Beunruhigend ist, dass die Angreifer den Angriff mit einem Botnetz aus nur 20.000 Rechnern erzeugen konnten. „Es gibt heute Botnetze, die aus Hunderttausenden oder Millionen Rechnern bestehen“, erklärte Cloudflare in einem technischen Blogbeitrag über die Schwachstelle (CVE-2023-44487). „Da das gesamte Web normalerweise nur zwischen 1 und 3 Milliarden Anfragen pro Sekunde verzeichnet, ist es durchaus vorstellbar, dass diese Methode die Anfragen eines gesamten Webs auf eine kleine Zahl von Zielen konzentriert.“
Ebenso beunruhigend ist, wie weit verbreitet die Schwachstelle ist.
Außerdem lesen: So stoppen Sie DDoS-Angriffe in drei Phasen
„Jeder moderne Webserver“ betroffen
Cloudflare wies darauf hin, dass der Angriff eine grundlegende Schwachstelle im HTTP/2-Protokoll ausnutzt: „Wir gehen davon aus, dass jeder Anbieter, der HTTP/2 implementiert hat, dem Angriff ausgesetzt ist. Das schließt jeden modernen Webserver ein.“
„Gemeinsam mit Google und AWS haben wir die Angriffsmethode gegenüber Webserver-Anbietern offengelegt, von denen wir erwarten, dass sie Patches bereitstellen. Bis dahin besteht die beste Verteidigung darin, vor jedem aus dem Web erreichbaren Web- oder API-Server einen DDoS-Schutzdienst wie den von Cloudflare zu betreiben.“
Anbieter von Webservern und Open-Source-Projekte, darunter Apache Tomcat, Microsoft und mehrere andere, veröffentlichten Leitfäden zum Umgang mit der Schwachstelle; die wachsende Zahl der Ankündigungen findet sich im CVE-Eintrag.
NGINX empfahl beispielsweise mehrere Konfigurationsänderungen zur Verkleinerung der Angriffsfläche:
- keepalive_requests sollte auf der Standardeinstellung von 1000 Anfragen belassen werden
- http2_max_concurrent_streams sollte auf der Standardeinstellung von 128 Streams belassen werden
- limit_conn begrenzt die Zahl der Verbindungen, die von einem einzelnen Client zugelassen werden, und sollte „mit einer angemessenen Einstellung hinzugefügt werden, die Anwendungsleistung und Sicherheit ausbalanciert“
- limit_req begrenzt die Zahl der Anfragen, die innerhalb eines bestimmten Zeitraums von einem einzelnen Client verarbeitet werden, und sollte ebenfalls Anwendungsleistung und Sicherheit ausbalancieren.
NGINX erklärte, dass das Unternehmen morgen einen Patch veröffentlichen werde, der die Zahl neuer Streams begrenzt, die innerhalb eines Ereigniszyklus eingeführt werden können. Das Limit wird auf das Doppelte des Werts gesetzt, der mit der Direktive http2_max_concurrent_streams konfiguriert wurde. „Das Limit wird auch dann angewendet, wenn der maximale Schwellenwert nie erreicht wird, etwa wenn Streams direkt nach dem Senden der Anfrage zurückgesetzt werden (wie im Fall dieses Angriffs)“, erklärte NGINX.
Außerdem lesen:
- So verhindern Sie DDoS-Angriffe: 5 Schritte zur DDoS-Prävention
- So erkennen Sie, ob Sie Opfer eines DDoS-Angriffs wurden: 5 Anzeichen für einen DDoS-Angriff
So funktioniert der HTTP/2-„Rapid-Reset“-Angriff
In einem technischen Blogbeitrag über den HTTP/2-„Rapid-Reset“-Angriff wies Google darauf hin: „Ein zentrales Ziel von HTTP/2 war die Effizienz. Leider können die Funktionen, die HTTP/2 für legitime Clients effizienter machen, auch dazu genutzt werden, DDoS-Angriffe effizienter zu machen.“
Im Kern funktioniert der Rapid-Reset-Angriff, indem eine HTTP/2-Funktion namens „Stream-Abbruch“ missbraucht wird: Wiederholt werden Anfragen gesendet und anschließend sofort abgebrochen.
Das HTTP/2-Protokoll ermöglicht es Clients, einem Server durch das Senden eines RST_STREAM-Frames mitzuteilen, dass ein vorheriger Stream abgebrochen werden soll, wie Google anmerkte. Das Protokoll verlangt nicht, dass Client und Server den Abbruch koordinieren; der Client kann ihn einseitig veranlassen. Außerdem kann der Client davon ausgehen, dass der Abbruch sofort wirksam wird, sobald der Server den RST_STREAM-Frame empfängt, bevor weitere Daten dieser TCP-Verbindung verarbeitet werden.
„Dieser Angriff wird Rapid Reset genannt, weil er darauf beruht, dass ein Endpunkt direkt nach dem Senden eines Request-Frames einen RST_STREAM-Frame senden kann. Dadurch beginnt der andere Endpunkt mit der Verarbeitung und setzt die Anfrage anschließend schnell zurück“, erklärte Google. „Die Anfrage wird abgebrochen, die HTTP/2-Verbindung bleibt jedoch bestehen.“
Der auf dieser Fähigkeit aufbauende HTTP/2-Rapid-Reset-Angriff ist laut Google einfach:
„Der Client öffnet gleichzeitig eine große Zahl von Streams, wie bei einem herkömmlichen HTTP/2-Angriff. Statt jedoch für jeden Request-Stream auf eine Antwort des Servers oder Proxys zu warten, bricht der Client jede Anfrage sofort ab. Durch die Möglichkeit, Streams sofort zurückzusetzen, kann jede Verbindung eine unbegrenzte Zahl von Anfragen gleichzeitig verarbeiten. Indem der Angreifer die Anfragen ausdrücklich abbricht, überschreitet er nie das Limit für die Zahl gleichzeitig geöffneter Streams. Die Zahl der gleichzeitig laufenden Anfragen hängt damit nicht mehr von der Round-Trip-Zeit (RTT), sondern nur noch von der verfügbaren Netzwerkbandbreite ab.“
Bei einer typischen HTTP/2-Serverimplementierung „muss der Server weiterhin erhebliche Arbeit für abgebrochene Anfragen leisten, etwa neue Datenstrukturen für Streams zuweisen, die Anfrage analysieren und Header dekomprimieren sowie die URL einer Ressource zuordnen“, erklärte Google.
Bei Reverse-Proxy-Implementierungen „kann die Anfrage an den Backend-Server weitergeleitet werden, bevor der RST_STREAM-Frame verarbeitet wird. Der Client hingegen hatte für das Senden der Anfragen nahezu keine Kosten. Dadurch entsteht ein ausnutzbares Kostenungleichgewicht zwischen Server und Client. Ein weiterer Vorteil für den Angreifer besteht darin, dass ein Reverse-Proxy-Server aufgrund des unmittelbaren expliziten Abbruchs der Anfragen direkt nach ihrer Erstellung keine Antwort auf eine der Anfragen senden wird.“
Gegenmaßnahmen können verschiedene Formen annehmen, konzentrieren sich laut Google jedoch hauptsächlich auf die Erfassung von Verbindungsstatistiken sowie auf die Nutzung von Signalen und Geschäftslogik, um zu bestimmen, wie nützlich die jeweilige Verbindung ist. „Wenn eine Verbindung beispielsweise mehr als 100 Anfragen aufweist und mehr als 50 % dieser Anfragen abgebrochen wurden, könnte sie ein Kandidat für eine Gegenmaßnahme sein. Umfang und Art der Reaktion hängen vom Risiko für die jeweilige Plattform ab; möglich sind jedoch Reaktionen von expliziten GOAWAY-Frames, wie zuvor beschrieben, bis hin zum sofortigen Schließen der TCP-Verbindung.
„Um der Variante dieses Angriffs ohne Abbrüche entgegenzuwirken, empfehlen wir, dass HTTP/2-Server Verbindungen schließen, die das Limit für gleichzeitig laufende Streams überschreiten. Dies kann entweder sofort oder nach einer kleinen Zahl wiederholter Verstöße geschehen.“
Weiterlesen: