Cache Poisoning via URL discrepancies

{% hint style="success" %} Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Consultez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.

{% endhint %}

Ceci est un résumé des techniques proposées dans le post https://portswigger.net/research/gotta-cache-em-all afin d'effectuer des attaques de cache poisoning en abusant des différences entre les proxies de cache et les serveurs web.

{% hint style="info" %} L'objectif de cette attaque est de faire croire au serveur de cache qu'une ressource statique est en cours de chargement afin qu'il la mette en cache, tandis que le serveur de cache stocke comme clé de cache une partie du chemin, mais le serveur web répond en résolvant un autre chemin. Le serveur web résoudra le chemin réel qui chargera une page dynamique (qui pourrait stocker des informations sensibles sur l'utilisateur, un payload malveillant comme XSS ou rediriger pour charger un fichier JS depuis le site de l'attaquant par exemple). {% endhint %}

Delimiters

Les délimiteurs d'URL varient selon le framework et le serveur, impactant la façon dont les requêtes sont routées et les réponses sont gérées. Certains délimiteurs d'origine courants sont :

Point-virgule : Utilisé dans Spring pour les variables de matrice (par exemple, /hello;var=a/world;var1=b;var2=c → /hello/world).
Point : Spécifie le format de réponse dans Ruby on Rails (par exemple, /MyAccount.css → /MyAccount).
Octet nul : Tronque les chemins dans OpenLiteSpeed (par exemple, /MyAccount%00aaa → /MyAccount).
Octet de nouvelle ligne : Sépare les composants d'URL dans Nginx (par exemple, /users/MyAccount%0aaaa → /account/MyAccount).

D'autres délimiteurs spécifiques peuvent être trouvés en suivant ce processus :

Étape 1 : Identifier les requêtes non mises en cache et les utiliser pour surveiller comment les URL avec des délimiteurs potentiels sont gérées.
Étape 2 : Ajouter des suffixes aléatoires aux chemins et comparer la réponse du serveur pour déterminer si un caractère fonctionne comme un délimiteur.
Étape 3 : Introduire des délimiteurs potentiels avant le suffixe aléatoire pour voir si la réponse change, indiquant l'utilisation d'un délimiteur.

Normalization & Encodings

Objectif : Les analyseurs d'URL dans les serveurs de cache et d'origine normalisent les URL pour extraire les chemins pour le mappage des points de terminaison et les clés de cache.
Processus : Identifie les délimiteurs de chemin, extrait et normalise le chemin en décodant les caractères et en supprimant les segments de points.

Encodings

Différents serveurs HTTP et proxies comme Nginx, Node et CloudFront décodent les délimiteurs différemment, ce qui entraîne des incohérences entre les CDN et les serveurs d'origine qui pourraient être exploitées. Par exemple, si le serveur web effectue cette transformation /myAccount%3Fparam → /myAccount?param mais que le serveur de cache conserve comme clé le chemin /myAccount%3Fparam, il y a une incohérence.

Une façon de vérifier ces incohérences est d'envoyer des requêtes URL en encodant différents caractères après avoir chargé le chemin sans aucun encodage et de vérifier si la réponse du chemin encodé provient de la réponse mise en cache.

Dot segment

La normalisation des chemins où des points sont impliqués est également très intéressante pour les attaques de cache poisoning. Par exemple, /static/../home/index ou /aaa..\home/index, certains serveurs de cache mettront en cache ces chemins avec eux-mêmes comme clés tandis que d'autres pourraient résoudre le chemin et utiliser /home/index comme clé de cache.
Tout comme précédemment, envoyer ce type de requêtes et vérifier si la réponse a été obtenue à partir du cache aide à identifier si la réponse à /home/index est la réponse envoyée lorsque ces chemins sont demandés.

Static Resources

Plusieurs serveurs de cache mettront toujours en cache une réponse si elle est identifiée comme statique. Cela peut être dû à :

L'extension : Cloudflare mettra toujours en cache les fichiers avec les extensions suivantes : 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
Il est possible de forcer un cache à stocker une réponse dynamique en utilisant un délimiteur et une extension statique comme une requête à /home$image.png qui mettra en cache /home$image.png et le serveur d'origine répondra avec /home
Répertoires statiques bien connus : Les répertoires suivants contiennent des fichiers statiques et donc leur réponse devrait être mise en cache : /static, /assets, /wp-content, /media, /templates, /public, /shared
Il est possible de forcer un cache à stocker une réponse dynamique en utilisant un délimiteur, un répertoire statique et des points comme : /home/..%2fstatic/something mettra en cache /static/something et la réponse sera /home
Dossiers statiques + points : Une requête à /static/..%2Fhome ou à /static/..%5Chome pourrait être mise en cache telle quelle mais la réponse pourrait être /home
Fichiers statiques : Certains fichiers spécifiques sont toujours mis en cache comme /robots.txt, /favicon.ico, et /index.html. Ce qui peut être abusé comme /home/..%2Frobots.txt où le cache pourrait stocker /robots.txt et le serveur d'origine répond à /home.