Cache Poisoning via URL discrepancies
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Questo è un riepilogo delle tecniche proposte nel post https://portswigger.net/research/gotta-cache-em-all per eseguire attacchi di cache poisoning abusando delle discrepanze tra i proxy di cache e i server web.
L'obiettivo di questo attacco è far credere al server di cache che una risorsa statica stia venendo caricata in modo che la memorizzi nella cache mentre il server di cache memorizza come chiave di cache parte del percorso, ma il server web risponde risolvendo un altro percorso. Il server web risolverà il percorso reale che caricherà una pagina dinamica (che potrebbe memorizzare informazioni sensibili sull'utente, un payload malevolo come XSS o reindirizzare per caricare un file JS dal sito web dell'attaccante, per esempio).
I delimitatori URL variano a seconda del framework e del server, influenzando come le richieste vengono instradate e le risposte gestite. Alcuni delimitatori di origine comuni sono:
Punto e virgola: Usato in Spring per variabili di matrice (es. /hello;var=a/world;var1=b;var2=c → /hello/world).
Punto: Specifica il formato di risposta in Ruby on Rails (es. /MyAccount.css → /MyAccount)
Byte nullo: Trunca i percorsi in OpenLiteSpeed (es. /MyAccount%00aaa → /MyAccount).
Byte di nuova linea: Separa i componenti URL in Nginx (es. /users/MyAccount%0aaaa → /account/MyAccount).
Altri delimitatori specifici potrebbero essere trovati seguendo questo processo:
Passo 1: Identificare le richieste non memorizzabili nella cache e usarle per monitorare come vengono gestiti gli URL con potenziali delimitatori.
Passo 2: Aggiungere suffissi casuali ai percorsi e confrontare la risposta del server per determinare se un carattere funge da delimitatore.
Passo 3: Introdurre potenziali delimitatori prima del suffisso casuale per vedere se la risposta cambia, indicando l'uso del delimitatore.
Scopo: I parser URL sia nei server di cache che in quelli di origine normalizzano gli URL per estrarre percorsi per il mapping degli endpoint e le chiavi di cache.
Processo: Identifica i delimitatori di percorso, estrae e normalizza il percorso decodificando i caratteri e rimuovendo i segmenti di punto.
Diversi server HTTP e proxy come Nginx, Node e CloudFront decodificano i delimitatori in modo diverso, portando a incoerenze tra CDNs e server di origine che potrebbero essere sfruttate. Ad esempio, se il server web esegue questa trasformazione /myAccount%3Fparam → /myAccount?param ma il server di cache mantiene come chiave il percorso /myAccount%3Fparam, c'è un'incoerenza.
Un modo per controllare queste incoerenze è inviare richieste URL codificando caratteri diversi dopo aver caricato il percorso senza alcuna codifica e controllare se la risposta del percorso codificato proviene dalla risposta memorizzata nella cache.
La normalizzazione del percorso in cui sono coinvolti i punti è anche molto interessante per gli attacchi di cache poisoning. Ad esempio, /static/../home/index o /aaa..\home/index, alcuni server di cache memorizzeranno questi percorsi con se stessi come chiavi mentre altri potrebbero risolvere il percorso e usare /home/index come chiave di cache.
Proprio come prima, inviare questo tipo di richieste e controllare se la risposta è stata raccolta dalla cache aiuta a identificare se la risposta a /home/index è la risposta inviata quando quei percorsi vengono richiesti.
Diversi server di cache memorizzeranno sempre una risposta se è identificata come statica. Questo potrebbe essere dovuto a:
L'estensione: Cloudflare memorizzerà sempre nella cache file con le seguenti estensioni: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
È possibile forzare una cache a memorizzare una risposta dinamica utilizzando un delimitatore e un'estensione statica come una richiesta a /home$image.png che memorizzerà nella cache /home$image.png e il server di origine risponderà con /home
Directory statiche ben note: Le seguenti directory contengono file statici e quindi la loro risposta dovrebbe essere memorizzata nella cache: /static, /assets, /wp-content, /media, /templates, /public, /shared
È possibile forzare una cache a memorizzare una risposta dinamica utilizzando un delimitatore, una directory statica e punti come: /home/..%2fstatic/something memorizzerà nella cache /static/something e la risposta sarà /home
Directory statiche + punti: Una richiesta a /static/..%2Fhome o a /static/..%5Chome potrebbe essere memorizzata nella cache così com'è, ma la risposta potrebbe essere /home
File statici: Alcuni file specifici sono sempre memorizzati nella cache come /robots.txt, /favicon.ico, e /index.html. Che possono essere abusati come /home/..%2Frobots.txt dove la cache potrebbe memorizzare /robots.txt e il server di origine risponde a /home.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
