dns-rebinding-attacks

À propos dns-rebinding-attacks

Un guide pratique sur les attaques par rebinding DNS, axé sur la technique côté client permettant de contourner la politique de même origine du navigateur en modifiant l’adresse IP associée à un nom d’hôte que la victime a déjà chargé. L’idée centrale est que la politique de même origine vérifie la chaîne de caractères du nom d’hôte, et non l’adresse IP résolue : un attaquant qui contrôle le DNS faisant autorité pour son domaine peut servir du code JavaScript malveillant lors de la première résolution (adresse IP de l'attaquant), puis ré-résoudre le même nom d'hôte vers une adresse IP interne. Le navigateur traite alors les requêtes adressées au service interne comme provenant de la même origine, et le script peut lire les réponses.

Cet article clarifie la distinction avec le SSRF, puisque le « DNS rebinding » en est l’équivalent côté client, et détaille les obstacles pratiques ainsi que les solutions de contournement. Comme les navigateurs disposent de leur propre cache DNS qui ignore les TTL faibles (environ 60 secondes dans Chrome, Edge et Firefox), cet article documente des stratégies de contournement, notamment l’attente de l’expiration du cache, les réponses comportant plusieurs enregistrements A avec blocage de l’adresse IP de l’attaquant pour forcer le repli, l’inondation de sous-domaines pour obtenir de nouvelles résolutions, et les délais imposés par les service workers. Les variantes d’attaque comprennent le rebinding HTTP classique, le rebinding WebSocket, un hybride TOCTOU côté serveur et l’approche rapide par enregistrements A multiples.

Utilisez-le lors du test d’applications qui s’appuient sur le DNS pour les vérifications d’origine ou qui effectuent des requêtes fetch/XHR côté client vers des domaines contrôlés par l’attaquant, en particulier lorsque le SSRF côté serveur n’est pas possible. Un tableau des cibles à forte valeur répertorie les métadonnées cloud (169.254.169.254), les API Docker et Kubernetes, les panneaux d'administration internes, Elasticsearch, Redis et Consul/etcd, avec une remarque indiquant que l’exigence de jeton d’IMDSv2 empêche la réaffectation car les en-têtes personnalisés ne peuvent pas être facilement définis en mode no-cors. Les outils couverts comprennent Singularity, le service rbndr.us sans configuration (avec un format de sous-domaine IP hexadécimal), whonow et des serveurs DNS Python minimalistes ; ce document établit également des recoupements avec les compétences relatives aux failles SSRF et aux erreurs de configuration CORS.

FAQ

En quoi le rebinding DNS diffère-t-il du SSRF ?

Le SSRF est une attaque côté serveur, tandis que la redirection DNS est son équivalent côté client, qui s’exécute dans le navigateur de la victime. Elle exploite le fait que la politique « same-origin » vérifie la chaîne du nom d’hôte, et non l’adresse IP résolue.

Pourquoi un TTL de 0 ne fonctionne-t-il pas immédiatement ?

Les navigateurs gèrent leur propre cache DNS qui ignore les TTL faibles (environ 60 secondes dans Chrome, Edge et Firefox) ; cette compétence couvre donc des techniques de contournement telles que l’attente, les enregistrements A multiples avec solution de secours, le déluge de sous-domaines et les délais liés aux service workers.

Quelles sont les cibles internes à forte valeur ajoutée ?

Les métadonnées cloud à l’adresse 169.254.169.254, l’API Docker, l’API Kubernetes, les panneaux d’administration internes, Elasticsearch sur le port 9200, Redis sur le port 6379, ainsi que Consul/etcd.

Le « rebinding » permet-il de voler des identifiants AWS à partir d’IMDSv2 ?

Pas facilement. IMDSv2 exige un en-tête « X-aws-ec2-metadata-token » dans une requête PUT, et la technique du « rebinding » ne permet pas de définir facilement des en-têtes personnalisés lors de la requête initiale de jeton en mode « no-cors ». IMDSv1 est plus vulnérable.

Quels outils recommande-t-il ?

Singularity (un framework complet), rbndr.us (aucune configuration requise, utilisant des sous-domaines de type « paire hexadécimale-adresse IP »), whonow (un serveur de rebinding dynamique) et des serveurs DNS Python personnalisés minimalistes.