Ursprünglich veröffentlicht am 29. September 2023 | aktualisiert am 10. Oktober 2023
Von: Dave Andrews, Marcus Hildum, Sergio Ruiz
Update: HTTP/2 Rapid Reset Attack – CVE-2023-44487
Im Anschluss an den kurzen ersten Blog unten hat Edgio mit Kollegen aus der ganzen Branche Kontakt aufgenommen, um CVE-2023-44487 – HTTP/2 Rapid Reset-Angriff zu definieren und verantwortungsbewusst aufzudecken.
Das zugrundeliegende Problem betrifft viele Implementierungen von HTTP/2-Servern, wodurch die Auswirkungen des Angriffs viel breiter sind als Edgio zuvor erkannt hatte. Edgio empfiehlt allen Kunden, die eine öffentliche Infrastruktur betreiben, ein Upgrade auf gepatchte Versionen ihrer Server durchzuführen, sobald diese verfügbar sind, und/oder HTTP/2 vorübergehend zu deaktivieren.
Edgio ist auch verfügbar, um das Risiko für unsere Kunden zu mindern, indem er die HTTP/2-Terminierung durchführt und HTTP/1,1 zurück in die Infrastruktur des Kunden sendet. Bitte wenden Sie sich an uns, um diesen Prozess einzuleiten.
Am 28. August 2023 um 18:43 Uhr, PST, beobachteten die Ingenieure von Edgio eine Zunahme der Speicherauslastung auf unseren Edge-Servern, der Anforderungsraten für mehrere große Web-Eigenschaften und des Volumens an Protokollen, die an der Peripherie generiert wurden.
Der Traffic, der bald als Angriff identifiziert wurde, war neu, weil er nur in den Protokollen unseres Layer 7 Load Balancers zu beobachten war. Edgio führt unsere benutzerdefinierte HTTP-Caching- und Proxying-Engine, Sailfish, sowohl als Layer 7 Load Balancer (den wir als „Frontend“ bezeichnen) als auch als Caching- und Proxying-Ebene (das „Backend“) aus. Dies ermöglicht gemeinsame Instrumentierung und Protokollierung auf beiden Ebenen, wodurch Vergleiche zwischen ihnen trivial sind.
Als wir die Frontend-Protokolle durchforstet haben, haben wir einige interessante Verhaltensweisen beobachtet, die auf einen Angriff hindeuten:
- Die Anzahl der Anfragen für einzelne Clients war weit höher als üblich: Während des Angriffs sahen wir Instanzen mit über 20.000 Anfragen auf einem einzigen Socket.
- Es wurden keine Byte an Clients gesendet.
- Die gesamte Anforderungszeit von Start bis Ende betrug zwischen 1 und 2 Millisekunden, die alle mit der Initiierung einer neuen Proxyverbindung zu den Backends verbracht wurden.
- Alle Verbindungen, die das Verhalten aufwiesen, waren HTTP/2-Verbindungen.
Basierend auf diesen ersten Beobachtungen haben wir die Theorie aufgestellt, dass der Angreifer die Anforderungen mit dem RST_STREAM-Frame von HTTP/2 abbricht und sehr schnell neue Anforderungen auf demselben Socket startet.
Danach gliedern wir unsere Bemühungen in drei unterschiedliche Arbeitsbereiche:
- Untersuchung potenzieller Probleme, die sich auf die von uns verwendete HTTP/2-Bibliothek, nghttp2, auswirken und die die Ursache beweisen könnten.
- Erstellen von Sailfish-Variablen, um die Grundlagen dieses Verhaltens aufzuzeigen und Abhilfemaßnahmen zu ermöglichen.
- Erstellung neuer Metriken, Dashboards und Warnungen, um diese Art von Angriff schneller zu identifizieren.
1. Gesandter… aber wirklich nghttp2
Nach einer kleinen Suche fanden wir in dieser Ausgabe Envoy, einen Service-Proxy, den Edgio nicht am Edge nutzt, und das entsprechende CVE. Bei einer genaueren Prüfung des Diff stellten wir fest, dass dieses Problem nicht nur im Gesandten, sondern auch in nghttp2 liegt, das wir verwenden.
Eine Pull-Anfrage und eine Point-Tag-Veröffentlichung für nghttp2 wurden kurz nach der Offenlegung veröffentlicht, um das zugrunde liegende Problem zu beheben. Das Fehlen eines spezifischen CVE, das nghttp2 zugewiesen wurde, hatte dazu geführt, dass unser automatisiertes CVE-Scansystem, mit dem wir Schwachstellen in der von uns verwendeten Schlüsselsoftware nachverfolgen, das Problem ursprünglich verpasst hat.
Wir haben sofort den Prozess zur Aktualisierung und Bereitstellung dieser Abhängigkeit gestartet, der vor einigen Wochen abgeschlossen wurde.
2. Prozentsatz der Rücksetzung anfordern
Parallel dazu haben wir daran gearbeitet, das Angriffsverhalten innerhalb von Sailfish selbst programmgesteuert zu identifizieren, um sofort Maßnahmen ergreifen zu können, um Leistungs- oder Zuverlässigkeitsprobleme zu vermeiden. Wir haben beschlossen, eine Konfigurationsvariable (h2_Remote_Reset_percent) in Sailfish zu implementieren, die den Prozentsatz der Anforderungen für eine bestimmte Verbindung verfolgt, die vom Client zurückgesetzt wurde.
In Verbindung mit einer vorhandenen Variable für die Anforderungsanzahl für eine einzelne Verbindung konnten wir eine Regel erstellen, die eine Verbindung zu einem Client, der einen Anforderungsschwellenwert überschritten und mehr als einen konfigurierten Prozentsatz von Anforderungen zurückgesetzt hatte, sofort schließen würde. Wir haben diese Konfiguration in normale betriebliche FailSafes verpackt, die es uns ermöglichen, sie für bestimmte Standorte oder Kunden zu deaktivieren.
Im Pseudocode sieht das wie folgt aus:
if request_count > 1000 and
h2_remote_reset_percent > 99 and
pop ~ ".*" and
customer_id not in () then
connection.silent_close();
fi
Nach sorgfältiger Validierung, um unbeabsichtigte Auswirkungen auf den Datenverkehr unserer Kunden zu vermeiden, wurde die neue Regel implementiert, und die Ingenieure von Edgio überwachten weiterhin auf weitere Anomalien.
3. Zählung und Verhältnisse
Um schneller erkennen zu können, wann Angriffe dieser Art stattfinden, haben wir ein neues Dashboard und eine neue Warnung basierend auf der Anzahl der HTTP/2 RST_STREAM-Frames konfiguriert, die von Clients an einem Standort empfangen wurden. Dies, gepaart mit einer einzigartigen Ansicht der Speicherverfügbarkeit und Integritätsprüfungen, gab uns ein klares Signal für eine mögliche Verschlechterung aufgrund dieser speziellen Art von Angriff:
Wir waren jedoch weiterhin besorgt über andere potenzielle Angriffstypen, die sich nur auf die Frontends auswirken könnten. Um dieses allgemeinere Anliegen zu verdeutlichen, haben wir begonnen, das Verhältnis der Transaktionsrate zwischen Frontends und Backends an einem bestimmten Standort zu verfolgen. Die zugrunde liegenden Daten für diesen Vergleich sind seit sehr langer Zeit ein zentraler Bestandteil unserer Überwachung.
Wenn man sich das normale Verhalten ansieht, sieht man das starke Banding um 1, das erwartete Verhältnis, da jede Anforderung, die an einem Front-End ankommt, in eine einzelne Backend-Anforderung überführt wird. Ebenfalls sichtbar ist das Banding näher an 0,5 und 0,25, das in erster Linie an ruhenden Teststandorten auftritt, wo Systeme wie Bereinigung und Integritätsprüfung dazu führen, dass mehr interne Transaktionen von Backends verarbeitet werden:
Während des ersten Angriffs können Sie jedoch die Auswirkungen auf dieses Verhältnis deutlich erkennen:
Unsere aktuellen Warnmeldungen werden so konfiguriert, dass sie ausgelöst werden, wenn das Verhältnis einen bestimmten Wert überschreitet. Dadurch entsteht ein Vorfall für die Support-Techniker von Edgio, der die Schritte zur Schadensbegrenzung auswertet und einleitet.
Zusammenfassung
Dies war ein interessanter neuer Angriffstyp, der eine relativ kürzlich gemeldete Schwachstelle in einer weit verbreiteten Bibliothek nutzte. Glücklicherweise hat das Team von Edgio schnell daran gearbeitet, unser operatives Bewusstsein zu verbessern, die spezifische Ursache des Angriffs zu mindern und generische und anpassbare allgemeine Abwehrmaßnahmen für diese Angriffsklasse einzuführen.
Natürlich arbeiten wir ständig an Verbesserungen wie dieser, z. B. an neuen Möglichkeiten, schlechte Akteure durch Fingerabdrücke zu identifizieren und diese Arbeit in unsere Sicherheitsproduktsuite zu integrieren, um eine dauerhaftere Blockierung und Ratenbegrenzung zu ermöglichen.
Nie einen langweiligen Moment bei Edgio.
Wenn Sie mehr über unseren umfassenden DDoS-Schutz erfahren möchten, der Teil der preisgekrönten WAAP-Lösung (Web Application and API Protection) von Edgio ist, wenden Sie sich bitte an unsere Experten hier.
