neex/http2smuglErkennt und nutzt HTTP-Request-Smuggling-Schwachstellen über HTTP/2-zu-HTTP/1.1-Konvertierung aus, mithilfe automatisierter Header-Smuggling-Techniken, um Backend-Parsing-Diskrepanzen zu identifizieren.
Dieses Tool hilft dabei, HTTP-Request-Smuggling zu erkennen und auszunutzen, wenn dies durch die Konvertierung von HTTP/2 -> HTTP/1.1 durch den Frontend-Server erreicht werden kann.
Das Schema ist wie folgt:
Der Angreifer möchte eine solche Anfrage finden, die vom Backend-Server als zwei separate Anfragen angesehen wird.
Wenn die Frontend<->Backend-HTTP/1.1-Verbindung Keep-Alive verwendet, könnte das Frontend Anfragen anderer Benutzer an dieselbe Verbindung senden. Wenn wir in der Lage sind, die Verbindung durch eine Teil-Anfrage zu „vergiften“, die nach einer legitimen kommt, können wir die Anfrage eines anderen Benutzers abgreifen.
Andere mögliche Szenarien umfassen das Umgehen von Frontend-Serverschutz und Umschreibungen, Cache-Poisoning oder Cache-Deception.
Weitere Informationen zu HTTP-Request-Smuggling finden Sie in der Portswigger Web Security Academy.
In HTTP/2 sind alle HTTP-Headernamen und -Werte binär. Daher können sie technisch gesehen zusätzliche Leerzeichen oder sogar Zeilenumbrüche enthalten.
RFC7540#10.3 besagt, dass Implementierungen, die HTTP/2-Anfragen in HTTP/1 konvertieren, die Einschränkungen des Zeichensatzes berücksichtigen müssen, die sich aus einer solchen Konvertierung ergeben; die meisten Implementierungen lehnen sie tatsächlich ab. Trotzdem hoffen wir, solche zu finden, die solche Header zulassen. Sie werden die konvertierte HTTP/1.1-Anfrage an das Backend verfälschen.
Ein weiterer Punkt ist, dass einige aktuelle Korrekturen im Zusammenhang mit HTTP-Request-Smuggling möglicherweise nur für HTTP/1.1-Parser implementiert wurden.
Im Allgemeinen hoffen wir, dass es Implementierungen von HTTP/2 gibt, die nicht sehr mit der aktuellen Forschung zu HTTP-Request-Smuggling in HTTP/1.1 vertraut sind und keine entsprechenden Gegenmaßnahmen enthalten.
Überraschenderweise ja!
Ich habe eine Möglichkeit gefunden, einen Header mit einem Leerzeichen durch Cloudflare zu schmuggeln und damit eine Tür für Cloudflare<->Client-Smuggling zu öffnen (falls die Software eines Cloudflare-Clients Headernamen akzeptiert und kürzt). Hier ist der Blogbeitrag.
Es gibt auch einen weiteren Bug-Bounty-Bericht, der noch nicht öffentlich ist. Er nutzt die Tatsache, dass eine benutzerdefinierte Software keine Zeilenumbrüche in HTTP2-Headern herausfiltert, und das Schmuggeln findet zu 100 % statt (ich kann Anfragen anderer Benutzer sehen).
Ich verstehe jedoch, dass diese Art von Schwachstellen frustrierend selten sein muss: Anders als bei HTTP/1.1 gibt es nicht so viele HTTP/2-Implementierungen, und die meisten sind sicherheitstechnisch entwickelt, sodass verdächtige oder ungültige Header abgelehnt werden.
Das Tool verfügt über einen Unterbefehl, der automatisch zu erkennen versucht, ob ein Ziel anfällig für den HTTP-Request-Smuggling-Angriff ist. Der Algorithmus hinter dieser Funktion wird in diesem Abschnitt beschrieben.
Um einen HTTP-Request-Smuggling-Angriff durchzuführen, müssen wir tatsächlich zuerst einen einzelnen Header schmuggeln (entweder Content-Length oder Transfer-Encoding). Das bedeutet, wir müssen einen Header senden, der a) steuert, wo der Anfragetext endet, und b) nicht vom Frontend verarbeitet, aber vom Backend verarbeitet wird.
Dies wird normalerweise erreicht, indem ein Header auf bestimmte Weise modifiziert wird: Anhängen von Leerzeichen oder Tabs an das Ende seines Namens, Ersetzen des Werts durch ein semi-Äquivalent usw.
Die Grundidee des Algorithmus zur Erkennung von Schwachstellen besteht darin, zu erkennen, ob der Server tatsächlich einen geschmuggelten Header so verarbeitet, als wäre er Content-Length oder Transfer-Encoding. Wir tun dies, indem wir mehrere Anfragen senden: einige mit gültigen und andere mit ungültigen Werten für den Header. Dann versuchen wir zu erkennen, ob es eine Möglichkeit gibt, die Antworten dieser beiden Gruppen zu unterscheiden.
Deshalb enthält die Ausgabe des Tools nicht die Wörter „anfällig/nicht anfällig“: Es sagt lediglich, ob es Antworten unterscheiden kann, die auf die Anfragen dieser beiden Gruppen kamen.
Das Tool betrachtet zwei Sätze von HTTP-Antworten als unterscheidbar, wenn mindestens eine der folgenden beiden Bedingungen erfüllt ist:
Die Timeouts werden als einzigartiger Statuscode-Wert behandelt, der keinem anderen gleicht; daher hebt das Tool das klassische „Erkennung durch Timing“-Schema auf.
Betrachten wir ein Beispiel. Angenommen, wir versuchen, den transfer-encoding-Header zu schmuggeln, indem wir den Bindestrich durch einen Unterstrich ersetzen.
Wenn es scheint, dass der Server mit Status 400 antwortet, jedes Mal wenn wir transfer_encoding:zalupa senden, und hängt, wenn es transfer_encoding:chunked ist, können wir sagen, dass der Server den Header wahrscheinlich als Wert für Transfer-Encoding verarbeitet. Theoretisch könnte es entweder der Frontend- oder der Backend-Server sein.
Der erste Fall ist nicht interessant, da wir die nicht geschmuggelte Version des Headers ohnehin senden könnten, und der zweite Fall ist das, wonach wir suchen. Da alles über HTTP/2 läuft, ist der erste Fall meist vermeidbar: Der HTTP/2-Server bestimmt das Ende des Anfragetextes auf andere Weise, die nichts mit den Anfrage-Headern zu tun hat, und erwartet nie, dass der Text im chunked-Format von HTTP/1.1 (dem mit hexadezimalen Chunk-Längen) vorliegt.
Die konkreten Variationen der Erkennungstechniken sind:
Wir senden eine geschmuggelte Version von Transfer-Encoding: chunked (z. B. transfer_encoding:chunked) und verschiedene Textkörper: gültig ist 0\r\n\r\n und ungültig ist 999\r\n.
Falls die Antworten unterschiedlich sind, können wir sicher sein, dass der Backend-Server den geschmuggelten Header empfängt und verarbeitet. Es gibt keinen Grund für das Frontend, dies zu tun: HTTP/2 verwendet nicht das von uns gesendete chunked-Format, sodass es ungültig wäre.
Wir erwarten, dass das Backend für die ungültigen Anfragen hängt (d. h. die Anfrage führt zu einem Timeout), da es auf weitere Daten wartet.
Dies ist die zuverlässigste Erkennungsvariante: Wenn der Server beim Lesen des Textkörpers hängt, ist wahrscheinlich etwas schiefgelaufen, da es keine Verwendung für HTTP/1.1-Transfer-Encoding in einer HTTP/2-Anfrage gibt.
Wir senden erneut eine geschmuggelte Version von Transfer-Encoding und verschiedene Textkörper: 0\r\n\r\n als gültigen Text und X\r\n\r\n als ungültigen.
Der Fall ist derselbe wie oben, aber statt den Text zu lesen, erwarten wir, dass das Backend ihn zumindest validiert.
Wir senden eine geschmuggelte Version des Content-Length-Headers mit den Werten 1 und -1.
Beide Werte sind aus Sicht des Frontends ungültig: Es gibt einen anderen Mechanismus zur Bestimmung der Textlänge in HTTP/2, und in beiden Fällen wird kein Anfragetext gesendet. Wenn die Antworten unterschiedlich sind, nehmen wir an, dass der Backend-Server die Header geparst hat.
Diese Methode ist die am wenigsten zuverlässige: Das Frontend könnte unterschiedliche Fehler ausgeben, wenn Content-Length einen ungültigen Wert hat, und wenn er nicht mit der tatsächlichen Länge übereinstimmt.
