HTTP Response Smuggling / Desync
The technique of this post was taken from the video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP Request Queue Desynchronisation
Kwanza kabisa, mbinu hii inatumia udhaifu wa HTTP Request Smuggling, hivyo unahitaji kujua ni nini hicho:
tofauti kuu kati ya mbinu hii na HTTP Request smuggling ya kawaida ni kwamba badala ya kushambulia ombile la mhasiriwa kwa kuongeza kiambatisho kwake, tunakwenda kuvuja au kubadilisha jibu ambalo mhasiriwa anapata. Hii inafanywa kwa, badala ya kutuma ombi 1 na nusu ili kutumia HTTP Request smuggling, tuma ombi 2 kamili ili kuondoa usawa wa foleni za majibu ya proxies.
Hii ni kwa sababu tutakuwa na uwezo wa kuondoa usawa wa foleni ya majibu ili jibu kutoka kwa ombile la halali la mhasiriwa litumwe kwa mshambuliaji, au kwa kuingiza maudhui yanayodhibitiwa na mshambuliaji katika jibu kwa mhasiriwa.
HTTP Pipeline Desync
HTTP/1.1 inaruhusu kuomba rasilimali tofauti bila kuhitaji kusubiri zilizopita. Hivyo, ikiwa kuna proxy katikati, ni jukumu la proxies kuweka usawa wa maombi yaliyotumwa kwa backend na majibu yanayotoka kutoka kwake.
Hata hivyo, kuna tatizo la kuondoa usawa wa foleni za majibu. Ikiwa mshambuliaji atatuma shambulio la HTTP Response smuggling na majibu kwa ombile la awali na lile lililovuja yanajibiwa mara moja, jibu lililovuja halitaingizwa ndani ya foleni ya jibu la mhasiriwa bali litakataliwa kama kosa.
Hivyo, inahitajika kwamba ombile lililovuja lichukue muda mrefu zaidi kutekelezwa ndani ya seva ya backend. Hivyo, wakati ombi lililovuja linaposhughulikiwa, mawasiliano na mshambuliaji yatakuwa yameisha.
Ikiwa katika hali hii maalum mhasiriwa ametuma ombi na ombile lililovuja linajibiwa kabla ya ombi halali, jibu lililovuja litatumwa kwa mhasiriwa. Hivyo, mshambuliaji atakuwa akidhibiti ombi "lililofanywa" na mhasiriwa.
Zaidi ya hayo, ikiwa mshambuliaji kisha atafanya ombi na jibu halali kwa ombile la mhasiriwa linajibiwa kabla ya ombi la mshambuliaji. Jibu kwa mhasiriwa litatumwa kwa mshambuliaji, kuchukua jibu kwa mhasiriwa (ambalo linaweza kuwa na mfano kichwa Set-Cookie).
Multiple Nested Injections
Tofauti nyingine ya kuvutia na HTTP Request Smuggling ya kawaida ni kwamba, katika shambulio la kawaida la smuggling, lengo ni kubadilisha mwanzo wa ombi la mhasiriwa ili lifanye kitendo kisichotarajiwa. Katika shambulio la HTTP Response smuggling, kwa kuwa unatumia maombi kamili, unaweza kuingiza katika payload moja majibu kumi ambayo yatakuwa yakiondoa usawa wa watumiaji kumi ambao watakuwa wakipokea majibu yaliyoingizwa.
Mbali na kuwa na uwezo wa kusambaza kwa urahisi majaribio kumi kati ya watumiaji halali, hii pia inaweza kutumika kusababisha DoS katika seva.
Exploit Organisation
Kama ilivyoelezwa hapo awali, ili kutumia mbinu hii, inahitajika kwamba ujumbe wa kwanza ulioingizwa ndani ya seva uchukue muda mwingi kutekelezwa.
Hii ombile linalochukua muda ni ya kutosha ikiwa tunataka tu kujaribu kuiba jibu la mhasiriwa. Lakini ikiwa unataka kufanya exploit ngumu zaidi hii itakuwa muundo wa kawaida kwa exploit.
Kwanza kabisa ombile la awali linalotumia HTTP Request smuggling, kisha ombile linalochukua muda na kisha ombile 1 au zaidi ambayo majibu yake yatatumwa kwa mhasiriwa.
Abusing HTTP Response Queue Desynchronisation
Capturing other users' requests
Kama ilivyo na payloads za HTTP Request Smuggling zinazojulikana, unaweza kuiba ombi la mhasiriwa kwa tofauti moja muhimu: Katika kesi hii unahitaji tu kupeleka maudhui ili yaonyeshwe katika jibu, hakuna hifadhi ya kudumu inahitajika.
Kwanza, mshambuliaji anatuma payload inayojumuisha ombile la mwisho la POST lenye parameter iliyoonyeshwa mwishoni na Content-Length kubwa.
Kisha, mara tu ombile la awali (bluu) liliposhughulikiwa na wakati ombile la usingizi linaposhughulikiwa (njano) ombile linalofuata linalotoka kwa mhasiriwa litakuwa limeongezwa kwenye foleni mara tu baada ya parameter iliyoonyeshwa:
Kisha, mhasiriwa atapokea jibu kwa ombile la usingizi na ikiwa wakati huo mshambuliaji alituma ombile lingine, jibu kutoka kwa ombi la maudhui yaliyoonyeshwa litatumwa kwake.
Response Desynchronisation
Hadi sasa, tumefundishwa jinsi ya kutumia shambulio la HTTP Request Smuggling ili kudhibiti ombile ambalo jibu ambalo mteja atakuwa akipokea na jinsi unaweza kisha kuiba jibu ambalo lilikuwa limekusudiwa kwa mhasiriwa.
Lakini bado inawezekana kuondoa usawa hata zaidi majibu.
Kuna maombi ya kuvutia kama HEAD ambayo yameelezwa kutokuwa na maudhui yoyote ndani ya mwili wa majibu na ambayo yanapaswa (lazima) kujumuisha Content-Length ya ombi kama kama ingekuwa ombi la GET.
Hivyo, ikiwa mshambuliaji anaingiza ombi la HEAD, kama katika picha hizi:
Kisha, mara tu bluu inajibiwa kwa mshambuliaji, ombi linalofuata la mhasiriwa litakuwa limeingizwa kwenye foleni:
Kisha, mhasiriwa atapokea jibu kutoka kwa ombile la HEAD, ambalo litakuwa na Content-Length lakini hakuna maudhui kabisa. Hivyo, proxy haitatuma jibu hili kwa mhasiriwa, bali itangojea maudhui, ambayo kwa kweli yatakuwa jibu kwa ombi la njano (pia lililoingizwa na mshambuliaji):
Content Confusion
Kufuata mfano wa awali, ukijua kwamba unaweza kudhibiti mwili wa ombi ambalo jibu litakalopokea mhasiriwa na kwamba jibu la HEAD kawaida lina Content-Type na Content-Length katika vichwa vyake, unaweza kutuma ombi kama ifuatavyo ili kusababisha XSS kwa mhasiriwa bila ukurasa kuwa na udhaifu wa XSS:
Cache Poisoning
Kutatiza shambulio la awali lililozungumziwa la desynchronisation ya jibu la Content Confusion, ikiwa cache inahifadhi jibu kwa ombi lililofanywa na mhasiriwa na jibu hili ni la kuingizwa linalosababisha XSS, basi cache inakuwa na sumu.
Ombi la uhalifu likijumuisha payload ya XSS:
Jibu la uhalifu kwa mhasiriwa ambalo lina kichwa kinachoonyesha kwa cache kuhifadhi jibu:
Note that in this case if the "victim" is the attacker he can now perform cache poisoning in arbitrary URLs as he can control the URL that is going to be cached with the malicious response.
Web Cache Deception
Shambulio hili ni sawa na la awali, lakini badala ya kuingiza payload ndani ya cache, mshambuliaji atakuwa akihifadhi taarifa za mhasiriwa ndani ya cache:
Response Splitting
Lengo la shambulio hili ni kutumia tena desynchronisation ya jibu ili kufanya proxy itume jibu 100% lililotengenezwa na mshambuliaji.
Ili kufikia hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambayo inaonyesha baadhi ya thamani ndani ya jibu na ajue urefu wa maudhui ya jibu la HEAD.
Atatuma exploit kama:
Baada ya ombi la kwanza kutatuliwa na kutumwa kwa mshambuliaji, ombile la mhasiriwa linaongezwa kwenye foleni:
Mhasiriwa atapokea kama jibu jibu la HEAD + maudhui ya jibu la ombi la pili (linalojumuisha sehemu ya data iliyoonyeshwa):
Hata hivyo, angalia jinsi data iliyoonyeshwa ilikuwa na ukubwa kulingana na Content-Length ya jibu la HEAD ambayo ilitoa jibu halali la HTTP katika foleni ya majibu.
Hivyo, ombile linalofuata la mhasiriwa wa pili litakuwa likipokea kama jibu kitu kilichotengenezwa kabisa na mshambuliaji. Kwa kuwa jibu linatengenezwa kabisa na mshambuliaji anaweza pia kufanya proxy ihifadhi jibu.
Last updated
