HTTP Response Smuggling / Desync

Reading time: 7 minutes

Teknolojia ya posti hii ilichukuliwa kutoka kwenye video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Request Queue Desynchronisation

Kwanza kabisa, teknolojia hii inatumia udhaifu wa HTTP Request Smuggling, hivyo unahitaji kujua ni nini hicho:

Tofauti kuu kati ya teknolojia hii na HTTP Request smuggling ya kawaida ni kwamba badala ya kushambulia ombile la mhasiriwa kwa kuongeza kiambatisho kwake, tutakuwa tukivuja au kubadilisha jibu ambalo mhasiriwa anapata. Hii inafanywa kwa, badala ya kutuma ombi 1 na nusu ili kutumia HTTP Request smuggling, tutatumia maombi 2 kamili ili kuondoa usawa wa 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 huko.

Hata hivyo, kuna tatizo la kuondoa usawa wa foleni ya 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 nyuma. 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 wa 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 majibu kumi kati ya watumiaji halali, hii pia inaweza kutumika kusababisha DoS katika seva.

Exploit Organisation

Kama ilivyoelezwa hapo awali, ili kutumia teknolojia 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 likitumia 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 maudhui ya kutumwa kuakisi katika jibu, hakuna hifadhi ya kudumu inahitajika.

Kwanza, mshambuliaji anatumia payload inayojumuisha ombile la mwisho la POST lenye kiambatisho kilichoakisiwa mwishoni na Content-Length kubwa.

Kisha, mara tu ombile la awali (bluu) liliposhughulikiwa na wakati ombile la usingizi linaposhughulikiwa (njano) ombile linalofika kutoka kwa mhasiriwa litakuwa limeongezwa kwenye foleni mara tu baada ya kiambatisho kilichoakisiwa:

Kisha, mhasiriwa atapokea jibu kwa ombile la usingizi na ikiwa wakati huo mshambuliaji alituma ombile lingine, jibu kutoka kwa ombi la maudhui yaliyoakisiwa 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 limetengwa kwa mhasiriwa.

Lakini bado inawezekana kuondoa usawa hata zaidi majibu.

Kuna maombi ya kuvutia kama HEAD ambayo yameainishwa 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 ombi la buluu linapojibiwa kwa mshambuliaji, ombi linalofuata la mhasiriwa litakuwa limeingizwa kwenye foleni:

Kisha, mhasiriwa atapokea jibu kutoka kwa HEAD ombi, ambalo litakuwa na Content-Length lakini hakuna maudhui kabisa. Hivyo, proxy haitatuma jibu hili kwa mhasiriwa, bali itasubiri 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 litapokea mhasiriwa na kwamba HEAD jibu 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

Kutumia shambulio la Content Confusion lililozungumziwa hapo awali, 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 kinachoelekeza kwenye cache kuhifadhi jibu:

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 kuondoa usawa wa majibu ili kufanya proxy itume jibu 100% lililotengenezwa na mshambuliaji.

Ili kufikia hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambayo inaakisi 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 iliyoakisiwa):

Hata hivyo, angalia jinsi data iliyoakisiwa ilikuwa na ukubwa kulingana na Content-Length ya HEAD jibu ambayo ilijenga 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 limeundwa kabisa na mshambuliaji anaweza pia kufanya proxy ihifadhi jibu.