HTTP/2-Rapid-Reset-Angriff betrifft F5 NGINX-Produkte

Dieser Blogbeitrag befasst sich mit einer kürzlich entdeckten Schwachstelle im Zusammenhang mit dem HTTP/2-Protokoll. Unter bestimmten Bedingungen kann diese Schwachstelle ausgenutzt werden, um einen Denial-of-Service-Angriff auf NGINX Open Source, NGINX Plus und verwandte Produkte durchzuführen, die den serverseitigen Teil der HTTP/2-Spezifikation implementieren. Um Ihre Systeme vor diesem Angriff zu schützen, empfehlen wir, Ihre NGINX-Konfiguration umgehend zu aktualisieren.

Das Problem mit dem Zurücksetzen von HTTP/2-Streams

Nachdem eine Verbindung zu einem Server hergestellt wurde, ermöglicht das HTTP/2-Protokoll Clients, mehrere Streams für den Datenaustausch gleichzeitig zu starten. Anders als bei früheren Versionen des Protokolls bietet HTTP/2 eine Möglichkeit, den Stream abzubrechen, wenn ein Endnutzer die Seite verlässt oder den Datenaustausch aus einem anderen Grund beendet. Dazu sendet der Client einen RST_STREAM-Frame an den Server und verhindert so, dass dieser unnötige Arbeit ausführt.

Die Schwachstelle wird ausgenutzt, indem über eine bestehende Verbindung eine große Anzahl von HTTP/2-Streams initiiert und schnell wieder abgebrochen wird. Dadurch wird die maximale Anzahl gleichzeitiger Streams des Servers umgangen. Dies ist möglich, weil eingehende Streams schneller zurückgesetzt werden, als nachfolgende Streams eintreffen. So kann der Client den Server überlasten, ohne dass der konfigurierte Schwellenwert jemals erreicht wird.

Auswirkungen auf NGINX

Aus Gründen der Leistung und des Ressourcenverbrauchs begrenzt NGINX die Anzahl gleichzeitiger Streams standardmäßig auf 128 (siehe http2_max_concurrent_streams). Um Netzwerk- und Serverleistung optimal auszubalancieren, ermöglicht NGINX dem Client außerdem standardmäßig, HTTP-Verbindungen mithilfe von HTTP-Keepalive für bis zu 1000 Anfragen aufrechtzuerhalten (siehe keepalive_requests).

Durch die Verwendung des standardmäßigen Keepalive-Limits verhindert NGINX diese Art von Angriff. Wenn zusätzliche Verbindungen erstellt werden, um dieses Limit zu umgehen, können böswillige Akteure mithilfe gängiger Überwachungs- und Warnwerkzeuge für Schicht 4 erkannt werden.

Wenn NGINX jedoch mit einem Keepalive-Wert konfiguriert ist, der deutlich über der standardmäßigen und empfohlenen Einstellung liegt, kann der Angriff die Systemressourcen erschöpfen. Wird ein Stream zurückgesetzt, schreibt das HTTP/2-Protokoll vor, dass über diesen Stream anschließend keine weiteren Daten an den Client zurückgegeben werden. In der Regel verursacht das Zurücksetzen nur einen vernachlässigbaren Server-Overhead in Form von Aufgaben, die den Abbruch ordnungsgemäß verarbeiten. Durch das Umgehen des Stream-Grenzwerts von NGINX kann ein Client diesen Overhead jedoch ausnutzen und verstärken, indem er in kurzer Folge Tausende von Streams initiiert. Dadurch steigt die CPU-Auslastung des Servers sprunghaft an, sodass legitimen Clients der Dienst verweigert wird.

Denial-of-Service durch den Aufbau von HTTP/2-Streams mit anschließenden Stream-Abbrüchen bei ungewöhnlich hohen Keepalive-Grenzwerten

Maßnahmen zur Verringerung der Angriffsfläche

Als voll ausgestatteter Server und Proxy stellt NGINX Administratoren leistungsstarke Werkzeuge zur Abwehr von Denial-of-Service-Angriffen bereit. Um diese Funktionen nutzen und die Angriffsfläche des Servers minimieren zu können, müssen die folgenden Änderungen an den NGINX-Konfigurationsdateien vorgenommen werden:

• keepalive_requests sollte auf der Standardeinstellung von 1000 Anfragen belassen werden.
• http2_max_concurrent_streams sollte auf der Standardeinstellung von 128 Streams belassen werden.

Wir empfehlen außerdem, diese Sicherheitsmaßnahmen als Best Practice hinzuzufügen:

• limit_conn begrenzt die Anzahl der Verbindungen, die von einem einzelnen Client aus zulässig sind. Diese Direktive sollte mit einer angemessenen Einstellung hinzugefügt werden, die ein ausgewogenes Verhältnis zwischen Anwendungsleistung und Sicherheit gewährleistet.
• limit_req begrenzt die Anzahl der Anfragen, die innerhalb eines bestimmten Zeitraums von einem einzelnen Client verarbeitet werden. Diese Direktive sollte mit einer angemessenen Einstellung hinzugefügt werden, die Anwendungsleistung und Sicherheit in Einklang bringt.

Wie wir darauf reagieren

Wir haben verschiedene Strategien zur Risikominderung erprobt, um besser zu verstehen, wie sich dieser Angriff auf unser breites Spektrum an Kunden und Benutzern auswirken könnte. Unsere Untersuchungen haben zwar bestätigt, dass NGINX bereits über alle erforderlichen Werkzeuge verfügt, um den Angriff abzuwehren, dennoch wollten wir zusätzliche Maßnahmen ergreifen, damit Benutzer NGINX bei Bedarf auch über die empfohlenen Spezifikationen hinaus konfigurieren können.

Unsere Untersuchung hat eine Methode zur Verbesserung der Ausfallsicherheit von Servern gegenüber verschiedenen Formen von Flood-Angriffen ergeben, die theoretisch über das HTTP/2-Protokoll möglich sind. Daher haben wir einen Patch veröffentlicht, der die Systemstabilität unter diesen Bedingungen erhöht. Zum Schutz vor solchen Bedrohungen empfehlen wir Benutzern von NGINX Open Source, die Binärdateien auf Grundlage der neuesten Codebasis neu zu erstellen, und Kunden von NGINX Plus, umgehend auf die neuesten Pakete (R29p1 oder R30p1) zu aktualisieren.

So funktioniert der Patch

Um Flood-Angriffe auf NGINX frühzeitig zu erkennen, begrenzt der Patch die Anzahl neuer Streams, die innerhalb eines Event-Loops initiiert werden können. Dieses Limit entspricht dem Doppelten des Werts, der mit der Direktive http2_max_concurrent_streams konfiguriert wurde. Das Limit gilt auch dann, wenn der maximale Schwellenwert nie erreicht wird, etwa wenn Streams unmittelbar nach dem Senden der Anfrage zurückgesetzt werden (wie bei diesem Angriff).

Betroffene Produkte

Diese Schwachstelle betrifft das NGINX-HTTP/2-Modul (ngx_http_v2_module). Informationen dazu, ob Ihr spezifisches NGINX- oder F5-Produkt betroffen sein könnte, finden Sie unter: https://my.f5.com/manage/s/article/K000137106

Weitere Informationen zu CVE-2023-44487 – HTTP/2 Rapid Reset Attack finden Sie unter: https://www.cve.org/CVERecord?id=CVE-2023-44487

Danksagungen

Wir möchten Cloudflare, Amazon und Google für ihren Beitrag zur Entdeckung dieser Schwachstelle sowie für die Zusammenarbeit bei ihrer Identifizierung und Behebung danken.

Dieser Blogbeitrag wurde nach seiner ursprünglichen Veröffentlichung um zusätzliche Details zu den Abhilfemaßnahmen ergänzt und zur besseren Verständlichkeit überarbeitet.