HTTP Response Smuggling / Desync
Die tegniek van hierdie pos is geneem uit die video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP Aanvraagry Desinkronisasie
Eerstens, misbruik hierdie tegniek 'n HTTP Aanvraag Smuggling kwesbaarheid, dus jy moet weet wat dit is:
Die hoofverskil tussen hierdie tegniek en 'n gewone HTTP Aanvraag-smuggling is dat in plaas daarvan om die aanvraag van die slagoffer aan te val deur 'n voorvoegsel by te voeg, gaan ons die reaksie wat die slagoffer ontvang lek of wysig. Dit word gedoen deur, in plaas van om 1 aanvraag en 'n half te stuur om die HTTP Aanvraag-smuggling te misbruik, 2 volledige aanvrae te stuur om die proksi se reaksie-ry te desinkroniseer.
Dit is omdat ons in staat gaan wees om die reaksie-ry te desinkroniseer sodat die reaksie van die wettige aanvraag van die slagoffer na die aanvaller gestuur word, of deur aanvallersbeheerde inhoud in die reaksie aan die slagoffer in te spuit.
HTTP Pyplyn Desinkronisasie
HTTP/1.1 maak dit moontlik om vir verskillende bronne te vra sonder om te wag vir voriges. Daarom, as daar 'n proksi in die middel is, is dit die proksi se taak om 'n gesinkroniseerde ooreenstemming van aanvrae wat na die agterste gestuur is en reaksies wat daarvandaan kom, te handhaaf.
Daar is egter 'n probleem om die reaksies-ry te desinkroniseer. As 'n aanvaller 'n HTTP Reaksie-smuggling-aanval stuur en die reaksies op die oorspronklike aanvraag en die gesmokkelde een onmiddellik reageer, sal die gesmokkelde reaksie nie binne die ry van die slagoffer se reaksie ingevoeg word nie, maar sal net as 'n fout verwerp word.
Daarom is dit nodig dat die gesmokkelde aanvraag meer tyd neem om binne die agterste bediener verwerk te word. Daarom, teen die tyd dat die gesmokkelde aanvraag verwerk is, sal die kommunikasie met die aanvaller verby wees.
As in hierdie spesifieke situasie 'n slagoffer 'n aanvraag gestuur het en die gesmokkelde aanvraag voor die wettige aanvraag beantwoord word, sal die gesmokkelde reaksie na die slagoffer gestuur word. Daarom sal die aanvaller die aanvraag "uitgevoer" deur die slagoffer beheer.
Verder, as die aanvaller dan 'n aanvraag uitvoer en die wettige reaksie op die slagoffer se aanvraag beantwoord word voor die aanvaller se aanvraag. Die reaksie na die slagoffer sal na die aanvaller gestuur word, wat die reaksie aan die slagoffer steel (wat byvoorbeeld die kop Set-Cookie kan bevat).
Meervoudige Geneste Inspruitings
'n Ander interessante verskil met gewone HTTP Aanvraag-smuggling is dat, in 'n gewone smokkelingsaanval, die doel is om die begin van die slagoffer se aanvraag te wysig sodat dit 'n onverwagte aksie uitvoer. In 'n HTTP Reaksie-smuggling-aanval, aangesien jy volledige aanvrae stuur, kan jy tientalle reaksies in een nut inpluis wat tientalle gebruikers sal desinkroniseer wat die ingevoegde reaksies ontvang.
Afgesien daarvan dat jy makliker tientalle exploits kan versprei onder wettige gebruikers, kan dit ook gebruik word om 'n DoS in die bediener te veroorsaak.
Uitbuiting Organisasie
Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die eerste gesmokkelde boodskap in die bediener baie tyd neem om verwerk te word.
Hierdie tydrowende aanvraag is genoeg as ons net die slagoffer se reaksie wil probeer steel. Maar as jy 'n meer komplekse uitbuiting wil uitvoer, sal dit 'n algemene struktuur vir die uitbuiting wees.
Eerstens die oorspronklike aanvraag wat HTTP Aanvraag-smuggling misbruik, dan die tydrowende aanvraag en dan 1 of meer nutaanvrae waarvan die reaksies na die slagoffers gestuur sal word.
Misbruik van HTTP Reaksie-ry Desinkronisasie
Vaslegging van ander gebruikers se aanvrae
Soos met bekende HTTP Aanvraag-smuggling-nutladings, kan jy die slagoffer se aanvraag steel met een belangrike verskil: In hierdie geval hoef jy net die gestuurde inhoud te sien in die reaksie, geen permanente stoorplek is nodig nie.
Eerstens stuur die aanvaller 'n nut wat 'n finale POST-aanvraag met die gereflekte parameter aan die einde en 'n groot Inhoudslengte bevat
Dan, sodra die oorspronklike aanvraag (blou) verwerk is en terwyl die slaperige een verwerk word (geel) gaan die volgende aanvraag wat van 'n slagoffer afkomstig is, in die ry net na die gereflekte parameter ingevoeg word:
Dan sal die slagoffer die reaksie op die slaperige aanvraag ontvang en as intussen die aanvaller 'n ander aanvraag stuur, sal die reaksie van die gereflekte inhoudsaanvraag na hom gestuur word.
Reaksie Desinkronisasie
Tot dusver het ons geleer hoe om HTTP Aanvraag-smuggling-aanvalle te misbruik om die aanvraag te beheer waarvan 'n kliënt die reaksie gaan ontvang en hoe jy dan die reaksie wat vir die slagoffer bedoel was, kan steel.
Maar dit is steeds moontlik om die reaksies selfs meer te desinkroniseer.
Daar is interessante aanvrae soos HEAD-aanvrae wat gespesifiseer is om geen inhoud binne die reaksie liggaam te hê en wat (moet) die Inhoudslengte bevat van die aanvraag soos of dit 'n GET-aanvraag was.
Daarom, as 'n aanvaller 'n HEAD-aanvraag inspuit, soos in hierdie beelde:
Dan, sodra die blou een aan die aanvaller beantwoord is, gaan die volgende slagoffersaanvraag in die ry ingevoer word:
Dan sal die slagoffer die reaksie van die HEAD-aanvraag ontvang, wat 'n Inhoudslengte maar geen inhoud nie gaan bevat. Daarom sal die proksi nie hierdie reaksie na die slagoffer stuur nie, maar sal wag vir 'n bietjie inhoud, wat eintlik die reaksie op die geel aanvraag gaan wees (ook deur die aanvaller ingespuit):
Inhoudsverwarring
Na die vorige voorbeeld, wetende dat jy die liggaam van die versoek kan beheer waarvan die reaksie deur die slagoffer ontvang gaan word en dat 'n HEAD reaksie gewoonlik die Content-Type en die Content-Length in sy koppe bevat, kan jy 'n versoek soos die volgende stuur om 'n XSS in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
Kegelvergiftiging
Deur die voorheen besproke reaksie desinkronisasie Inhoudsverwarring aan te val, as die kegel die reaksie op die versoek wat deur die slagoffer uitgevoer is stoor en hierdie reaksie 'n geïnspireerde een is wat 'n XSS veroorsaak, dan is die kegel vergiftig.
Boosaardige versoek wat die XSS-lading bevat:
Boosaardige reaksie aan die slagoffer wat die kop bevat wat aan die kegel aandui om die reaksie te stoor:
Let daarop dat in hierdie geval as die "slagoffer" die aanvaller is, kan hy nou kegelvergiftiging in willekeurige URL's uitvoer aangesien hy die URL kan beheer wat met die boosaardige reaksie gestoor gaan word.
Web Kegel Misleiding
Hierdie aanval is soortgelyk aan die vorige een, maar in plaas daarvan om 'n lading binne die kegel in te spuit, sal die aanvaller slagofferinligting binne die kegel stoor:
Reaksie Splitsing
Die doel van hierdie aanval is om weer die reaksie desinkronisasie te misbruik om die proksi te dwing om 'n 100% aanvaller gegenereerde reaksie te stuur.
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat waardes binne die reaksie reflekteer en die inhoudslengte van die HEAD-reaksie ken.
Hy sal 'n uitbuiting stuur soos:
Nadat die eerste versoek opgelos en teruggestuur is na die aanvaller, word die slagoffersversoek by die tou gevoeg:
Die slagoffer sal as reaksie die HEAD-reaksie + die inhoud van die tweede versoekreaksie (wat deel van die gereflekte data bevat) ontvang:
Let egter daarop hoe die gereflekteerde data 'n grootte volgens die Content-Length van die HEAD-reaksie gehad het wat 'n geldige HTTP-reaksie in die reaksietou gegenereer het.
Daarom sal die volgende versoek van die tweede slagoffer as reaksie iets heeltemal deur die aanvaller saamgestel ontvang. Aangesien die reaksie heeltemal deur die aanvaller saamgestel is, kan hy ook die proksi dwing om die reaksie te stoor.
Last updated
