Genauerer Blick auf die Angriffsmechanismen
Am 10. Oktober veröffentlichten Google und Cloudflare Berichte über den Missbrauch einer bestimmten Funktion des HTTP/2-Protokolls, die zu einer erhöhten Last und einem potenziellen Denial-of-Service auf Servern führt, die mit vielen gleichzeitigen Anfragen nicht Schritt halten können.
In ihren Berichten wird ein Szenario detailliert beschrieben, in dem ein Akteur die Beschränkungen zur Begrenzung der Anzahl gleichzeitiger Anfragen an einen HTTP/2-Server (für jeden Client) umgehen kann, indem er eine Anfrage direkt nach der Erstellung abbricht und den internen Anfragezähler für jede abgebrochene Anfrage effektiv zurücksetzt. Dies bedeutet, dass der Akteur dann unendlich viele neue Anfragen an den Server senden kann, ohne an diese Grenzen zu stoßen.
Ein gut optimierter Webserver, bei dem der HTTP/2-Dienst direkt mit dem Client verbunden ist und keine externen Daten über die Geschäftslogik abgerufen werden (d.h. ein Server, der keine Anfragen an einen anderen Server weiterleitet oder proxysiert), wird definitiv einen gewissen Anstieg der Auslastung verzeichnen, aber nichts, was der Server nicht bewältigen könnte. Das Problem wird deutlicher, wenn der HTTP/2-Server versucht, jede Anfrage über eine Netzwerkverbindung weiterzuleiten (z. B. ein Nginx-Server, der Verbindungen zu einem auf Apache laufenden API-Dienst weiterleitet).
In diesem Szenario müssen die Anfragedaten vom Proxy gepuffert und dann an einen Backend-Dienst gesendet werden; dieser Backend-Dienst muss diese Daten dann verarbeiten und die Antwort zurück an den HTTP/2-Server senden. In der Zwischenzeit, während des Wartens auf diese Proxy-Antworten, können mehrere Bereiche im laufenden Prozess Speicher und Ressourcen nutzen, die noch bereinigt werden müssen.
Kurz gesagt, ein Client sendet eine gültige HTTP/2-Anfrage, der HTTP/2-Server analysiert diese Anfrage, sendet die Anfrage an einen Backend-Server und wartet auf eine Antwort. Der Client bricht diese Anfrage jedoch sofort ab, so dass der HTTP2-Server die Anfrage an das Backend ebenfalls abbrechen muss, aber zu diesem Zeitpunkt sind die Daten und Ressourcen bereits zugewiesen und verwendet worden. Und da der Zähler für die maximale Anzahl von Anfragen ständig zurückgesetzt wird, können unendlich viele Anfragen eingehen, ohne dass sie aufgehalten werden.
Der Google-Blog bringt es am besten auf den Punkt, wenn er Folgendes schreibt:
"...kann der Client 100 Streams öffnen und eine Anfrage an jeden von ihnen in einem einzigen Umlauf senden; der Proxy liest und verarbeitet jeden Stream seriell, aber die Anfragen an die Backend-Server können wiederum parallelisiert werden. Der Client kann dann neue Streams öffnen, wenn er Antworten auf die vorherigen erhält. Dies ergibt einen effektiven Durchsatz für eine einzelne Verbindung von 100 Anfragen pro Round Trip, mit ähnlichen Zeitkonstanten für Round Trip wie bei HTTP/1.1-Anfragen. Dies führt in der Regel zu einer fast 100-mal höheren Auslastung jeder Verbindung.
Die treffend als "Rapid Reset Attack" bezeichnete HTTP/2-Attacke (die darauf basiert, dass Clients jede ausgehende Anfrage zurücksetzen) betrifft technisch gesehen jede HTTP/2-Implementierung, d. h. es handelt sich nicht um eine hersteller- oder produktspezifische Schwäche, sondern um eine Schwachstelle im Protokoll selbst. Und jedes Produkt, das HTTP/2 (derzeit) unterstützt, ist anfällig für diesen Angriff.
Kurz gesagt, dieser Angriff setzt die Frontend-Server und die Backend-Server, mit denen sie kommunizieren, stark unter Druck, wie in Umgebungen mit starkem Proxy. Deshalb kommen die meisten Berichte über diesen Angriff von Dienstanbietern, die sich stark mit Lastausgleich und HTTP-Proxys beschäftigen, wie Cloudflare und Google.
Was Censys sieht
Censys kann feststellen, ob ein HTTP-Dienst eingehende HTTP/2-Anfragen annehmen und verarbeiten kann, verfügt aber über keine zusätzlichen Informationen über die zugrundeliegende Implementierung, abgesehen von dem, was uns die HTTP-Server mitteilen (z.B. ein Server-Header, der uns sagt, dass es sich um Apache oder Nginx handelt). Zum Zeitpunkt der Erstellung dieses Artikels gibt es keine konkreten Patches oder Workarounds. Wenn wir raten sollten, handelt es sich nicht um eine Änderung des zugrunde liegenden Protokolls, sondern um eine Umgehung in den Protokollimplementierungen selbst. In jedem Fall werden die HTTP/2-Protokollimplementierungen geändert, und die Betreiber von Hosts müssen ihre Server aktualisieren.
Da das HTTP2-Protokoll keine spezifische semantische Versionierung oder Identifizierung enthält, kann Censys auch nach einer Umgehung oder Korrektur nur feststellen, ob das HTTP/2-Protokoll unterstützt wird oder nicht.
Mit Stand vom 10. Oktober 2023 beobachtete Censys 556,3 Millionen Hosts mit 719,8 Millionen HTTP/2-fähigen Servern. Beachten Sie, dass dies HTTP-Server mit der Möglichkeit eines Upgrades auf HTTP/2 einschließt, aber nicht notwendigerweise alle Server, die derzeit HTTP/2 nutzen.
