harley-ghostie/cve-2019-9511_priority-churn-data-dribbleLeichte HTTP/2-Sonden zur kontrollierten Validierung von CVE-2019-9511 (Data Dribble) und CVE-2019-9513 (Priority Churn) DoS-Vektoren in autorisierten Umgebungen.
Repository mit kontrollierten Validierungsskripten für Verhaltensweisen im Zusammenhang mit den CVEs CVE-2019-9511 und CVE-2019-9513, die beide mit Denial-of-Service-Vektoren in HTTP/2-Implementierungen verbunden sind.
Die Skripte wurden erstellt, um technische Validierungen in autorisierten Umgebungen zu unterstützen. Sie ermöglichen die Beobachtung, ob der Server HTTP/2 aushandelt und auf bestimmte Muster im Zusammenhang mit Data Dribble und Priority Churn reagiert, ohne einen Denial-of-Service-Angriff auszuführen.
Ziel ist es, den Vektor auf leichte und sichere Weise nachzuweisen, mit geringem Anfragevolumen und ohne das Ziel, die Umgebung lahmzulegen.
| CVE | Name | Skript | Beschreibung |
|---|
CVE-2019-9511 | HTTP/2 Data Dribble | data_dribble_probe.py | Validiert das Verhalten der HTTP/2-Flusskontrolle durch kontrollierte Freigabe kleiner Datenmengen. |
CVE-2019-9513 | HTTP/2 Priority Churn / Resource Loop | priority_churn_probe.py | Validiert das Verhalten bei der Verarbeitung von PRIORITY-Frames mit geringer Intensität. |
Die CVE-2019-9511, bekannt als HTTP/2 Data Dribble, betrifft einige HTTP/2-Implementierungen, die das Fenstermanagement und die schrittweise Datenauslieferung nicht effizient handhaben.
In diesem Szenario kann ein Angreifer Daten vom Server anfordern und die Flusskontrolle so manipulieren, dass die Antwort offen gehalten und in kleinen Blöcken (z. B. 1‑Byte-Paketen) ausgeliefert wird. Je nach Implementierung kann dieses Verhalten zu übermäßigem CPU‑, Speicher- oder Verbindungsressourcenverbrauch führen, was ein Denial-of-Service-Risiko darstellt.
In diesem Repository ist das zugehörige Skript:
data_dribble_probe.py
Ziel des Skripts ist es, das Verhalten auf leichte Weise zu validieren, ohne aggressive Last zu erzeugen oder eine Nichtverfügbarkeit herbeizuführen.
Referenzen:
Die CVE-2019-9513, bekannt als HTTP/2 Priority Churn oder Resource Loop, betrifft einige HTTP/2-Implementierungen, die kontinuierliche Änderungen im Prioritätsbaum der Streams aufwändig verarbeiten.
In diesem Szenario kann ein Angreifer mehrere Streams erstellen und wiederholt die Priorität zwischen ihnen ändern, was zu Churn im Prioritätsbaum führt. Je nach Implementierung kann dieses Verhalten übermäßigen CPU‑Verbrauch verursachen und zu einem Denial-of-Service führen.
In diesem Repository ist das zugehörige Skript:
priority_churn_probe.py
Ziel des Skripts ist es zu validieren, ob der Server PRIORITY-Frames akzeptiert und verarbeitet – bei geringer Intensität und ohne einen DoS-Angriff auszuführen.
Referenzen:
Die CVEs CVE-2019-9511 und CVE-2019-9513 sind nicht an eine einzige spezifische Version eines Webservers (wie nur nginx, Apache oder Tomcat) gebunden.
Sie betreffen bestimmte HTTP/2-Implementierungen in verschiedenen Produkten, Bibliotheken, Proxys, Load-Balancern und Servern. Daher sollte die Validierung berücksichtigen, welche Komponente im analysierten Umfeld HTTP/2 aushandelt und verarbeitet.
Beispiele für möglicherweise beteiligte Komponenten:
nginx
Apache HTTP Server
Envoy
HAProxy
Tomcat
Jetty
Node.js
Go net/http2
nghttp2
CDN
WAF
Load Balancer
Ingress Controller Kubernetes
Das erste technische Kriterium ist die Bestätigung, ob der Dienst HTTP/2 per ALPN aushandelt. Falls der Dienst kein h2 aushandelt, sind diese Skripte nicht anwendbar.
Die Bestätigung einer Schwachstelle pro Version muss auf Grundlage des offiziellen Advisories des Herstellers der identifizierten Komponente erfolgen.
Führen Sie vor der Ausführung der Skripte eine Validierung durch, ob das Ziel HTTP/2 per ALPN aushandelt.
Verwenden Sie im Befehl nur die Domain, ohne https://.
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
Auch mit Platzhalter möglich:
openssl s_client -alpn h2 -connect <HOST>:443 </dev/null 2>/dev/null | grep -i "ALPN"
Erwartete Ausgabe:
ALPN protocol: h2
Wenn die Ausgabe h2 anzeigt, handelt der Dienst HTTP/2 aus, und die Skripte können anwendbar sein.
Wenn keine Rückmeldung erfolgt oder das ausgehandelte Protokoll ein anderes ist (z. B. http/1.1), sind die Skripte für diesen Endpunkt nicht anwendbar.
| Skript | Zugehörige CVE | Zweck | Wann verwenden |
|---|---|---|---|
data_dribble_probe.py | CVE-2019-9511 | Validierung des Data‑Dribble-Verhaltens mittels Fensterkontrolle zur Freigabe kleiner Datenblöcke | Wenn der Server HTTP/2 unterstützt und das Verhalten der DATA‑Frame-Auslieferung mit reduziertem Fenster überprüft werden soll. |
priority_churn_probe.py | CVE-2019-9513 | Validierung des Priority‑Churn-Verhaltens mittels PRIORITY-Frames bei geringer Intensität | Wenn der Server HTTP/2 unterstützt und geprüft werden soll, ob er Prioritätsänderungen von Streams verarbeitet. |
Die logischste Reihenfolge zur Verwendung der Skripte ist:
1. HTTP/2-Vorvalidierung mit openssl
↓
2. priority_churn_probe.py
↓
3. data_dribble_probe.py
Verwenden Sie zuerst den Befehl mit openssl, um zu bestätigen, dass das Ziel HTTP/2 aushandelt. Verwenden Sie dann priority_churn_probe.py, um zu validieren, ob der Server Prioritäts-Frames akzeptiert und verarbeitet. Verwenden Sie anschließend data_dribble_probe.py, um das Serververhalten bei reduziertem Flussfenster zu beobachten, indem kleine Datenmengen kontrolliert freigegeben werden.
Beide Skripte sind leichte Sonden. Sie zielen nicht darauf ab, eine Nichtverfügbarkeit herbeizuführen, sondern einen technischen Nachweis des beobachteten Verhaltens zu erbringen.
priority_churn_probe.py ist eine leichte PoC zur Validierung des Verhaltens im Zusammenhang mit CVE-2019-9513, bekannt als HTTP/2 Priority Churn.
Das Skript stellt eine HTTP/2-Verbindung per TLS her, öffnet kleine HTTP-Streams und sendet Prioritätsänderungen mittels PRIORITY-Frames. Anschließend misst es die Latenz vor und nach dem Senden dieser Frames, um festzustellen, ob es eine Verarbeitungsvariation gibt.
PING;PRIORITY-Frames mit geringer Intensität;Verwenden Sie dieses Skript, wenn validiert werden muss, ob ein HTTP/2-Server Prioritäts-Frames im Zusammenhang mit dem Priority Churn-Vektor akzeptiert und verarbeitet – ohne einen aggressiven DoS-Test durchzuführen.
Es eignet sich für kontrollierte Validierungen in Pentests, HTTP/2-Expositionsanalysen und den technischen Nachweis eines anfälligen oder potenziell sensiblen Verhaltens.
Das Skript erhält die Werte über Kommandozeilenargumente:
--host
--port
--paths
--shuffles
| Parameter | Beschreibung |
|---|---|
--host | FQDN des autorisierten Ziels. Kein https:// einfügen. |
--port | TLS-Port, auf dem der HTTP/2-Dienst verfügbar ist. Standard: 443. |
--paths | Liste einfacher Pfade zum Öffnen von HTTP/2-Streams. |
--shuffles | Anzahl der Zyklen von Prioritätsänderungen. Für einen sicheren Test niedrig halten. |
Verwenden Sie leichte, öffentliche und wenig belastende Pfade wie:
/
/robots.txt
/favicon.ico
/health
/login
Vermeiden Sie Pfade, die schwere Operationen, komplexe Abfragen, Berichtserstellung, Uploads, erweiterte Suche oder andere Backend-lastige Funktionen ausführen.
python3 priority_churn_probe.py --host exemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
Beispielausgabe:
[OK] PING vorher: 45.20 ms; nach Churn: 52.80 ms; shuffles=10
Signal 9513: PRIORITY-Frames akzeptiert und verarbeitet; leichter Anstieg nach Churn belegt den Vektor (ohne DoS).
Wenn das Skript HTTP/2 aushandeln, Streams öffnen und PRIORITY-Frames senden kann, zeigt dies, dass der Server diese Art von Verhalten verarbeitet.
Ein leichter Anstieg der Latenz nach dem Churn kann als technischer Nachweis für das Vorhandensein des Vektors verwendet werden, sollte aber nicht allein als Beleg für eine schwerwiegende Auswirkung interpretiert werden. Die endgültige Einstufung hängt vom Kontext, der Serverversion, der Architektur, den mitigierenden Maßnahmen, WAF/CDN und der HTTP/2-Konfiguration ab.
data_dribble_probe.py ist eine leichte PoC zur Validierung des Verhaltens im Zusammenhang mit CVE-2019-9511, bekannt als HTTP/2 Data Dribble.
Das Skript stellt eine HTTP/2-Verbindung per TLS her, öffnet einen einzelnen Stream und manipuliert das Flusskontrollfenster, um kleine Datenmengen freizugeben und so das Verhalten der schrittweisen Auslieferung von DATA-Frames zu simulieren.
Verwenden Sie dieses Skript, wenn validiert werden muss, ob der HTTP/2-Server auf ein Muster reduzierter Flusskontrolle im Zusammenhang mit dem Data Dribble-Vektor reagiert – ohne aggressive Last zu erzeugen.
Es eignet sich für kontrollierte technische Nachweise, insbesondere wenn automatisierte Tools auf eine mögliche Exposition hinweisen und eine manuelle Validierung mit geringerem Betriebsrisiko erforderlich ist.
Das Skript erhält die Werte über Kommandozeilenargumente:
--host
--path
--port
--bytes
| Parameter | Beschreibung |
|---|---|
--host | FQDN des autorisierten Ziels. Kein https:// einfügen. |
--path | Pfad, der im Test angefordert wird. |
--port | TLS-Port, auf dem der HTTP/2-Dienst verfügbar ist. Standard: 443. |
--bytes | Gesamtzahl der während des Tests freigegebenen Bytes. Für eine sichere Validierung niedrig halten. |
Verwenden Sie einen einfachen, statischen oder für den Server kostengünstigen Pfad, wie z. B.:
/
/robots.txt
/favicon.ico
/health
/login
Vermeiden Sie Endpunkte, die Datenbankabfragen, schwere Authentifizierung, asynchrone Verarbeitung, Dokumentenerstellung oder Aufrufe interner Systeme durchführen.
python3 data_dribble_probe.py --host exemplo.com.br --path / --port 443 --bytes 12
Beispielausgabe:
[OK] HTTP/2 ausgehandelt; empfangene DATA-Frames: 12; freigegebene Bytes: 12; Zeit(ms): 1450
Signal 9511: mehrere winzige DATA unter Fenster=1 ausgeliefert (Nachweis des 'Dribble'-Pfads ohne Stress).
Wenn das Skript HTTP/2 aushandelt und kleine DATA-Frames gemäß der Freigabe des Flussfensters empfängt, zeigt dies, dass der Server dieses Flusskontrollmuster verarbeitet.
Dieses Verhalten kann als technischer Nachweis für den Vektor verwendet werden, aber die Kritikalität sollte den tatsächlichen Kontext der Umgebung berücksichtigen, wie verwendeten Server, Version, Verbindungsgrenzen, Load-Balancer, CDN, WAF, Timeout und Missbrauchsschutzmaßnahmen.
Die Skripte erfordern Python 3 und die Bibliothek h2.
python3
pip
h2
ssl
socket
argparse
Die Bibliotheken ssl, socket, time, argparse und select sind Teil der Python-Standardbibliothek.
Die wichtigste externe Abhängigkeit ist:
h2
Direkte Installation:
python3 -m pip install h2
Installation mit virtueller Umgebung:
python3 -m venv venv
source venv/bin/activate
pip install h2
Installation validieren:
python3 -c "import h2; print('h2 erfolgreich installiert')"
Die Skripte sind auf die HTTP/2-Aushandlung per ALPN angewiesen.
Bestätigen Sie vor der Ausführung, ob der Server HTTP/2 unterstützt:
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
Erwartete Ausgabe:
ALPN protocol: h2
Wenn der Server kein h2 aushandelt, sind die Skripte nicht anwendbar.
--host verwendenGeben Sie https:// nicht im Parameter --host an.
Richtig:
--host exemplo.com.br
Falsch:
--host https://exemplo.com.br
Bevorzugen Sie einfache Pfade:
/
/robots.txt
/favicon.ico
/health
Vermeiden Sie sensible oder lastintensive Endpunkte:
/relatorios
/export
/search
/upload
/api/processamento
Ziel ist es, das HTTP/2-Verhalten zu validieren, nicht das Backend zu belasten.
Verwenden Sie konservative Werte:
Für priority_churn_probe.py:
--shuffles 10
Für data_dribble_probe.py:
--bytes 12
Erhöhen Sie diese Werte in einer Produktionsumgebung nicht ohne ausdrückliche Genehmigung.
openssl s_client -alpn h2 -connect exemplo.com.br:443 </dev/null 2>/dev/null | grep -i "ALPN"
python3 priority_churn_probe.py --host exemplo.com.br --port 443 --paths / /robots.txt /favicon.ico --shuffles 10
python3 data_dribble_probe.py --host exemplo.com.br --path / --port 443 --bytes 12
Um Risiken im Zusammenhang mit HTTP/2-DoS-Angriffen zu reduzieren, wird empfohlen, Webserver, Proxys, Load-Balancer und HTTP/2-Bibliotheken auf dem neuesten Stand zu halten, Verbindungslimits festzulegen, angemessene Timeouts zu konfigurieren, die Anzahl gleichzeitiger Streams zu begrenzen, Missbrauch von HTTP/2-Frames einzuschränken, Latenzanomalien zu überwachen und die Deaktivierung von HTTP/2 in Diensten, die dieses Protokoll nicht benötigen, zu evaluieren.
Es wird auch empfohlen, den Schutz in Schichten wie CDN, WAF, Reverse Proxy, Ingress Controller und Load Balancer zu validieren, da die tatsächliche Exposition oft eher von der Edge als von der endgültigen Anwendung abhängt.
Die Bestätigung einer Korrektur sollte auf Basis der Komponente erfolgen, die HTTP/2 in der Umgebung tatsächlich terminiert und verarbeitet, wie Webserver, Proxy, Load Balancer, CDN oder Ingress Controller.
Diese Skripte dürfen nur in autorisierten Umgebungen verwendet werden.
Obwohl sie für eine leichte Ausführung geschrieben wurden, interagieren sie direkt mit HTTP/2-Mechanismen, die mit DoS-Vektoren in Verbindung stehen. Daher muss die Nutzung mit dem formalen Testumfang, den Engagement-Regeln und den vom Verantwortlichen der Umgebung festgelegten Betriebsgrenzen übereinstimmen.
Bestätigen Sie vor der Ausführung in der Produktion:
Die Verwendung dieser Skripte gegen Systeme ohne Autorisierung ist verboten.
Der Zweck dieses Repositorys ist ausschließlich die Unterstützung legitimer Sicherheitsaktivitäten wie autorisierte Pentests, kontrollierte Schwachstellenvalidierung, Laborarbeit, technische Studien und sichere Risikodemonstration.