Die Websysteme, bei denen das Frontend Verbindungen über HTTP akzeptiert / 2 und übergibt sie per HTTP / 1.1 h . an das Backendeiner neuen Version des Angriffs "HTTP Request Smuggling" ausgesetzt waren, Es ermöglicht durch das Senden speziell entwickelter Client-Anfragen, den Inhalt der Anfragen anderer Benutzer aufzuteilen, die im gleichen Fluss zwischen dem Frontend und dem Backend verarbeitet werden.
Der Angriff kann verwendet werden, um bösartigen JavaScript-Code einzuschleusen in einer Sitzung mit einer legitimen Site, um Zugangsbeschränkungssysteme zu umgehen und Authentifizierungsparameter abzufangen.
Der Autor der Studie demonstrierte die Möglichkeit eines Angriffs auf Netflix-, Verizon-, Bitbucket-, Netlify CDN- und Atlassian-Systeme, und erhielt 56.000 US-Dollar an Belohnungsprogrammen für die Identifizierung von Schwachstellen. Das Problem wurde auch in F5 Networks-Produkten bestätigt.
Das Problem wirkt sich teilweise auf mod_proxy auf dem Apache http-Server aus (CVE-2021-33193), Korrekturen in Version 2.4.49 erwartet (Entwickler wurden Anfang Mai über das Problem informiert und erhielten 3 Monate Zeit, um es zu beheben). In nginx war die Möglichkeit, gleichzeitig die Header "Content-Length" und "Transfer-Encoding" anzugeben, in der Vorgängerversion (1.21.1) blockiert.
Das Funktionsprinzip der neuen Methode der übereinstimmenden Anfragen im Verkehr ähnelt der Schwachstelle, die derselbe Forscher vor zwei Jahren entdeckt hat, aber es ist auf Schnittstellen beschränkt, die Anfragen über HTTP / 1.1 akzeptieren.
Der klassische „HTTP Request Smuggling“-Angriff basierte darauf, dass Frontends und Backends die Verwendung von HTTP „Content-Length“-Headern unterschiedlich interpretieren (bestimmt die Gesamtgröße der Daten in der Anfrage) und „Transfer-Encoding: chunked“ ( ermöglicht die Übertragung von Daten in Blöcken) ...
Wenn die Schnittstelle beispielsweise nur "Content-Length" unterstützt, aber "Transfer-Encoding: fragmented" ignoriert, kann ein Angreifer eine Anfrage senden, die die Header "Content-Length" und "Transfer-Encoding: fragmented" enthält, aber die Größe de Die "Länge des Inhalts" stimmt nicht mit der Größe des gestückelten Strings überein. In diesem Fall verarbeitet und leitet das Frontend die Anfrage entsprechend der "Inhaltslänge" um und das Backend wartet auf den Abschluss des Blocks basierend auf der "Übertragungscodierung: chunked".
Im Gegensatz zum textuellen HTTP / 1.1-Protokoll, das auf Zeilenebene geparst wird, HTTP / 2 ist ein binäres Protokoll und manipuliert Blöcke Daten einer vorgegebenen Größe. Allerdings HTTP / 2 Pseudo-Header verwenden die normalen HTTP-Headern entsprechen. Bei der Interaktion mit dem Backend unter Verwendung des HTTP / 1.1-Protokolls, das Frontend übersetzt diese Pseudo-Header in ähnlichen HTTP / 1.1 HTTP-Headern. Das Problem ist, dass das Backend Entscheidungen über die Analyse der Übertragung trifft basierend auf den vom Frontend gesetzten HTTP-Headern, ohne die Parameter der ursprünglichen Anfrage zu kennen.
Auch in Form von Pseudo-Headern werden die Werte "Content-Länge" und "Transfer-Encoding" sie können gestreamt werden, obwohl sie in HTTP/2 nicht verwendet werden, da die Größe aller Daten in einem separaten Feld bestimmt wird. Beim Konvertieren einer HTTP/2-Anfrage in HTTP/1.1 werden diese Header jedoch durchgereicht und können das Backend verwirren.
Es gibt zwei Hauptangriffsoptionen: H2.TE und H2.CL, bei dem das Backend durch eine falsche Übertragungscodierung oder einen Inhaltslängenwert getäuscht wird, der nicht der tatsächlichen Größe des vom Frontend über das HTTP/2-Protokoll empfangenen Request-Bodys entspricht.
Als Beispiel für den H2.CL-Angriff wird im Pseudo-Header eine falsche Größe angegeben Inhaltslänge beim Senden einer Anfrage HTTP / 2 zu Netflix. Diese Anfrage führt zum Hinzufügen eines Headers HTTP-Inhaltslänge ähnlich beim Zugriff auf das Backend über HTTP / 1.1, aber da die Größe in Inhaltslänge kleiner als der tatsächliche ist, wird ein Teil der Daten in der Warteschlange als Beginn der nächsten Anfrage verarbeitet.
Angriffswerkzeuge wurden bereits zu Burps Toolkit hinzugefügt und sind als Turbo Intruder-Erweiterung verfügbar. Anfällig für das Problem sind Web-Proxys, Load Balancer, Web-Beschleuniger, Content Delivery-Systeme und andere Konfigurationen, bei denen Anfragen in einem Front-End-Back-End-Schema umgeleitet werden.
Quelle: https://portswigger.net