Qu'est-ce que le DNS rebinding et pourquoi s'en soucier ?

La plupart des contrôles de sécurité qui impliquent un domaine supposent que son adresse IP est assez stable pour être validée une fois, puis crue sur parole. Le DNS rebinding exploite précisément cette hypothèse. Un attaquant contrôle le DNS d'un domaine et le configure pour qu'il se résolve d'abord vers une adresse IP publique normale, ce qui passe toute validation effectuée par le système visé, puis qu'il change la réponse pour une adresse interne (comme 127.0.0.1 ou une plage interne 10.x.x.x) lors d'une requête ultérieure, une fois le contrôle déjà passé.

Pourquoi ce n'est pas qu'une astuce théorique

Un TTL très court rend l'attaque praticable : l'attaquant règle l'enregistrement pour qu'il expire en quelques secondes, de sorte qu'un contrôle de validation et la requête réelle qui le suit peuvent voir deux réponses différentes, à quelques millisecondes d'écart, sans que le système victime s'aperçoive que le terrain a bougé sous ses pieds. Tout système qui résout un domaine une seule fois et réutilise cette IP pour plusieurs opérations, ou pire, qui le résout une fois pour la validation et laisse un autre composant le résoudre de nouveau pour la vraie requête, est potentiellement exposé.

La seule défense fiable

Valider une chaîne de nom d'hôte ne suffit pas, et valider une IP une seule fois non plus. La seule défense robuste consiste à comparer l'adresse réellement résolue à une liste de blocage des plages privées et internes, au moment même où la connexion est établie, à chaque fois et pas seulement lors de la validation initiale. Cela referme la faille temporelle dont dépend le rebinding, car il n'existe plus de fenêtre entre « vérifié » et « utilisé » pendant laquelle la réponse pourrait changer.

• Bloquez les plages privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), de bouclage (127.0.0.0/8), de lien local (169.254.0.0/16) et les points de terminaison de métadonnées cloud, aussi bien en IPv4 qu'en IPv6.
• Revérifiez à chaque utilisation, pas seulement une fois lors de la validation de la saisie.
• Traitez une adresse IPv6 mappée sur IPv4 (comme ::ffff:127.0.0.1) comme équivalente à l'adresse IPv4 qu'elle contient : les tentatives de rebinding utilisent parfois précisément cet encodage pour déjouer un contrôle naïf limité à l'IPv6.

Où cela a compté en pratique

Le DNS rebinding n'est pas une préoccupation académique marginale : il a été utilisé à maintes reprises contre des routeurs domestiques, des hubs domotiques et d'autres appareils qui exposent une interface d'administration locale sans authentification, en partant du principe que seul du trafic local de confiance pourrait jamais l'atteindre. Une page web malveillante, ouverte dans un onglet de navigateur ordinaire sur le même réseau, peut recourir au rebinding pour que le propre navigateur de la victime, déjà jugé fiable par le routeur du simple fait qu'il se trouve sur le réseau local, envoie des requêtes directement à cette interface d'administration pour le compte de l'attaquant. Le navigateur croit tout le temps parler au domaine public d'origine ; seule la réponse DNS en dessous a changé.

Une variante plus subtile : le rebinding à réponses multiples

Une version plus sophistiquée évite complètement d'attendre l'expiration d'un TTL. Une seule réponse DNS peut légitimement contenir plus d'un enregistrement A, et certains logiciels clients les essaient simplement dans l'ordre, voire les alternent en round-robin d'une requête à l'autre. Un attaquant peut renvoyer à la fois une adresse publique légitime et une adresse interne dans la même réponse, en comptant sur le fait que le client finira par essayer la seconde entrée : pas d'attente, pas de fenêtre temporelle, il suffit d'exploiter le fait que le DNS n'a jamais été conçu pour garantir que toutes les adresses d'une réponse multiple soient également dignes de confiance. C'est un bon rappel que « vérifier la première adresse renvoyée » n'est jamais suffisant : chaque adresse d'une réponse doit être examinée avec la même rigueur.