Cache Poisoning and Cache Deception

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Koristite Trickest da biste lako izgradili i automatizovali radne tokove pokretane najnaprednijim alatima zajednice na svetu. Dobijte pristup danas:

Razlika

Koja je razlika između trovanja keša veb stranica i prevare keša veb stranica?

  • U trovanju keša veb stranica, napadač uzrokuje da aplikacija sačuva zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.

  • U prevari keša veb stranica, napadač uzrokuje da aplikacija sačuva osetljiv sadržaj koji pripada drugom korisniku u kešu, a zatim napadač preuzima taj sadržaj iz keša.

Trovanje keša

Trovanje keša ima za cilj manipulisanje kešom na strani klijenta kako bi se naterali klijenti da učitavaju resurse koji su neočekivani, delimični ili pod kontrolom napadača. Obim uticaja zavisi od popularnosti pogođene stranice, jer zagađeni odgovor se servira isključivo korisnicima koji posećuju stranicu tokom perioda zagađenja keša.

Izvođenje napada trovanja keša uključuje nekoliko koraka:

  1. Identifikacija neindeksiranih ulaza: To 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.

  2. Iskorišćavanje neindeksiranih ulaza: Nakon identifikacije neindeksiranih ulaza, sledeći korak je saznati kako zloupotrebiti ove parametre kako bi se izmenio odgovor servera na način koji koristi napadaču.

  3. Osiguravanje da je zagađeni odgovor keširan: Poslednji korak je osigurati da je manipulisani odgovor sačuvan u kešu. Na ovaj način, svaki korisnik koji pristupa pogođenoj stranici dok je keš zagađen će dobiti zagađeni odgovor.

Otkrivanje: Provera HTTP zaglavlja

Obično, kada je odgovor sačuvan u kešu, postoji zaglavlje koje to pokazuje, možete proveriti na koja zaglavlja treba da obratite pažnju u ovom postu: HTTP zaglavlja keša.

Otkrivanje: Keširanje grešaka

Ako sumnjate da se odgovor čuva u kešu, možete pokušati slati zahteve sa lošim zaglavljima, na koje bi trebalo da se odgovori sa status kodom 400. Zatim pokušajte da pristupite zahtevu na uobičajen način i ako je odgovor status kod 400, znate da je ranjiv (i čak biste mogli izvesti DoS).

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

pageCache Poisoning to DoS

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

Otkrivanje: Identifikacija i procena neindeksiranih ulaza

Možete koristiti Param Miner da bruteforce parametre i zaglavlja koji mogu promeniti odgovor stranice. Na primer, stranica može koristiti zaglavlje X-Forwarded-For da bi pokazala klijentu da učita skriptu odatle:

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

Izazovite štetan odgovor od serverske strane

Sa identifikovanim parametrom/headerom proverite kako se filtrira i gde se odražava ili utiče na odgovor iz headera. Možete li ga zloupotrebiti na bilo koji 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 može biti zloupotrebljena, koji parametar/header koristiti i kako ga zloupotrebiti, trebate dobiti keširanu stranicu. Zavisno od resursa koji pokušavate dobiti u kešu, ovo može potrajati neko vreme, možda ćete morati pokušavati nekoliko sekundi. Header X-Cache u odgovoru može biti veoma koristan jer može imati vrednost miss kada zahtev nije bio keširan i vrednost hit kada je keširan. Header Cache-Control je takođe interesantan kako biste znali da li se resurs kešira i kada će sledeći put resurs ponovo biti keširan: Cache-Control: public, max-age=1800 Još jedan interesantan header je Vary. Ovaj header se često koristi da ukazuje na dodatne headere koji se tretiraju kao deo ključa keša čak i ako obično nisu ključni. Stoga, ako korisnik zna User-Agent žrtve koju cilja, može otrovati keš za korisnike koji koriste taj specifičan User-Agent. Još jedan header koji se odnosi na keš je Age. Definiše vreme u sekundama koliko je objekat bio u kešu proxy servera.

Prilikom keširanja zahteva, budite oprezni sa headerima koje koristite jer neki od njih mogu biti neočekivano korišćeni kao ključni i žrtva će morati koristiti isti header. Uvek testirajte Trovanje Keša sa različitim pregledačima da biste proverili da li radi.

Primeri eksploatacije

Najjednostavniji primer

Header poput X-Forwarded-For se odražava u odgovoru nefiltrirano. Možete poslati osnovni XSS payload i otrovati keš tako da će svako ko pristupi stranici biti izložen XSS napadu:

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

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

Trovanje keša za DoS

pageCache Poisoning to DoS

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

Kolačići takođe mogu biti reflektovani u odgovoru stranice. Ako možete zloupotrebiti to da izazovete XSS na primer, možete iskoristiti XSS u nekoliko klijenata koji učitavaju zlonamerni keš odgovor.

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

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

Trovanje keša sa prolazom putanje za krađu API ključa

Ovaj tekst 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 urađeno kada je zahtev stigao do veb servera.

Korišćenje više zaglavlja za iskorišćavanje ranjivosti trovanja keša na vebu

Ponekad će vam biti potrebno iskoristiti nekoliko neindeksiranih ulaza kako biste mogli zloupotrebiti keš. Na primer, možete pronaći Otvoreno preusmeravanje ako postavite X-Forwarded-Host na domen koji kontrolišete i X-Forwarded-Scheme na http. Ako je server prosleđivao sve HTTP zahteve na HTTPS i koristio zaglavlje X-Forwarded-Scheme kao ime domena za preusmeravanje. Možete kontrolisati gde će stranica biti 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 zaglavlje X-Host koristi kao ime domena za učitavanje JS resursa ali da Vary zaglavlje u odgovoru ukazuje na User-Agent. Zatim, trebate pronaći 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 cache server kešira onaj iz URL-a, svako ko pristupi tom URL-u zapravo će koristiti parametar iz tela. Kao ranjivost koju je Džejms Ketl pronašao na Github veb sajtu:

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

Parametarsko prikrivanje

Na primer, moguće je razdvojiti parametre u rubi serverima koristeći karakter ; umesto &. Ovo se može koristiti da se neindeksirane vrednosti parametara stave unutar indeksiranih i zloupotrebe istih.

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

Zloupotreba HTTP keš trovanja zloupotrebom HTTP zahteva za krijumčarenje

Saznajte ovde kako izvesti napade keš trovanja zloupotrebom HTTP zahteva za krijumčarenje.

Automatizovano testiranje za trovanje keša veb stranica

Alatka za skeniranje ranjivosti keša veb stranica može se koristiti za automatsko testiranje trovanja keša veb stranica. Podržava mnoge različite tehnike i visoko je prilagodljiva.

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

Koristite Trickest da lako kreirate i automatizujete radne tokove pokretane najnaprednijim alatkama zajednice na svetu. Pristupite danas:

Ranjivi primeri

Apache Traffic Server (CVE-2021-27577)

ATS je prosleđivao fragment unutar URL-a bez uklanjanja istog i generisao keš ključ koristeći samo host, putanju i upit (ignorišući fragment). Dakle, zahtev /#/../?r=javascript:alert(1) je poslat backend-u kao /#/../?r=javascript:alert(1) i keš ključ nije sadržavao payload unutar sebe, već samo host, putanju i upit.

GitHub CP-DoS

Slanje loše vrednosti u zaglavlju content-type pokrenulo je keširan odgovor 405. Keš ključ je sadržavao kolačić tako da je bilo moguće napasti samo neautentifikovane korisnike.

GitLab + GCP CP-DoS

GitLab koristi GCP buckete za skladištenje statičkog sadržaja. GCP Bucketi podržavaju zaglavlje x-http-method-override. Tako je bilo moguće poslati zaglavlje x-http-method-override: HEAD i otrovati keš tako da vrati prazno telo odgovora. Takođe je mogao podržavati metod PURGE.

Rack Middleware (Ruby on Rails)

U Ruby on Rails aplikacijama često se koristi Rack middleware. Svrsishodnost Rack koda je da uzme vrednost zaglavlja x-forwarded-scheme i postavi je kao šemu zahteva. Kada se pošalje zaglavlje x-forwarded-scheme: http, dolazi do 301 preusmerenja na istu lokaciju, što potencijalno može izazvati DoS na tom resursu. Dodatno, aplikacija može prepoznati zaglavlje X-forwarded-host i preusmeriti korisnike na određeni host. Ovo ponašanje može dovesti do učitavanja JavaScript fajlova sa servera napadača, što predstavlja sigurnosni rizik.

403 i skladišni bucketi

Ranije je Cloudflare keširao 403 odgovore. Pokušaj pristupa S3 ili Azure Storage Blobs sa neispravnim autorizacionim zaglavljima rezultovao bi 403 odgovorom koji bi bio keširan. Iako je Cloudflare prestao sa keširanjem 403 odgovora, ovo ponašanje može još uvek biti prisutno u drugim proxy servisima.

Umetanje indeksiranih parametara

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

Pravila korisničkog agenta

Neki programeri blokiraju zahteve sa korisničkim agentima koji se podudaraju sa onima visokoprometnih alatki poput FFUF ili Nuclei radi upravljanja opterećenjem servera. Ironično, ovaj pristup može uvesti ranjivosti poput trovanja keša i DoS-a.

Nelegalna zaglavlja

RFC7230 specificira prihvatljive karaktere u imenima zaglavlja. Zaglavlja koja sadrže karaktere van navedenog opsega tchar idealno bi trebala pokrenuti odgovor 400 Bad Request. U praksi, serveri se ne pridržavaju uvek ovog standarda. Značajan primer je Akamai, koji prosleđuje zaglavlja sa nevažećim karakterima i kešira svaku 400 grešku, sve dok zaglavlje cache-control nije prisutno. Identifikovan je iskoristiv obrazac gde slanje zaglavlja sa nevažećim karakterom, poput \, rezultuje keširanom greškom 400 Bad Request.

Pronalaženje novih zaglavlja

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

Trovanje keša

Cilj trovanja keša je da klijenti učitaju resurse koji će biti sačuvani u kešu sa njihovim osetljivim informacijama.

Pre svega, napomenimo da su ekstenzije poput .css, .js, .png itd. obično konfigurisane da se sačuvaju u kešu. Dakle, ako pristupite www.example.com/profile.php/nonexistent.js, keš će verovatno sačuvati odgovor jer vidi ekstenziju .js. Međutim, ako aplikacija ponavlja sa osetljivim korisničkim sadržajima sačuvanim u www.example.com/profile.php, možete ukrasti te sadržaje od drugih korisnika.

Drugi testovi:

  • 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 poput .avif

Još jedan veoma jasan primer može se naći u ovom izveštaju: https://hackerone.com/reports/593712. U primeru je objašnjeno da ako učitate nepostojeću stranicu poput 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 pregledaču i posmatrati poverljive informacije korisnika koji su pristupili prethodno.

Imajte na umu da bi keš proxy trebalo da bude konfigurisan da kešira fajlove na osnovu ekstenzije fajla (.css) a ne na osnovu tipa sadržaja. U primeru http://www.example.com/home.php/non-existent.css će imati text/html tip sadržaja umesto text/css MIME tipa (što se očekuje za .css fajl).

Saznajte ovde kako izvesti napade trovanja keša zloupotrebom HTTP zahteva za krijumčarenje.

Automatski alati

  • toxicache: Golang skener za pronalaženje ranjivosti otrovanja keša na vebu u listi URL-ova i testiranje više tehnika ubacivanja.

Reference

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

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Last updated