DNS Rebinding.

Dans une attaque de DNS rebinding, l'attaquant contrôle un serveur DNS faisant autorité pour un domaine comme evil.example.com et répond avec un TTL très court (souvent 1 seconde). Le navigateur de la victime résout d'abord le nom vers l'IP publique de l'attaquant et charge du JavaScript, ce qui satisfait la same-origin policy. Un instant plus tard, le serveur de l'attaquant relie le même nom à une adresse interne comme 192.168.1.1, 127.0.0.1 ou une IP de métadonnées cloud (169.254.169.254). Comme l'origine (schéma, hôte, port) ne change pas du point de vue du navigateur, le JavaScript déjà chargé peut émettre des requêtes vers l'API HTTP de la cible interne, lire les réponses et déclencher des actions privilégiées sur des équipements qui font confiance à tout appelant local.

La technique est ancienne — elle remonte à l'« attaque de Princeton » de 1996 contre Java — mais elle resurgit sans cesse contre les services locaux non authentifiés. En janvier 2018, Tavis Ormandy, de Google Project Zero, a montré que l'Update Agent de Blizzard exposait un serveur JSON-RPC sur localhost:1120 qui ne validait jamais l'en-tête Host : une page rebindée pouvait ainsi piloter des commandes privilégiées sur les machines de dizaines de millions de joueurs ; quelques jours plus tôt, il avait démontré la même classe de faille dans le client BitTorrent Transmission. Des hubs domotiques, des outils de développement et des interfaces d'administration de routeurs ont été atteints ainsi. Le rebinding sert aussi de pivot courant vers le vol de type SSRF d'identifiants cloud depuis le point de terminaison de métadonnées 169.254.169.254.

Les défenses opèrent aux couches applicative et réseau : valider l'en-tête Host/Origin sur chaque service local, exiger une authentification même sur localhost, épingler les réponses à HTTPS (le certificat TLS ne correspondra pas à l'IP rebindée) et faire rejeter par les résolveurs toute réponse associant un nom public à une plage RFC 1918, loopback ou métadonnées (« DNS pinning » et filtrage des IP privées).

flowchart TD
  V[Navigateur de la victime] -->|1. visite evil.example.com| A[Serveur web de l'attaquant]
  A -->|2. sert du JS, TTL DNS = 1s| V
  V -->|3. re-resout evil.example.com| D[Serveur DNS de l'attaquant]
  D -->|4. rebind vers 192.168.1.1<br/>ou 169.254.169.254| V
  V -->|5. le JS same-origin<br/>appelle la cible interne| T[Routeur / metadonnees / API IoT]
  T -->|6. reponse lue par le JS attaquant| A