HTTP Response Smuggling / Desync
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Die tegniek van hierdie pos is geneem uit die video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Eerstens, hierdie tegniek misbruik 'n HTTP Request Smuggling kwesbaarheid, so jy moet weet wat dit is:
Die hoof verskil tussen hierdie tegniek en 'n algemene HTTP Request smuggling is dat in plaas van die aanval op die aanvraag van die slagoffer deur 'n voorvoegsel daaraan toe te voeg, ons gaan lek of die antwoord wat die slagoffer ontvang, verander. Dit word gedoen deur, in plaas daarvan om 1 aanvraag en 'n half te stuur om die HTTP Request smuggling te misbruik, 2 volledige versoeke te stuur om die proxies se antwoordqueue te desinkroniseer.
Dit is omdat ons in staat gaan wees om die antwoordqueue te desinkroniseer sodat die antwoord van die legitieme aanvraag van die slagoffer na die aanvaller gestuur word, of deur aanvallersbeheerde inhoud in die antwoord aan die slagoffer in te voeg.
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 agtergrond gestuur is en antwoorde wat daaruit kom, te handhaaf.
Daar is egter 'n probleem om die antwoordequeue te desinkroniseer. As 'n aanvaller 'n HTTP Response smuggling aanval stuur en die antwoorde op die aanvanklike aanvraag en die gesmugde een onmiddellik beantwoord word, sal die gesmugde antwoord nie in die queue van die slagoffer se antwoord ingevoeg word nie, maar sal net as 'n fout weggegooi word.
Daarom is dit nodig dat die gesmugde aanvraag meer tyd neem om verwerk te word binne die agtergrond bediener. Daarom, teen die tyd dat die gesmugde aanvraag verwerk word, sal die kommunikasie met die aanvaller verby wees.
As in hierdie spesifieke situasie 'n slagoffer 'n aanvraag gestuur het en die gesmugde aanvraag voor die legitieme aanvraag beantwoord word, sal die gesmugde antwoord na die slagoffer gestuur word. Daarom sal die aanvaller die aanvraag "uitgevoer" deur die slagoffer beheer.
Boonop, as die aanvaller dan 'n aanvraag uitvoer en die legitieme antwoord op die slagoffer se aanvraag beantwoord voor die aanvaller se aanvraag. Die antwoord aan die slagoffer gaan na die aanvaller gestuur word, steel die antwoord aan die slagoffer (wat byvoorbeeld die header Set-Cookie kan bevat).
Nog 'n interessante verskil met algemene HTTP Request Smuggling is dat, in 'n algemene smuggling aanval, die doel is om die begin van die slagoffer se aanvraag te verander sodat dit 'n onverwagte aksie uitvoer. In 'n HTTP Response smuggling aanval, aangesien jy volledige versoeke stuur, kan jy in een payload tientalle antwoorde invoeg wat tientalle gebruikers gaan desinkroniseer wat die ingevoegde antwoorde 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.
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 aanvraag is genoeg as ons net wil probeer om die slagoffer se antwoord te steel. Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.
Eerstens die aanvanklike aanvraag wat HTTP Request smuggling misbruik, dan die tydrowende aanvraag en dan 1 of meer payload versoeke waarvan die antwoorde aan die slagoffers gestuur sal word.
Soos met bekende payloads van HTTP Request Smuggling, kan jy die slagoffer se aanvraag steel met een belangrike verskil: In hierdie geval het jy net die gestuurde inhoud nodig om in die antwoord weerspieël te word, geen volhoubare berging is nodig nie.
Eerstens, die aanvaller stuur 'n payload wat 'n finale POST-aanvraag met die weerspieëlde parameter aan die einde en 'n groot Content-Length bevat.
Dan, sodra die aanvanklike aanvraag (blou) verwerk is en terwyl die slaapagtige een verwerk word (geel), gaan die volgende aanvraag wat van 'n slagoffer aankom in die queue net na die weerspieëlde parameter ingevoeg word:
Dan, die slagoffer sal die antwoord op die slaapagtige aanvraag ontvang en as intussen die aanvaller nog 'n aanvraag gestuur het, sal die antwoord van die weerspieëlde inhoud aanvraag na hom gestuur word.
Tot op hierdie punt het ons geleer hoe om HTTP Request Smuggling aanvalle te misbruik om die aanvraag waarvan die antwoord 'n klient gaan ontvang te beheer en hoe jy dan die antwoord wat bedoel was vir die slagoffer kan steel.
Maar dit is steeds moontlik om die antwoorde nog meer te desinkroniseer.
Daar is interessante versoeke soos HEAD versoeke wat gespesifiseer is om geen inhoud binne die antwoord se liggaam te hê nie en wat die Content-Length van die aanvraag moet (moet) bevat soos as dit 'n GET-aanvraag was.
Daarom, as 'n aanvaller 'n HEAD aanvraag invoeg, soos in hierdie beelde:
Dan, sodra die blou een aan die aanvaller beantwoord word, gaan die volgende slagoffer se aanvraag in die queue ingevoer word:
Dan, die slagoffer sal die antwoord van die HEAD aanvraag ontvang, wat 'n Content-Length gaan bevat maar glad nie inhoud nie. Daarom sal die proxy nie hierdie antwoord aan die slagoffer stuur nie, maar sal wag vir 'n inhoud, wat eintlik die antwoord op die geel aanvraag gaan wees (ook deur die aanvaller ingevoeg):
Volgende op die vorige voorbeeld, wetende dat jy die liggaam van die aanvraag kan beheer waarvan die antwoord die slagoffer gaan ontvang en dat 'n HEAD antwoord gewoonlik in sy headers die Content-Type en die Content-Length bevat, kan jy 'n aanvraag soos die volgende stuur om XSS in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
Deur die voorheen bespreekte antwoord desinkronisasie Inhoud Verwarring aanval te misbruik, as die cache die antwoord op die aanvraag wat deur die slagoffer uitgevoer is, stoor en hierdie antwoord 'n ingevoegde een is wat 'n XSS veroorsaak, dan is die cache vergiftig.
Kwaadwillige aanvraag wat die XSS payload bevat:
Kwaadwillige antwoord aan die slagoffer wat die header bevat wat aan die cache aandui om die antwoord te stoor:
Let daarop dat in hierdie geval as die "slagoffer" die aanvaller is, hy nou cache vergiftiging in arbitrêre URL's kan uitvoer aangesien hy die URL wat in die cache gestoor gaan word, kan beheer met die kwaadwillige antwoord.
Hierdie aanval is soortgelyk aan die vorige een, maar in plaas daarvan om 'n payload binne die cache in te voeg, sal die aanvaller slagofferinligting binne die cache stoor:
Die doel van hierdie aanval is om weer die antwoord desinkronisasie te misbruik om die proxy 'n 100% aanvaller gegenereerde antwoord te laat stuur.
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat sekere waardes binne die antwoord weerspieël en die inhoudsgrootte van die HEAD antwoord weet.
Hy sal 'n exploit soos volg stuur:
Nadat die eerste aanvraag opgelos is en aan die aanvaller teruggestuur is, word die slagoffer se aanvraag in die queue ingevoeg:
Die slagoffer sal as antwoord die HEAD antwoord + die inhoud van die tweede aanvraag se antwoord (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 antwoord wat 'n geldige HTTP antwoord in die antwoordqueue gegenereer het.
Daarom, die volgende aanvraag van die tweede slagoffer sal ontvang as antwoord iets wat heeltemal deur die aanvaller saamgestel is. Aangesien die antwoord heeltemal deur die aanvaller saamgestel is, kan hy ook die proxy laat cache die antwoord.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
