En enregistrant un nom de domaine qu’il contrôle, un attaquant peut manipuler les réponses DNS reçues par un client. Il peut ainsi contourner certains contrôles de sécurité mal implémentés dans le cadre d’une attaque dite de DNS rebinding. Le problème survient lorsqu’un client valide une adresse IP à des fins de sécurité, mais accède ensuite à la ressource via une adresse différente, par exemple à la suite d’une nouvelle résolution DNS.
Dans cet article, nous présenterons le fonctionnement du DNS rebinding ainsi que différents scénarios dans lesquels cette technique peut permettre d’accéder de manière non autorisée à des systèmes internes. Nous détaillerons également les principales mesures de sécurité permettant de s’en prémunir.
Le DNS rebinding exploite le fait qu’un nom de domaine n’est pas associé de manière permanente à une adresse IP. Un même domaine peut légitimement être résolu vers différentes adresses IP au fil du temps, selon les réponses DNS obtenues.
Cette propriété devient problématique lorsqu’un système vérifie l’adresse IP associée à un nom de domaine avant d’autoriser une requête, mais utilise ensuite de nouveau ce nom de domaine pour établir la connexion. Un attaquant contrôlant le domaine peut alors faire varier la réponse DNS entre ces deux étapes : le domaine peut d’abord pointer vers une adresse IP publique autorisée, puis vers une adresse IP privée, une adresse de bouclage ou une autre cible sensible.
La connexion est alors établie vers une ressource que le mécanisme de contrôle cherchait précisément à protéger.
Lorsqu’un serveur vérifie un nom de domaine fourni par un utilisateur en le résolvant une première fois, puis réutilise ultérieurement ce même nom pour récupérer du contenu, une fenêtre de type « time-of-check to time-of-use » (TOCTOU) peut apparaître. C’est précisément cet intervalle qu’une attaque par DNS rebinding peut exploiter.
Lors de la phase de vérification (time-of-check), le serveur interroge le DNS afin d’obtenir l’adresse IP associée au domaine. Celui-ci renvoie alors une adresse IP publique a priori légitime, conduisant la logique de validation à considérer la destination comme sûre.
Lors de la phase d’utilisation (time-of-use), le serveur effectue ensuite la requête HTTP en réutilisant le même nom d’hôte. Cette étape peut déclencher une nouvelle résolution DNS, par exemple parce que :
Si l’attaquant contrôle les réponses DNS du domaine, il peut alors renvoyer une adresse IP différente lors de cette seconde résolution. En utilisant notamment un TTL très court, il peut faire en sorte que le nom d’hôte considéré comme sûr quelques instants auparavant pointe désormais vers une adresse IP privée, une adresse de bouclage ou toute autre adresse interne sensible.
Le DNS rebinding est souvent associé aux attaques SSRF (Server-Side Request Forgery), car ces deux techniques peuvent permettre de pousser un serveur à envoyer des requêtes vers des destinations qui n’étaient pas prévues initialement. Une SSRF se produit lorsqu’une application récupère une ressource distante à partir d’une URL contrôlée par un attaquant et que celui-ci parvient à influencer la destination de la requête effectuée côté serveur.
Par exemple, une application vulnérable peut commencer par résoudre un nom d’hôte fourni par l’utilisateur afin de vérifier l’adresse IP correspondante. Si celle-ci est considérée comme sûre, l’application réutilise ensuite le même nom de domaine pour récupérer le contenu demandé. Cependant, cette seconde étape peut entraîner une nouvelle résolution DNS et retourner une adresse IP différente de celle précédemment validée, permettant ainsi de contourner le contrôle de sécurité.
app.get("/fetch", async (req, res) => {
try {
const url = new URL(req.query.url || "");
// TRUNCATED: Verify the URL scheme (HTTP or HTTPS)
// First resolution to verify the IP address of the provided hostname
const { address } = await dns.lookup(url.hostname);
if (isPrivateIp(address)) res.sendStatus(403);
// Second resolution to fetch content
const r = await fetch(url, { redirect: "manual" });
res.send(await r.text());
} catch {
res.sendStatus(500);
}
});
Le problème réside dans le décalage entre la validation et l’utilisation de l’adresse IP. La décision de sécurité repose sur une première résolution DNS, tandis que la connexion réseau peut s’appuyer sur une résolution ultérieure, sans garantie que les deux retournent la même adresse IP. Autrement dit, l’application considère le nom d’hôte comme un identifiant stable, alors que le contrôle de sécurité porte en réalité sur une réponse DNS obtenue à un instant donné. Entre la validation et l’établissement de la connexion, la destination associée au nom d’hôte peut donc changer.
Pour limiter ce risque, la validation et l’utilisation doivent porter sur la même cible réseau. Une approche consiste, par exemple, à effectuer une seule résolution DNS, à valider l’adresse IP obtenue, puis à s’assurer que cette même adresse est utilisée pour établir la connexion. Une autre possibilité consiste à effectuer la validation directement au moment de l’établissement de la connexion, afin d’éviter qu’une nouvelle résolution puisse modifier la destination entre ces deux étapes.
Dans le scénario précédent, une approche plus sûre consiste ainsi à vérifier que l’adresse IP validée est bien celle effectivement utilisée pour établir la connexion. Avec Node.js, il est notamment possible de fournir un agent de requête personnalisé disposant d’une fonction de résolution DNS. Celle-ci effectue la résolution et applique la politique de sécurité (par exemple, le blocage des plages d’adresses IP privées au moment même de la connexion). Cette approche supprime ainsi le décalage entre la vérification et l’utilisation susceptible d’être exploité par le DNS rebinding.
import { fetch, Agent } from "undici";
const dispatcher = new Agent({
connect: {
lookup: (hostname, options, cb) => {
dns.lookup(hostname, options, (err, address, family) => {
if (err) return cb(err);
if (isPrivateIp(address)) return cb(new Error("blocked"));
cb(null, address, family);
});
}
}
})
app.get("/fetch", async (req, res) => {
try {
const url = new URL(req.query.url || "");
// TRUNCATED: Verify the URL scheme (HTTP or HTTPS)
// The dispatcher uses the valided resolution to establish a connection
const r = await fetch(url, { redirect: "manual", dispatcher });
res.send(await r.text());
} catch {
res.sendStatus(500);
}
});
De nombreuses bibliothèques clientes HTTP permettent de personnaliser le mécanisme de résolution DNS. Cela permet d’appliquer les mêmes contrôles de sécurité lors de chaque nouvelle connexion, notamment lorsqu’une redirection entraîne une nouvelle résolution.
Lorsque la bibliothèque utilisée ne permet pas de contrôler la résolution DNS, une autre approche consiste à fixer explicitement l’adresse IP utilisée pour établir la connexion et à désactiver les redirections automatiques. Chaque éventuelle redirection peut alors être traitée séparément et faire l’objet des mêmes contrôles avant qu’une nouvelle connexion ne soit établie.
Même lorsqu’une application ne résout qu’une seule fois un nom d’hôte contrôlé par un attaquant, une attaque par DNS rebinding peut rester possible si cette unique résolution DNS renvoie plusieurs adresses IP. En effet, de nombreux clients HTTP ne considèrent pas le résultat d’une résolution DNS comme une adresse IP unique, mais comme un ensemble d’adresses candidates. Lors de l’établissement de la connexion, le client peut alors tenter successivement plusieurs de ces adresses jusqu’à ce que l’une d’entre elles aboutisse.
Cette variante du DNS rebinding ne nécessite pas deux requêtes DNS distinctes. Le domaine contrôlé par l’attaquant renvoie plusieurs enregistrements au sein d’une même réponse DNS : généralement une adresse IP publique sous son contrôle et une seconde adresse correspondant à la cible visée. Certains clients considèrent ces différentes adresses comme des candidats à la connexion et peuvent basculer de l’une à l’autre lorsque la première tentative échoue, expire ou est réinitialisée.
Dans le contexte d’un navigateur, l’attaquant peut maintenir sa première adresse IP accessible suffisamment longtemps pour servir une page contenant du code JavaScript. Le navigateur associe alors ce script à une origine définie notamment par le nom d’hôte, et non à l’adresse IP utilisée pour établir la connexion. Une fois le script chargé, celui-ci peut déclencher de nouvelles requêtes vers le même nom d’hôte. Si la connexion à la première adresse IP échoue, le navigateur peut tenter d’utiliser une autre adresse issue de la réponse DNS initiale.
Le nom d’hôte restant identique, ces nouvelles requêtes peuvent toujours être considérées comme appartenant à la même origine. Pourtant, la connexion réseau peut désormais atteindre la seconde adresse IP, correspondant par exemple à un service interne. Le code JavaScript contrôlé par l’attaquant peut alors tenter d’interagir avec ce service, contournant potentiellement certains contrôles réseau qui reposent sur l’hypothèse qu’un site externe ne peut pas atteindre directement les ressources du réseau interne.
À titre d’exemple, un attaquant peut configurer son serveur DNS pour renvoyer simultanément les enregistrements suivants :
attacker.example. 0 IN A $ATTACKER_SERVER
attacker.example. 0 IN A 192.168.20.4L’attaquant peut ensuite héberger une page contenant le code HTML suivant. Après un délai de dix secondes, le script effectue une nouvelle requête vers la même origine. Si la connexion vers le serveur de l’attaquant n’est alors plus disponible et que le navigateur utilise la seconde adresse IP, la requête peut être dirigée vers le serveur interne.
<h1>PoC DNS Rebinding</h1>
<script>
setTimeout(() => {
fetch("/", { cache: "no-store" }).then((x) => x.text()).then((x) => alert(x))
}, 10000)
</script>
Dans certaines configurations de Firefox, ce scénario peut permettre à la page de l’attaquant de rester ouverte tandis que le contenu renvoyé par le serveur interne est récupéré par le script. L’impact peut alors se rapprocher de celui d’une vulnérabilité XSS, puisque du code JavaScript contrôlé par l’attaquant peut interagir avec une application normalement inaccessible depuis Internet.
Ce scénario est toutefois davantage limité par les protections mises en œuvre dans les navigateurs modernes. Chrome, notamment, intègre des mécanismes visant à restreindre les requêtes initiées depuis un contexte public vers des ressources situées sur un réseau privé (Private Access Network specification). Ces protections réduisent les possibilités d’exploitation, sans pour autant rendre le DNS rebinding systématiquement inopérant. Selon la topologie réseau, la configuration du navigateur et l’accessibilité de la cible, le navigateur de la victime peut encore constituer un intermédiaire permettant d’atteindre des services autrement protégés par des restrictions réseau.
Plusieurs mesures peuvent être combinées pour se protéger contre ce type d’attaque. L’utilisation de navigateurs modernes permet tout d’abord de bénéficier des mécanismes de protection limitant les accès depuis des contextes publics vers des ressources privées. Au niveau de l’infrastructure, les résolveurs DNS peuvent également mettre en œuvre des mécanismes de DNS rebinding protection, notamment en filtrant les réponses suspectes associant des noms de domaine externes à des adresses IP privées.
Enfin, les interfaces web sensibles accessibles depuis un réseau interne ne doivent pas reposer uniquement sur leur inaccessibilité depuis Internet comme mécanisme de sécurité. L’utilisation de TLS, d’une authentification robuste et d’une validation stricte des noms d’hôte permet de réduire davantage les possibilités d’exploitation.
Le DNS est un mécanisme complexe et le DNS rebinding peut, par essence, être considéré comme une vulnérabilité classique de type « time-of-check to time-of-use » (TOCTOU).
La phase de vérification correspond au moment où l’application valide une destination, par exemple en résolvant un nom d’hôte et en vérifiant que l’adresse IP obtenue est autorisée. La phase d’utilisation correspond, quant à elle, à l’établissement effectif de la connexion réseau. Celle-ci peut intervenir après une nouvelle résolution DNS, une nouvelle tentative de connexion ou encore une redirection. Lorsque ces deux étapes ne reposent pas sur la même destination, un attaquant peut parvenir à modifier la cible de la connexion après sa validation.
Les mesures de protection suivent donc les mêmes principes que pour les vulnérabilités TOCTOU classiques : effectuer la validation au moment de l’utilisation, en appliquant les contrôles de sécurité lors de la résolution utilisée pour établir la connexion, ou effectuer une résolution unique et verrouiller l’adresse IP obtenue, tout en contrôlant strictement les redirections et les nouvelles tentatives de connexion.
Dans le cas des attaques exploitant le navigateur d’une victime, l’application ne maîtrise pas l’ensemble du processus de résolution et de connexion. Il est donc essentiel d’adopter une approche de défense en profondeur afin de réduire les différents vecteurs d’exploitation. Les protections intégrées aux navigateurs modernes, notamment celles relatives aux accès aux réseaux privés, peuvent ainsi être complétées par des mécanismes de protection contre le DNS rebinding au niveau des résolveurs DNS, afin de filtrer les noms d’hôte publics qui se résolvent vers des plages d’adresses IP privées.
Auteur : Arnaud PASCAL – Pentester @Vaadata
