Útok na front-end-back-end systémy, který nám umožňuje vklínit se do požadavků třetích stran

Odhaleno podrobnosti o novém útoku na weby, které používají model front-end-back-end, jako jsou ty, které běží přes sítě pro doručování obsahu, nástroje pro vyrovnávání zatížení nebo servery proxy. Útok umožňuje odesláním určitých požadavků vklínit se do obsahu jiných požadavků zpracovávaných ve stejném vlákně mezi frontend a backend. Navržená metoda byla úspěšně použita k organizaci útoku, který umožnil zachytit autentizační parametry uživatelů služby PayPal, která výzkumníkům zaplatila zhruba 40 tisíc dolarů v rámci programu informujícího o přítomnosti neopravených zranitelností. Útok se vztahuje i na stránky využívající síť pro doručování obsahu Akamai.

Jádro problému je v tom, že frontendy a backendy často poskytují různé úrovně podpory protokolu HTTP, ale zároveň zapouzdřují požadavky od různých uživatelů do společného kanálu. Pro spojení frontendu přijímajícího požadavky a backendu zpracovávajících požadavky je navázáno dlouhodobé TCP spojení, přes které jsou přenášeny požadavky uživatelů, přenášené po řetězci, oddělené pomocí protokolu HTTP. K oddělení požadavků slouží hlavičky „Content-Length“ (určuje celkovou velikost dat v požadavku) a „Transfer-Encoding: chunked"(umožňuje přenášet data po částech s uvedením bloků různých velikostí ve formátu "{velikost}\r\n{blok}\r\n{velikost}\r\n{blok}\r\n0").

Problém nastává, pokud frontend podporuje pouze „Content-Length“, ale ignoruje „Transfer-Encoding: chunked“ (to udělal například Akamai CDN) nebo naopak. Pokud je na obou stranách podporováno Transfer-Encoding: chunked, lze pro útok použít implementační funkce analyzátorů hlaviček HTTP (například když frontend ignoruje řádky jako „Transfer-Encoding: xchunked“, „Transfer-Encoding: chunked“ "", "Kódování přenosu" :[tab]chunked", "X: X[\n]Kódování přenosu: kusové", "Kódování přenosu[\n]: kusové" nebo "Kódování přenosu: kusové" a backend je úspěšně zpracuje).

V tomto případě může útočník odeslat požadavek, který obsahuje hlavičky „Content-Length“ i „Transfer-Encoding: chunked“, ale velikost v „Content-Length“ neodpovídá velikosti chunkovaného řetězce, což je menší než skutečná hodnota. Pokud frontend zpracuje a přepošle požadavek podle "Délka obsahu" a backend čeká na dokončení bloku na základě "Přenos-kódování: chunked", pak bude konec dat založený na "Přenosové kódování: chunked" být určen dříve a zbývající část žádosti bude útočník na začátku další žádosti, tzn. útočník bude moci připojit libovolná data na začátek požadavku někoho jiného přenášeného jako další.

Chcete-li zjistit problém v použité kombinaci frontend-backend, můžete odeslat požadavek takto:

POST /o HTTP/1.1
Hostitel: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Problém nastává, pokud backend okamžitě nezpracuje požadavek a čeká na příchod posledního nulového ohraničujícího bloku chunked dat. Pro úplnější kontrolu připravený speciální nástroj, který také testuje možné metody pro skrytí hlavičky „Transfer-Encoding: chunked“ z frontendu.

Provedení skutečného útoku závisí na možnostech napadeného webu, například při útoku na webovou aplikaci Trello můžete nahradit začátek požadavku (nahraďte údaje jako „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) a odešlete zprávu obsahující původní požadavek uživatele třetí strany a v něm uvedený ověřovací soubor cookie. U útoku na saas-app.com se ukázalo, že je možné v odpovědi nahradit kód JavaScriptu jeho nahrazením v jednom z parametrů požadavku. Pro útok na redhat.com byl použit interní handler k přesměrování na útočníkův web (požadavek ve tvaru „POST /search?dest=../assets/idx?redir=//[chráněno e-mailem]/ HTTP/1.1").

Použití metody pro sítě pro doručování obsahu umožnilo jednoduše nahradit požadovaný web nahrazením záhlaví „Host:“. Útok lze také použít k otravě obsahu systémů pro ukládání obsahu do mezipaměti a extrahování důvěrných dat uložených v mezipaměti. Vrcholem metody byla organizace útoku na PayPal, která umožnila zachytit hesla zaslaná uživateli při autentizaci (požadavek iframe byl upraven tak, aby spouštěl JavaScript v kontextu stránky paypal.com/us/gifts, např. který CSP (Content Security Policy) nebyl použit).

Zajímavé je, že v roce 2005 došlo navrženo v podstatě podobná technika falšování požadavků, která vám umožňuje falšovat data v mezipaměti proxy (Tomcat, squid, mod_proxy) nebo obejít blokování firewallu zadáním několika požadavků „GET“ nebo „POST“ v rámci jedné relace HTTP.

Zdroj: opennet.ru