HTTP Response Smuggling / Desync

Reading time: 8 minutes

Die tegniek van hierdie pos is geneem uit die video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Versoek Queues Desynchronisasie

Eerstens, hierdie tegniek misbruik 'n HTTP Versoek Smuggling kwesbaarheid, so jy moet weet wat dit is:

Die hoof verskil tussen hierdie tegniek en 'n algemene HTTP Versoek smuggling is dat in plaas van om die versoek van die slagoffer te aanval deur 'n voorvoegsel daaraan toe te voeg, ons gaan die respons wat die slagoffer ontvang, lek of wysig. Dit word gedoen deur, in plaas van om 1 versoek en 'n halwe te stuur om die HTTP Versoek smuggling te misbruik, 2 volledige versoeke te stuur om die proxies se respons queue te desynchroniseer.

Dit is omdat ons in staat gaan wees om die respons queue te desynchroniseer sodat die respons van die legitieme versoek van die slagoffer na die aanvaller gestuur word, of deur aanvallers beheerde inhoud in die respons aan die slagoffer in te spuit.

HTTP Pyplyn Desync

HTTP/1.1 laat toe om verskillende hulpbronne te vra sonder om te wag vir vorige. Daarom, as daar 'n proxy in die middel is, is dit die proxies se taak om 'n gesinkroniseerde ooreenstemming van versoeke wat na die agterkant gestuur is en respons wat daarvandaan kom, te handhaaf.

Daar is egter 'n probleem om die respons queue te desynchroniseer. As 'n aanvaller 'n HTTP Respons smuggling aanval stuur en die respons op die aanvanklike versoek en die gesmugde een onmiddellik beantwoord word, sal die gesmugde respons nie in die queue van die slagoffer se respons ingevoeg word nie, maar sal net as 'n fout weggegooi word.

Daarom is dit nodig dat die gesmugde versoek meer tyd neem om verwerk te word binne die agterkant bediener. Daarom, teen die tyd dat die gesmugde versoek verwerk word, sal die kommunikasie met die aanvaller verby wees.

As in hierdie spesifieke situasie 'n slagoffer 'n versoek gestuur het en die gesmugde versoek voor die legitieme versoek beantwoord word, sal die gesmugde respons aan die slagoffer gestuur word. Daarom sal die aanvaller die versoek "uitgevoer" deur die slagoffer beheer.

Boonop, as die aanvaller dan 'n versoek uitvoer en die legitieme respons op die slagoffer se versoek beantwoord voor die aanvaller se versoek. Die respons aan die slagoffer gaan aan die aanvaller gestuur word, steel die respons aan die slagoffer (wat byvoorbeeld die header Set-Cookie kan bevat).

Meervoudige Geneste Inspuitings

Nog 'n interessante verskil met algemene HTTP Versoek Smuggling is dat, in 'n algemene smuggling aanval, die doel is om die begin van die slagoffer se versoek te wysig sodat dit 'n onverwagte aksie uitvoer. In 'n HTTP Respons smuggling aanval, aangesien jy volledige versoeke stuur, kan jy in een payload tientalle responsies inspuit wat tientalle gebruikers gaan desynchroniseer wat die ingespuite responsies gaan ontvang.

Afgesien van die vermoë om tientalle exploits makliker te versprei oor legitieme gebruikers, kan dit ook gebruik word om 'n DoS op die bediener te veroorsaak.

Exploit Organisasie

Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die eerste gesmugde boodskap in die bediener baie tyd neem om verwerk te word.

Hierdie tydrowende versoek is genoeg as ons net die slagoffer se respons wil probeer steel. Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.

Eerstens die aanvanklike versoek wat HTTP Versoek smuggling misbruik, dan die tydrowende versoek en dan 1 of meer payload versoeke waarvan die respons aan die slagoffers gestuur sal word.

Misbruik van HTTP Respons Queue Desynchronisasie

Vasvang van ander gebruikers se versoeke

Soos met bekende payloads van HTTP Versoek Smuggling, kan jy die slagoffer se versoek steel met een belangrike verskil: In hierdie geval het jy net die gestuurde inhoud nodig om in die respons weerspieël te word, geen volgehoue berging is nodig nie.

Eerstens, stuur die aanvaller 'n payload wat 'n finale POST versoek met die weerspieëlde parameter aan die einde en 'n groot Content-Length bevat.

Dan, sodra die aanvanklike versoek (blou) verwerk is en terwyl die slaapagtige een verwerk word (geel), gaan die volgende versoek wat van 'n slagoffer aankom in die queue net na die weerspieëlde parameter ingevoeg word:

Dan, die slagoffer sal die respons op die slaapagtige versoek ontvang en as intussen die aanvaller nog 'n versoek gestuur het, sal die respons van die weerspieëlde inhoud versoek aan hom gestuur word.

Respons Desynchronisasie

Tot op hierdie punt, het ons geleer hoe om HTTP Versoek Smuggling aanvalle te misbruik om die versoek waarvan die respons 'n klient gaan ontvang te beheer en hoe jy dan die respons kan steel wat bedoel was vir die slagoffer.

Maar dit is steeds moontlik om die respons nog meer te desynchroniseer.

Daar is interessante versoeke soos HEAD versoeke wat gespesifiseer is om geen inhoud binne die respons se liggaam te hê nie en wat moet (moet) die Content-Length van die versoek bevat soos as dit 'n GET versoek was.

Daarom, as 'n aanvaller 'n HEAD versoek inspuit, soos in hierdie beelde:

Dan, sodra die blou een aan die aanvaller beantwoord word, gaan die volgende slagoffer se versoek in die queue ingevoer word:

Dan, die slagoffer sal die respons van die HEAD versoek ontvang, wat 'n Content-Length gaan bevat maar glad nie inhoud nie. Daarom sal die proxy nie hierdie respons aan die slagoffer stuur nie, maar sal wag vir 'n inhoud, wat eintlik die respons op die geel versoek gaan wees (ook deur die aanvaller ingespuit):

Inhoud Verwarring

Volg die vorige voorbeeld, wetende dat jy die liggaam van die versoek kan beheer waarvan die respons aan die slagoffer gaan ontvang en dat 'n HEAD respons gewoonlik in sy headers die Content-Type en die Content-Length bevat, kan jy 'n versoek soos die volgende stuur om XSS in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:

Cache Vergiftiging

Deur die voorheen bespreekte respons desynchronisasie Inhoud Verwarring aanval te misbruik, as die cache die respons op die versoek wat deur die slagoffer uitgevoer is, stoor en hierdie respons 'n ingespuite een is wat 'n XSS veroorsaak, dan is die cache vergiftig.

Kwaadwillige versoek wat die XSS payload bevat:

Kwaadwillige respons aan die slagoffer wat die header bevat wat aan die cache aandui om die respons te stoor:

Web Cache Misleiding

Hierdie aanval is soortgelyk aan die vorige een, maar in plaas van om 'n payload binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:

Respons Splitting

Die doel van hierdie aanval is om weer die respons desynchronisasie te misbruik om die proxy 'n 100% aanvaller gegenereerde respons te laat stuur.

Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat sekere waardes binne die respons weerspieël en die inhoudsgrootte van die HEAD respons weet.

Hy sal 'n exploit soos volg stuur:

Nadat die eerste versoek opgelos is en aan die aanvaller teruggestuur is, word die slagoffer se versoek in die queue ingevoeg:

Die slagoffer sal as respons die HEAD respons + die inhoud van die tweede versoek se respons (wat 'n deel van die weerspieëlde data bevat):

Let egter op hoe die weerspieëlde data 'n grootte gehad het volgens die Content-Length van die HEAD respons wat 'n geldige HTTP respons in die respons queue gegenereer het.

Daarom, die volgende versoek van die tweede slagoffer sal ontvang as respons iets wat heeltemal deur die aanvaller saamgestel is. Aangesien die respons heeltemal deur die aanvaller saamgestel is, kan hy ook die proxy laat cache die respons.