8.9 KiB
Kujibu Kwa Kupokea Kwa HTTP / Desync
Jifunze kuhusu kuvamia AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!
Njia nyingine za kusaidia HackTricks:
- Ikiwa unataka kuona kampuni yako ikitangazwa kwenye HackTricks au kupakua HackTricks kwa PDF Angalia MIPANGO YA KUJIUNGA!
- Pata bidhaa rasmi za PEASS & HackTricks
- Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs
- Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.
- Shiriki mbinu zako za kuvamia kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud github repos.
Mbinu ya chapisho hili ilitolewa kutoka kwenye video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Kupotosha Safu ya Ombi la HTTP
Kwanza kabisa, mbinu hii inatumia udhaifu wa Kupotosha Ombi la HTTP, kwa hivyo unahitaji kujua ni nini hicho:
Tofauti kuu kati ya mbinu hii na kupotosha kawaida ya ombi la HTTP ni kwamba badala ya kushambulia ombi la mwathiriwa kwa kuongeza kipimo kwake, tutakuwa kufichua au kubadilisha jibu ambalo mwathiriwa anapokea. Hii inafanywa kwa kutuma ombi 2 kamili badala ya ombi na nusu kwa kufanya upotoshaji wa ombi la HTTP, tuma ombi 2 kamili kwa kudharau safu za majibu ya wakala.
Hii ni kwa sababu tutaweza kupotosha safu ya majibu ili jibu kutoka kwa ombi halali la mwathiriwa litumwe kwa muovu, au kwa kuingiza maudhui yanayodhibitiwa na muovu kwenye jibu kwa mwathiriwa.
Kupotosha Safu ya Mpipa 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 kupotosha safu za majibu. Ikiwa muovu anatuma shambulio la Kupotosha Majibu ya HTTP na majibu kwa ombi la awali na lile lililopotoshwa yanajibiwa mara moja, jibu lililopotoshwa halitawekwa ndani ya safu ya jibu la mwathiriwa lakini litakuwa tu linatupiliwa mbali kama kosa.
Kwa hivyo, ni muhimu kwamba ombi lililopotoshwa linachukua muda zaidi kusindika ndani ya seva ya nyuma. Kwa hivyo, kufikia wakati ombi lililopotoshwa linasindika, mawasiliano na muovu yatakuwa yameisha.
Ikiwa katika hali hii maalum mwathiriwa amepeleka ombi na ombi lililopotoshwa linajibiwa kabla ya ombi halali, jibu lililopotoshwa litatumwa kwa mwathiriwa. Kwa hivyo, muovu atakuwa anadhibiti ombi "lililofanywa" na mwathiriwa.
Zaidi ya hayo, ikiwa muovu kisha atafanya ombi na jibu halali kwa mwathiriwa linajibiwa kabla ya ombi la muovu. Jibu kwa mwathiriwa litatumwa kwa muovu, kuiba jibu kwa mwathiriwa (ambalo linaweza kuwa na kichwa kama vile Set-Cookie).
Uingizaji wa Ndani wa Mara nyingi
Tofauti nyingine ya kuvutia na Kupotosha Kawaida ya Ombi la HTTP ni kwamba, katika shambulio la kawaida la kupotosha, ** lengo** ni kubadilisha mwanzo wa ombi la mwathiriwa ili ifanye hatua isiyotarajiwa. Katika shambulio la Kupotosha Majibu ya HTTP, kwa kuwa unatuma maombi kamili, unaweza kuingiza kwenye mzigo mmoja majibu kadhaa ambayo yatakuwa kupotosha mamia ya watumiaji ambao watakuwa wanapokea majibu yaliyoingizwa.
Mbali na kuweza kugawa kwa urahisi majibu kadhaa kwa watumiaji halali, hii inaweza pia kutumika kusababisha DoS kwenye seva.
Uendeshaji wa Shambulio
Kama ilivyoelezwa hapo awali, ili kutumia mbinu hii, ni muhimu kwamba ujumbe wa kwanza uliopotoshwa ndani ya seva unachukua muda mwingi kusindika.
Hii ombi lenye kuchukua muda ni ya kutosha ikiwa tunataka jaribu kuiba jibu la mwathiriwa. Lakini ikiwa unataka kufanya shambulio lenye utata zaidi hii itakuwa muundo wa kawaida wa shambulio.
Kwanza kabisa ombi la kwanza likitumia Kupotosha Ombi la HTTP, kisha ombi lenye kuchukua muda na kisha ombi 1 au zaidi la mzigo ambalo majibu yake yatatumiwa kwa waathiriwa.
Kutumia Kupotosha Safu ya Majibu
Kukamata maombi ya watumiaji wengine
Kama ilivyo na malipo yaliyofahamika ya Kupotosha Ombi la HTTP, unaweza kuiba ombi la mwathiriwa na tofauti muhimu: Katika kesi hii unahitaji maudhui yaliyotumwa yarudi kwenye jibu, hakuna uhifadhi endelevu unahitajika.
Kwanza, muovu anatuma mzigo unaotumia ombi la mwisho la POST na parameta iliyorudiwa mwishoni na Content-Length kubwa
Kisha, mara tu ombi la awali (buluu) liliposindika na wakati wakati ombi lenye usingizi linasindika (njano) ombi linalofuata linalofika kutoka kwa mwathiriwa litakuwa kuongezwa kwenye foleni mara baada ya parameta iliyorudiwa:
Kisha, mwathiriwa atapokea jibu kwa ombi lenye usingizi na ikiwa kwa wakati huo muovu alituma ombi lingine, jibu kutoka kwa ombi la maudhui lililorudiwa litatumwa kwake.
Kupotosha Majibu
Mpaka sasa, tumepata jinsi ya kutumia mashambulio ya Kupotosha Ombi la HTTP kudhibiti ombi ambalo jibu mteja atapokea na jinsi unavyoweza kisha kuiba jibu lililokusudiwa kwa mwathiriwa.
Lakini bado inawezekana kupotosha 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) iwe na Content-Length ya ombi kama kama ilivyokuwa ombi la GET.
Kwa hivyo, ikiwa muovu anaingiza ombi la KICHWA, kama katika picha hizi:
Kisha, mara tu lililokuwa buluu linajibiwa kwa muovu, ombi la mwathiriwa linayofuata litawekwa kwenye foleni:
Kisha, mwathiriwa atapokea jibu kutoka kwa ombi la KICHWA, ambalo litakuwa na Content-Length lakini hakuna maudhui kabisa. Kwa hivyo, wakala hautatuma jibu hili kwa mwathiriwa, bali utangoja kwa maudhui, ambayo kimsingi itakuwa jibu kwa ombi la njano (pia lililoingizwa na muovu):
Utata wa Yaliyomo
Kufuatia mfano uliopita, ukijua kwamba unaweza kudhibiti mwili wa ombi ambalo jibu lake linatarajiwa kupokea na muathiriwa na kwamba jibu la HEAD kawaida lina Content-Type na Content-Length katika vichwa vyake, unaweza kutuma ombi kama ifuatavyo kusababisha XSS kwa muathiriwa bila ukurasa kuwa na udhaifu wa XSS:
Kuharibu Cache
Kwa kutumia shambulio la Utata wa Yaliyomo lililopita la kudhoofisha majibu yaliyosafishwa, 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:
{% hint style="warning" %} Tambua kwamba katika kesi hii ikiwa "muathiriwa" ni mshambuliaji anaweza sasa kufanya kudhoofisha cache kwa URL za kupindukia kwani anaweza kudhibiti URL itakayohifadhiwa na jibu la uovu. {% endhint %}
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:
Kugawanyika kwa Majibu
Lengo la shambulio hili ni kutumia tena kudhoofisha majibu kwa lengo la 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 wa jibu la HEAD.
Atatuma exploit kama:
Baada ya ombi la kwanza kutatuliwa na kutumwa kwa mshambuliaji, ombi la muathiriwa linaongezwa kwenye foleni:
Muathiriwa atapokea kama jibu jibu la HEAD + yaliyomo ya jibu la pili (lenye sehemu ya data iliyorejelewa):
Hata hivyo, angalia jinsi data iliyorejelewa ilikuwa na ukubwa kulingana na Content-Length ya jibu la HEAD lililosababisha jibu la HTTP linalofaa katika foleni ya majibu**.
Kwa 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.