HTTP Response Smuggling / Desync
Mbinu ya chapisho hili ilitokana na video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Kupanga Safu ya Ombi la HTTP Desynchronisation
Kwanza kabisa, mbinu hii inatumia udhaifu wa Kupiga Smuggling ya Ombi la HTTP, hivyo unahitaji kujua ni nini hicho:
Tofauti kuu kati ya mbinu hii na kupiga kawaida ya Ombi la HTTP ni kwamba badala ya kushambulia ombi la mwathiriwa kwa kuongeza kipimo, tutakuwa kufichua au kubadilisha majibu anayopokea mwathiriwa. Hii inafanywa kwa kutuma ombi 2 kamili badala ya ombi 1 na nusu kudhoofisha safu za majibu ya wakala.
Hii ni kwa sababu tutaweza kudhoofisha safu ya majibu ili majibu kutoka kwa ombi halali la mwathiriwa yatumwe kwa muhusika, au kwa kuingiza maudhui yanayodhibitiwa na muhusika kwenye majibu kwa mwathiriwa.
Kupanga Safu ya Mpipi ya HTTP
HTTP/1.1 inaruhusu kuomba rasilimali tofauti bila kusubiri zile za awali. Kwa hivyo, ikiwa kuna wakala katikati, ni jukumu la wakala kuhifadhi mechi iliyosawazishwa ya maombi yanayotumwa kwa seva ya nyuma na majibu yanayokuja kutoka kwake.
Walakini, kuna tatizo la kudhoofisha safu za majibu. Ikiwa muhusika anatuma shambulio la Kupiga Smuggling ya Majibu ya HTTP na majibu kwa ombi la awali na lile lililodhoofishwa yanajibiwa mara moja, majibu lililodhoofishwa halitawekwa ndani ya safu ya majibu ya mwathiriwa bali litafutwa tu kama kosa.
Kwa hivyo, ni muhimu kwamba ombi lililodhoofishwa lichukue muda zaidi kusindika ndani ya seva ya nyuma. Kwa hivyo, kufikia wakati ombi lililodhoofishwa linasindika, mawasiliano na muhusika yatakuwa yameisha.
Ikiwa katika hali hii maalum mwathiriwa amepeleka ombi na ombi lililodhoofishwa linajibiwa kabla ya ombi halali, majibu lililodhoofishwa litatumwa kwa mwathiriwa. Kwa hivyo, muhusika atakuwa anadhibiti ombi "lililofanywa" na mwathiriwa.
Zaidi ya hayo, ikiwa muhusika kisha atafanya ombi na majibu halali kwa mwathiriwa yanajibiwa kabla ya ombi la muhusika. Majibu kwa mwathiriwa yatapelekwa kwa muhusika, kuiba majibu kwa mwathiriwa (ambayo inaweza kuwa na kichwa kama vile Set-Cookie).
Uingizaji wa Ndani wa Mara nyingi
Tofauti nyingine ya kuvutia na Kupiga Smuggling ya Kawaida ya Ombi la HTTP ni kwamba, katika shambulio la kawaida la kudhoofisha, ** lengo** ni kubadilisha mwanzo wa ombi la mwathiriwa ili ifanye hatua isiyotarajiwa. Katika shambulio la Kupiga Majibu ya HTTP, kwa kuwa unatuma maombi kamili, unaweza kuingiza kwenye mzigo mmoja majibu kumi ambayo yatakuwa kudhoofisha watumiaji kumi ambao watakuwa wanapokea majibu yaliyoingizwa.
Mbali na kuweza kugawa kwa urahisi zaidi mbinu kumi za kudhoofisha kwa watumiaji halali, hii inaweza pia kutumika kusababisha DoS kwenye seva.
Uendeshaji wa Uvamizi
Kama ilivyoelezwa hapo awali, ili kutumia mbinu hii, ni muhimu kwamba ujumbe wa kwanza uliodhoofishwa ndani ya seva uchukue muda mwingi kusindika.
Hii ombi lenye kuchukua muda ni ya kutosha ikiwa tunataka jaribu kuiba majibu ya mwathiriwa. Lakini ikiwa unataka kufanya uvamizi wenye utata zaidi hii itakuwa muundo wa kawaida kwa uvamizi.
Kwanza kabisa ombi la kwanza likitumia Kupiga Smuggling ya Ombi la HTTP, kisha ombi lenye kuchukua muda na kisha ombi 1 au zaidi la mzigo ambalo majibu yake yatapelekwa kwa waathiriwa.
Kutumia Kupanga Safu ya Majibu ya HTTP Desynchronisation
Kukamata maombi ya watumiaji wengine
Kama ilivyo na mizigo inayojulikana ya Kupiga Smuggling ya Ombi la HTTP, unaweza kuiba ombi la mwathiriwa na tofauti muhimu: Katika kesi hii unahitaji maudhui yaliyotumwa yarudi kwenye majibu, hakuna uhifadhi endelevu unahitajika.
Kwanza, muhusika anatuma mzigo unaotumia **ombi la mwisho la POST lenye kipengele kilichorudiwa mwishoni na Content-Length kubwa
Kisha, mara ombi la awali (buluu) liliposindika na wakati wakati wa kulala unapopita (njano) ombi linalofuata linalofika kutoka kwa mwathiriwa litakuwa kuongezwa kwenye foleni mara baada ya kipengele kilichorudiwa:
Kisha, mwathiriwa atapokea majibu kwa ombi la kulala na ikiwa kati ya wakati huo muhusika alituma ombi lingine, majibu kutoka kwa ombi la maudhui yaliyorudiwa yatatumiwa kwake.
Majibu ya Desynchronisation
Mpaka sasa, tumepata jinsi ya kutumia mashambulio ya Kupiga Smuggling ya Ombi la HTTP kudhibiti ombi ambalo majibu ya mteja ataipokea na jinsi unavyoweza kisha kuiba majibu yaliyokusudiwa kwa mwathiriwa.
Lakini bado inawezekana kudhoofisha hata zaidi majibu.
Kuna maombi ya kuvutia kama ombi la KICHWA ambayo yameelezwa kutokuwa na maudhui yoyote ndani ya mwili wa majibu na inapaswa (lazima) kuwa na Content-Length ya ombi kama kama ilivyokuwa ombi la GET.
Kwa hivyo, ikiwa muhusika anaingiza ombi la KICHWA, kama katika picha hizi:
Kisha, mara ombi la buluu linajibiwa kwa muhusika, ombi la mwathiriwa linalofuata litawekwa kwenye foleni:
Kisha, mwathiriwa atapokea majibu kutoka kwa ombi la KICHWA, ambalo litakuwa na Content-Length lakini hakuna maudhui kabisa. Kwa hivyo, wakala hautatuma majibu haya kwa mwathiriwa, bali utangoja kwa maudhui, ambayo kimsingi yatakuwa majibu kwa ombi la njano (pia lililoingizwa na muhusika):
Utata wa Yaliyomo
Kufuatia mfano uliopita, ukijua kwamba unaweza kudhibiti mwili wa ombi ambalo jibu lake linatarajiwa kupokea na muathiriwa na kwamba jibu la KICHWA kawaida lina Content-Type na Content-Length katika vichwa vyake, unaweza tuma ombi kama lifuatalo ili kusababisha XSS kwa muathiriwa bila ukurasa kuwa na udhaifu wa XSS:
Kuharibu Cache
Kwa kutumia shambulio la Utata wa Yaliyomo la majibu yaliyotangulia, ikiwa cache inahifadhi jibu kwa ombi lililofanywa na muathiriwa na jibu hili ni moja linalosababisha XSS, basi cache imechafuliwa.
Ombi la uovu lenye mzigo wa XSS:
Jibu la uovu kwa muathiriwa linaloonyesha kichwa kinachoelekeza cache kuhifadhi jibu:
Tambua kwamba katika kesi hii ikiwa "muathiriwa" ni mshambuliaji anaweza sasa kufanya kuharibu cache kwa URL za kupindukia kwani anaweza kudhibiti URL itakayohifadhiwa na jibu la uovu.
Udanganyifu wa Cache ya Wavuti
Shambulio hili ni sawa na lile lililopita, lakini badala ya kuingiza mzigo ndani ya cache, mshambuliaji atahifadhi habari za muathiriwa ndani ya cache:
Kugawanya Majibu
Lengo la shambulio hili ni kutumia tena kutofautisha majibu ili kufanya proksi itume majibu yaliyotengenezwa 100% na mshambuliaji.
Ili kufanikisha hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambao unarejea baadhi ya thamani ndani ya majibu na kujua urefu wa yaliyomo ya jibu la KICHWA.
Atatuma kudukua kama:
Baada ya ombi la kwanza kutatuliwa na kutumwa kwa mshambuliaji, ombi la muathiriwa linaongezwa kwenye foleni:
Muathiriwa atapokea kama jibu jibu la KICHWA + yaliyomo ya jibu la pili (yenye sehemu ya data iliyorejelewa):
Hata hivyo, angalia jinsi data iliyorejelewa ilikuwa na ukubwa kulingana na Content-Length ya jibu la KICHWA ambalo lilizalisha jibu la HTTP halali kwenye foleni ya majibu.
Hivyo, ombi la pili la muathiriwa litakuwa likipokea kama jibu kitu kilichoundwa kabisa na mshambuliaji. Kwa kuwa jibu limeundwa kabisa na mshambuliaji, yeye pia anaweza kufanya proksi kuhifadhi jibu.
Last updated
