Cache Poisoning and Cache Deception
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
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 je usmeren na manipulaciju kešom na strani klijenta kako bi se primorali klijenti 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:
Identifikacija neključenih ulaza: Ovo su parametri koji, iako nisu potrebni da bi zahtev bio keširan, mogu promeniti odgovor koji vraća server. Identifikacija ovih ulaza je ključna jer se mogu iskoristiti za manipulaciju kešom.
Eksploatacija neključenih ulaza: Nakon identifikacije neključenih ulaza, sledeći korak uključuje pronalaženje načina kako da se zloupotrebe ovi parametri kako bi se modifikovao odgovor servera na način koji koristi napadaču.
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.
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.
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:
Cache Poisoning to DoSMeđutim, imajte na umu da ponekad ovi tipovi status kodova nisu keširani, tako da ovaj test možda neće biti pouzdan.
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:
Sa identifikovanim parametrom/hedderom proverite kako se sanitizuje i gde se odražava ili utiče na odgovor iz hedera. Možete li to iskoristiti na bilo koji način (izvršiti XSS ili učitati JS kod koji kontrolišete? izvršiti DoS?...)
Kada ste identifikovali stranicu koja se može iskoristiti, koji parametar/heder koristiti i kako ga iskoristiti, 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 sledeći put biti 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. 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.
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:
Napomena da će ovo otrovati zahtev za /en?region=uk, a ne za /en
Kolačići se takođe mogu odraziti na odgovor stranice. Ako možete da ih zloupotrebite 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.
Napomena da ako je ranjavi kolačić veoma korišćen od strane korisnika, redovni zahtevi će čistiti keš.
Proverite:
Cache Poisoning via URL discrepanciesOvaj 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 Cloudflare normalizacije URL-a, što je urađeno kada je zahtev stigao do web servera.
Ovo je takođe bolje objašnjeno u:
Cache Poisoning via URL discrepanciesPonekad će vam 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.
Vary zaglavljemAko 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:
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 što je ranjivost koju je pronašao James Kettle na Github vebsajtu:
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
Na primer, moguće je odvojiti parametre na ruby serverima koristeći karakter ; umesto &. Ovo se može koristiti da se unkeyed vrednosti parametara stave unutar keyed parametara i zloupotrebe ih.
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
Saznajte ovde kako da izvršite Cache Poisoning napade zloupotrebom HTTP Request Smuggling.
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
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 backend-u kao /#/../?r=javascript:alert(1) i ključ keša nije imao payload unutar njega, samo host, putanju i upit.
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 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.
U Ruby on Rails aplikacijama, Rack middleware se često koristi. 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 određeni host. Ovo ponašanje može dovesti do učitavanja JavaScript datoteka sa servera napadača, predstavljajući sigurnosni rizik.
Cloudflare je ranije keširao 403 odgovore. Pokušaj pristupa S3 ili Azure Storage Blobs sa netačnim Authorization headerima rezultirao bi 403 odgovorom koji je keširan. Iako je Cloudflare prestao sa keširanjem 403 odgovora, ovo ponašanje može i dalje biti prisutno u drugim proxy servisima.
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-encoded verzija parametra (npr. siz%65) takođe poslata sa netačnom vrednošću, ključ keša bi bio konstruisan koristeći ispravan size parametar. Ipak, backend bi obradio vrednost u URL-encoded parametru. URL-encoding drugog size parametra doveo je do njegovog izostavljanja od strane keša, ali njegove upotrebe od strane backend-a. Dodeljivanje vrednosti 0 ovom parametru rezultiralo je keširanim 400 Bad Request greškom.
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.
RFC7230 definiše prihvatljive karaktere u imenima headera. Headeri koji sadrže karaktere van specificiranog tchar opsega bi idealno trebali izazvati 400 Bad Request odgovor. U praksi, serveri ne prate 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širanim 400 Bad Request greškom.
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cilj Cache Deception-a je da natera klijente da učitavaju resurse koji će biti sačuvani u kešu 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.
Napomena da bi cache 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 je očekivano za .css datoteku).
Saznajte ovde kako da izvršite Cache Deceptions napade zloupotrebom HTTP Request Smuggling.
toxicache: Golang skener za pronalaženje ranjivosti web cache poisoning u listi URL-ova i testiranje više tehnika injekcije.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
