Cache Poisoning and Cache Deception
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)
Gebruik Trickest om maklik te bou en werkvloei te outomatiseer wat deur die wêreld se mees gevorderde gemeenskap gereedskap aangedryf word. Kry Toegang Vandag:
Wat is die verskil tussen web cache poisoning en web cache deception?
In web cache poisoning veroorsaak die aanvaller dat die aansoek 'n paar kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander aansoekgebruikers bedien.
In web cache deception veroorsaak die aanvaller dat die aansoek 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
Cache poisoning is daarop gemik om die kliënt-kant cache te manipuleer om kliënte te dwing om hulpbronne te laai wat onverwags, gedeeltelik, of onder die beheer van 'n aanvaller is. Die omvang van die impak hang af van die gewildheid van die aangetaste bladsy, aangesien die besmette antwoord eksklusief aan gebruikers wat die bladsy besoek tydens die periode van cache besoedeling bedien word.
Die uitvoering van 'n cache poisoning aanval behels verskeie stappe:
Identifikasie van Ongekykte Insette: Dit is parameters wat, alhoewel nie vereis word vir 'n versoek om in die cache gestoor te word nie, die antwoord wat deur die bediener teruggestuur word, kan verander. Die identifikasie van hierdie insette is van kardinale belang aangesien dit benut kan word om die cache te manipuleer.
Eksploitatie van die Ongekykte Insette: Na die identifikasie van die ongekykte insette, behels die volgende stap om uit te vind hoe om hierdie parameters te misbruik om die bediener se antwoord op 'n manier te verander wat die aanvaller bevoordeel.
Verseker dat die Besmette Antwoord in die Cache Gestoor Word: Die finale stap is om te verseker dat die gemanipuleerde antwoord in die cache gestoor word. Op hierdie manier sal enige gebruiker wat toegang tot die aangetaste bladsy verkry terwyl die cache besoedel is, die besmette antwoord ontvang.
Gewoonlik, wanneer 'n antwoord in die cache gestoor is, sal daar 'n kopteks wees wat dit aandui, jy kan kyk watter koptekste jy op hierdie pos moet let: HTTP Cache koptekste.
As jy dink dat die antwoord in 'n cache gestoor word, kan jy probeer om versoeke met 'n slegte kopteks te stuur, wat met 'n statuskode 400 beantwoord moet word. Probeer dan om die versoek normaal te benader en as die antwoord 'n 400 statuskode is, weet jy dit is kwesbaar (en jy kan selfs 'n DoS uitvoer).
Jy kan meer opsies vind in:
Let egter daarop dat soms hierdie soort statuskodes nie in die cache gestoor word nie, so hierdie toets mag nie betroubaar wees nie.
Jy kan Param Miner gebruik om parameters en koptekste te brute-force wat moontlik die antwoord van die bladsy verander. Byvoorbeeld, 'n bladsy mag die kopteks X-Forwarded-For gebruik om die kliënt aan te dui om die skrip van daar te laai:
Met die parameter/kop wat geïdentifiseer is, kyk hoe dit gesanitiseer word en waar dit reflekteer of die reaksie van die kop beïnvloed. Kan jy dit op enige manier misbruik (voer 'n XSS uit of laai 'n JS-kode wat deur jou beheer word? voer 'n DoS uit?...)
Sodra jy die bladsy geïdentifiseer het wat misbruik kan word, watter parameter/kop om te gebruik en hoe om dit te misbruik, moet jy die bladsy in die cache kry. Afhangende van die hulpbron wat jy probeer om in die cache te kry, kan dit 'n rukkie neem, jy mag dalk vir verskeie sekondes moet probeer.
Die kop X-Cache in die reaksie kan baie nuttig wees, aangesien dit die waarde miss kan hê wanneer die versoek nie in die cache was nie en die waarde hit wanneer dit in die cache is.
Die kop Cache-Control is ook interessant om te weet of 'n hulpbron in die cache gestoor word en wanneer die volgende keer die hulpbron weer in die cache gestoor sal word: Cache-Control: public, max-age=1800
Nog 'n interessante kop is Vary. Hierdie kop word dikwels gebruik om addisionele koppe aan te dui wat as deel van die cache-sleutel behandel word, selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die gebruiker die User-Agent van die slagoffer wat hy teiken, ken, kan hy die cache vir die gebruikers wat daardie spesifieke User-Agent gebruik, vergiftig.
Een meer kop wat met die cache verband hou, is Age. Dit definieer die tyd in sekondes wat die objek in die proxy-cache was.
Wanneer jy 'n versoek in die cache stoor, wees versigtig met die koppe wat jy gebruik omdat sommige daarvan onverwagte as gesleuteld gebruik kan word en die slagoffer sal daardie selfde kop moet gebruik. Toets altyd 'n Cache Poisoning met verskillende blaaiers om te kyk of dit werk.
'n Kop soos X-Forwarded-For word ongesanitiseer in die reaksie gereflekteer.
Jy kan 'n basiese XSS-payload stuur en die cache vergiftig sodat almal wat die bladsy benader, XSS sal ervaar:
Note dat dit 'n versoek na /en?region=uk sal vergiftig en nie na /en nie
Koekies kan ook op die antwoord van 'n bladsy weerspieël word. As jy dit kan misbruik om 'n XSS te veroorsaak, kan jy in staat wees om XSS in verskeie kliënte te benut wat die kwaadwillige cache antwoord laai.
Let daarop dat as die kwesbare koekie baie deur die gebruikers gebruik word, gereelde versoeke die cache sal skoonmaak.
Kontroleer:
Hierdie skrywe verduidelik hoe dit moontlik was om 'n OpenAI API-sleutel te steel met 'n URL soos https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 omdat enigiets wat pas by /share/* in die cache gestoor sal word sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.
Dit word ook beter verduidelik in:
Soms sal jy verskeie ongekeyde insette moet benut om 'n cache te kan misbruik. Byvoorbeeld, jy mag 'n Open redirect vind as jy X-Forwarded-Host na 'n domein wat deur jou beheer word en X-Forwarded-Scheme na http stel. As die bediener al die HTTP versoeke na HTTPS stuur en die koptekst X-Forwarded-Scheme as die domeinnaam vir die omleiding gebruik. Jy kan beheer waar die bladsy deur die omleiding gewys word.
VaryheaderAs jy gevind het dat die X-Host header gebruik word as domeinnaam om 'n JS hulpbron te laai maar die Vary header in die antwoord dui op User-Agent. Dan moet jy 'n manier vind om die User-Agent van die slagoffer te exfiltreer en die cache te vergiftig met daardie gebruikersagent:
Stuur 'n GET-versoek met die versoek in die URL en in die liggaam. As die webbediener die een uit die liggaam gebruik, maar die kasbediener die een uit die URL kas, sal enigiemand wat daardie URL benader, eintlik die parameter uit die liggaam gebruik. Soos die kwesbaarheid wat James Kettle op die Github-webwerf gevind het:
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
Byvoorbeeld, dit is moontlik om parameters in ruby bedieners te skei deur die karakter ; te gebruik in plaas van &. Dit kan gebruik word om ongekeyde parameterwaardes binne gekeyde te plaas en dit te misbruik.
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Leer hier oor hoe om Cache Poisoning-aanvalle uit te voer deur HTTP Request Smuggling te misbruik.
Die Web Cache Vulnerability Scanner kan gebruik word om outomaties vir web cache poisoning te toets. Dit ondersteun baie verskillende tegnieke en is hoogs aanpasbaar.
Voorbeeld gebruik: wcvs -u example.com
ATS het die fragment binne die URL deurgegee sonder om dit te verwyder en het die cache-sleutel slegs met die gasheer, pad en navraag gegenereer (wat die fragment geïgnoreer het). So die versoek /#/../?r=javascript:alert(1) is na die agterkant gestuur as /#/../?r=javascript:alert(1) en die cache-sleutel het nie die payload daarin gehad nie, slegs gasheer, pad en navraag.
Die stuur van 'n slegte waarde in die content-type kop het 'n 405 gecacheerde antwoord geaktiveer. Die cache-sleutel het die koekie bevat, so dit was moontlik om slegs ongeauthentiseerde gebruikers aan te val.
GitLab gebruik GCP-buckets om statiese inhoud te stoor. GCP Buckets ondersteun die kop x-http-method-override. So dit was moontlik om die kop x-http-method-override: HEAD te stuur en die cache te vergiftig om 'n leë antwoordliggaam te laat terugkeer. Dit kan ook die metode PURGE ondersteun.
In Ruby on Rails-toepassings word Rack middleware dikwels gebruik. Die doel van die Rack-kode is om die waarde van die x-forwarded-scheme kop in te stel as die versoek se skema. Wanneer die kop x-forwarded-scheme: http gestuur word, vind 'n 301 herleiding na dieselfde plek plaas, wat moontlik 'n Denial of Service (DoS) aan daardie hulpbron kan veroorsaak. Boonop kan die toepassing die X-forwarded-host kop erken en gebruikers na die gespesifiseerde gasheer herlei. Hierdie gedrag kan lei tot die laai van JavaScript-lêers van 'n aanvaller se bediener, wat 'n sekuriteitsrisiko inhou.
Cloudflare het voorheen 403-antwoorde gecache. Pogings om S3 of Azure Storage Blobs met onakkurate Owerheidskoppe te benader, sou 'n 403-antwoord lewer wat gecache is. Alhoewel Cloudflare opgehou het om 403-antwoorde te cache, kan hierdie gedrag steeds in ander proxy-dienste teenwoordig wees.
Caches sluit dikwels spesifieke GET-parameters in die cache-sleutel in. Byvoorbeeld, Fastly se Varnish het die size parameter in versoeke gecache. As 'n URL-gecodeerde weergawe van die parameter (bv. siz%65) egter ook met 'n foute waarde gestuur is, sou die cache-sleutel met die korrekte size parameter saamgestel word. Tog sou die agterkant die waarde in die URL-gecodeerde parameter verwerk. URL-gecodeer die tweede size parameter het gelei tot sy weglating deur die cache, maar sy gebruik deur die agterkant. Om 'n waarde van 0 aan hierdie parameter toe te ken, het gelei tot 'n cachebare 400 Bad Request-fout.
Sommige ontwikkelaars blokkeer versoeke met gebruikers-agente wat ooreenstem met dié van hoë-verkeer gereedskap soos FFUF of Nuclei om bedienerlaai te bestuur. Ironies, kan hierdie benadering kwesbaarhede soos cache poisoning en DoS inbring.
Die RFC7230 spesifiseer die aanvaarbare karakters in kopname. Koppe wat karakters buite die gespesifiseerde tchar reeks bevat, behoort idealiter 'n 400 Bad Request-antwoord te aktiveer. In praktyk hou bedieners nie altyd by hierdie standaard nie. 'n Opmerkelijke voorbeeld is Akamai, wat koppe met ongeldige karakters deurgee en enige 400-fout cache, solank die cache-control kop nie teenwoordig is nie. 'n Uitbuitbare patroon is geïdentifiseer waar die stuur van 'n kop met 'n onwettige karakter, soos \, 'n cachebare 400 Bad Request-fout sou lewer.
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Die doel van Cache Deception is om kliënte hulpbronne te laat laai wat deur die cache met hul sensitiewe inligting gestoor gaan word.
Eerstens, let daarop dat uitbreidings soos .css, .js, .png ens. gewoonlik gekonfigureer is om in die cache gestoor te word. Daarom, as jy toegang verkry tot www.example.com/profile.php/nonexistent.js, sal die cache waarskynlik die antwoord stoor omdat dit die .js uitbreiding sien. Maar, as die toepassing herhaal met die sensitiewe gebruikersinhoud wat in www.example.com/profile.php gestoor is, kan jy daardie inhoud van ander gebruikers steel.
Ander dinge om te toets:
www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
Gebruik minder bekende uitbreidings soos .avif
Nog 'n baie duidelike voorbeeld kan in hierdie skrywe gevind word: https://hackerone.com/reports/593712. In die voorbeeld word verduidelik dat as jy 'n nie-bestaande bladsy soos http://www.example.com/home.php/non-existent.css laai, die inhoud van http://www.example.com/home.php (met die gebruiker se sensitiewe inligting) gaan teruggegee word en die cache bediener gaan die resultaat stoor. Dan kan die aanvaller toegang verkry tot http://www.example.com/home.php/non-existent.css in hul eie blaaiert en die vertrouelijke inligting van die gebruikers wat voorheen toegang verkry het, waarneem.
Let daarop dat die cache proxy moet wees gekonfigureer om lêers te cache gebaseer op die uitbreiding van die lêer (.css) en nie gebaseer op die content-type nie. In die voorbeeld http://www.example.com/home.php/non-existent.css sal 'n text/html content-type hê in plaas van 'n text/css mime tipe (wat die verwagte vir 'n .css lêer is).
Leer hier oor hoe om Cache Deceptions aanvalle uit te voer wat HTTP Request Smuggling misbruik.
toxicache: Golang skandeerder om web cache poisoning kwesbaarhede in 'n lys van URL's te vind en verskeie inspuitings tegnieke te toets.
Gebruik Trickest om maklik te bou en werkvloei te automate wat deur die wêreld se mees gevorderde gemeenskap gereedskap aangedryf word. Kry Toegang Vandag:
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
