HTTP/2 Rapid Reset-Angriff beeinträchtigt F5 NGINX-Produkte

In diesem Blogbeitrag geht es um eine kürzlich entdeckte Sicherheitslücke im Zusammenhang mit dem HTTP/2-Protokoll. Unter bestimmten Bedingungen kann diese Sicherheitslücke ausgenutzt werden, um einen Denial-of-Service-Angriff auf NGINX Open Source, NGINX Plus und verwandte Produkte auszuführen, die den serverseitigen Teil der HTTP/2-Spezifikation implementieren. Um Ihre Systeme vor diesem Angriff zu schützen, empfehlen wir eine sofortige Aktualisierung Ihrer NGINX-Konfiguration.

Das Problem mit HTTP/2-Stream-Resets

Nach dem Herstellen einer Verbindung mit einem Server ermöglicht das HTTP/2-Protokoll Clients, gleichzeitige Streams für den Datenaustausch zu initiieren. Im Gegensatz zu früheren Versionen des Protokolls bietet HTTP/2 eine Methode zum Abbrechen des Streams, wenn ein Endbenutzer die Seite verlassen oder den Datenaustausch aus einem anderen Grund unterbrechen möchte. Dies geschieht durch die Ausgabe eines RST_STREAM-Frames an den Server, wodurch dieser davor bewahrt wird, unnötige Arbeit auszuführen.

Die Sicherheitslücke wird ausgenutzt, indem über eine bestehende Verbindung eine große Anzahl von HTTP/2-Streams initiiert und schnell wieder abgebrochen wird, wodurch das Maximum an gleichzeitigen Streams des Servers umgangen wird. Dies liegt daran, dass eingehende Streams schneller zurückgesetzt werden als nachfolgende Streams eintreffen, wodurch der Client den Server überlasten kann, ohne jemals seinen konfigurierten Schwellenwert zu erreichen.

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 die Netzwerk- und Serverleistung optimal auszubalancieren, ermöglicht NGINX dem Client außerdem standardmäßig, HTTP-Verbindungen für bis zu 1000 Anfragen aufrechtzuerhalten, indem ein HTTP-Keepalive verwendet wird (siehe keepalive_requests ).

Durch die Verwendung des standardmäßigen Keepalive-Limits verhindert NGINX diese Art von Angriff. Durch die Erstellung zusätzlicher Verbindungen zur Umgehung dieser Beschränkung werden böswillige Akteure über standardmäßige Layer-4-Überwachungs- und Warntools enttarnt.

Wenn NGINX jedoch mit einem Keepalive-Wert konfiguriert ist, der wesentlich höher ist als die standardmäßige und empfohlene Einstellung, kann der Angriff die Systemressourcen erschöpfen. Wenn ein Stream-Reset erfolgt, erfordert das HTTP/2-Protokoll, dass in diesem Stream keine nachfolgenden Daten an den Client zurückgegeben werden. Normalerweise führt das Zurücksetzen zu einem vernachlässigbaren Server-Overhead in Form von Aufgaben, die den Abbruch reibungslos handhaben. Durch die Umgehung des Stream-Schwellenwerts von NGINX kann ein Client jedoch diesen Overhead ausnutzen und ihn durch die schnelle Initiierung von Tausenden von Streams verstärken. Dadurch wird die CPU-Auslastung des Servers erhöht und legitimen Clients wird der Dienst verweigert.

Denial-of-Service durch Einrichten von HTTP/2-Streams, gefolgt von Stream-Abbrüchen aufgrund ungewöhnlich hoher Keepalive-Grenzwerte.

Schritte zur Minderung der Angriffsgefahr

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

• 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 bewährte Methode hinzuzufügen:

• limit_conn erzwingt eine Begrenzung der Anzahl der Verbindungen, die von einem einzelnen Client aus zulässig sind. Diese Anweisung sollte mit einer sinnvollen Einstellung hinzugefügt werden, die Anwendungsleistung und Sicherheit in Einklang bringt.
• limit_req erzwingt eine Begrenzung der Anzahl von Anfragen, die innerhalb einer bestimmten Zeitspanne von einem einzelnen Client verarbeitet werden. Diese Anweisung sollte mit einer sinnvollen Einstellung hinzugefügt werden, die Anwendungsleistung und Sicherheit in Einklang bringt.

Unsere Reaktion

Wir haben mit mehreren Abwehrstrategien experimentiert, die uns geholfen haben, zu verstehen, wie sich dieser Angriff auf unsere zahlreichen Kunden und Benutzer auswirken könnte. Diese Untersuchung hat zwar bestätigt, dass NGINX bereits mit allen notwendigen Tools ausgestattet ist, um den Angriff abzuwehren, dennoch wollten wir zusätzliche Schritte unternehmen, um sicherzustellen, dass Benutzer, die NGINX über die empfohlenen Spezifikationen hinaus konfigurieren müssen, dies auch tun können.

Unsere Untersuchung ergab eine Methode zur Verbesserung der Serverausfallsicherheit gegenüber verschiedenen Formen von Flood-Angriffen, die theoretisch über das HTTP/2-Protokoll möglich sind. Daher haben wir einen Patch herausgegeben, der die Systemstabilität unter diesen Bedingungen erhöht. Zum Schutz vor solchen Bedrohungen empfehlen wir Benutzern von NGINX Open Source, Binärdateien aus 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 eine frühzeitige Erkennung von Flood-Angriffen auf NGINX zu gewährleisten, begrenzt der Patch die Anzahl neuer Streams, die innerhalb einer Ereignisschleife eingeführt werden können. Dieses Limit wird auf den doppelten Wert eingestellt, der mit der Direktive http2_max_concurrent_streams konfiguriert wurde. Die Begrenzung 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).

Betroffene Produkte

Diese Sicherheitslücke betrifft das NGINX HTTP/2-Modul ( ngx_http_v2_module ). Informationen zu Ihrem spezifischen NGINX- oder F5-Produkt, das möglicherweise betroffen ist, 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 und Zusammenarbeit bei der Identifizierung und Minderung dieser Sicherheitslücke danken.