DNSChanger, le malware qui réécrit vos réglages DNS

DNSChanger est un cheval de Troie qui remplace les serveurs DNS déclarés sur un poste ou sur un routeur, de sorte que toutes les résolutions de noms passent par un résolveur contrôlé par l'attaquant. La famille d'origine, démantelée par le FBI en novembre 2011, avait infecté environ 4 millions de machines dans plus de 100 pays, et la technique reste réutilisée aujourd'hui contre les box et routeurs grand public.

Ce que DNSChanger modifie exactement

Le DNS traduit un nom en adresse IP (RFC 1034 et 1035, port 53 en UDP et TCP). Celui qui choisit le résolveur choisit donc la réponse. DNSChanger ne casse rien et n'exploite aucune faille du protocole : il change une valeur de configuration. Sur Windows, la variante historique écrivait la valeur NameServer sous HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}. Sur macOS, la famille RSPlug/Jahlav, diffusée dès 2007 sous la forme d'un faux codec vidéo à installer pour lire une vidéo, ajoutait une tâche cron qui réappliquait les serveurs pirates à intervalle régulier. Corriger le réglage dans les préférences réseau ne servait à rien tant que la tâche restait en place.

Le second étage est plus gênant. Depuis la machine infectée, le code testait les identifiants d'usine de l'interface d'administration du routeur local, en 192.168.0.1 ou 192.168.1.1, avec les couples classiques admin/admin ou admin sans mot de passe. Une fois entré, il remplaçait le DNS distribué par le serveur DHCP du routeur. À partir de là, un téléphone, une console ou une télé connectée qui n'a jamais été infecté reçoit quand même le résolveur pirate au moment où il prend son bail DHCP. Désinfecter le PC ne suffit plus.

L'objectif était publicitaire, pas destructeur, ce qui explique que la plupart des victimes n'aient rien remarqué : les sites s'affichaient normalement. Rove Digital, la société estonienne derrière l'opération, substituait les régies sur les pages consultées et redirigeait une partie des clics, une fraude chiffrée à 14 millions de dollars par le ministère américain de la Justice. Certaines variantes bloquaient en plus la résolution des domaines de mise à jour des antivirus et de Windows Update, laissant la machine sans correctif pendant des mois.

Operation Ghost Click et la panne du 9 juillet 2012

Le 8 novembre 2011, le FBI annonce l'opération Ghost Click : six ressortissants estoniens sont arrêtés, un septième suspect russe reste en fuite. Vladimir Tsastsin, à la tête de Rove Digital, sera extradé aux États-Unis et plaidera coupable en 2015. Le problème pratique se pose immédiatement : couper les serveurs pirates privait des millions de machines de toute résolution de noms. Sur autorisation d'un juge, l'ISC (Internet Systems Consortium) a donc exploité des résolveurs propres sur les mêmes adresses IP, d'abord jusqu'au 8 mars 2012, puis jusqu'au 9 juillet 2012 après prolongation.

Ce jour-là, les machines encore configurées sur ces plages ont perdu Internet du point de vue de l'utilisateur. Cas de panne typique et facile à reconnaître : un ping 8.8.8.8 par adresse IP répond, une page web par nom retourne « serveur introuvable ». Le FBI estimait qu'un peu plus de 200 000 machines étaient toujours concernées début juillet 2012.

Les plages ci-dessous sont celles publiées à l'époque par le FBI. Elles n'ont plus d'usage opérationnel aujourd'hui, sauf pour lire un vieux ticket ou un ancien log : les sites de vérification de l'époque, comme dns-ok.us du DNS Changer Working Group, ne sont plus en ligne et ne doivent pas servir de test.

La technique, elle, n'a pas disparu. En décembre 2016, Proofpoint documentait un kit d'exploitation baptisé DNSChanger EK, diffusé par publicité malveillante, qui identifiait l'adresse IP privée du visiteur via WebRTC puis attaquait son routeur en visant 166 modèles. En septembre 2018, Netlab 360 décrivait la campagne GhostDNS, qui a détourné plus de 100 000 routeurs, en grande majorité au Brésil, pour rediriger le trafic vers de faux sites bancaires.

Plage de résolveurs pirates (FBI)	Notation CIDR
85.255.112.0 à 85.255.127.255	85.255.112.0/20
67.210.0.0 à 67.210.15.255	67.210.0.0/20
93.188.160.0 à 93.188.167.255	93.188.160.0/21
77.67.83.0 à 77.67.83.255	77.67.83.0/24
213.109.64.0 à 213.109.79.255	213.109.64.0/20
64.28.176.0 à 64.28.191.255	64.28.176.0/20

Vérifier quel résolveur répond vraiment

Le réflexe utile n'est pas de chercher un nom de virus, c'est de lire la configuration effective, poste par poste, puis sur le routeur. Un résolveur inconnu qui n'est ni celui de votre FAI, ni celui que vous avez choisi, ni l'adresse de la box, mérite une explication.

Le test le plus parlant tient en une ligne : dig +short whoami.akamai.net. Le serveur faisant autorité renvoie l'adresse IP publique du résolveur qui lui a transmis votre requête, pas la vôtre. Si vous croyez utiliser 1.1.1.1 et que la réponse est une adresse hébergée dans un pays sans rapport, quelque chose s'intercale. Comparez ensuite dig +short exemple.fr et dig +short exemple.fr @1.1.1.1 : deux adresses différentes pour un domaine stable sont un signal, à nuancer si le domaine est servi par un CDN en géo-répartition.

Sur le routeur, ouvrez l'interface d'administration et regardez deux champs distincts : le DNS utilisé côté WAN et le DNS annoncé aux clients par le serveur DHCP. Les campagnes de type GhostDNS ne touchent souvent que le second, ce qui laisse l'administrateur croire que le routeur est sain parce que la page WAN affiche encore les serveurs du FAI.

• Windows : ipconfig /all, ou netsh interface ipv4 show dnsservers pour ne voir que les résolveurs. nslookup affiche aussi le serveur interrogé sur sa première ligne.
• macOS : scutil --dns | grep nameserver. Ne vous fiez pas à /etc/resolv.conf seul, il est généré et peut mentir sur l'état réel.
• Linux avec systemd-resolved : resolvectl status, qui donne le résolveur par interface.
• Vérification croisée : dig +short whoami.akamai.net pour connaître l'IP publique du résolveur réellement utilisé.
• Routeur ou box : champ DNS du WAN et champ DNS distribué par le DHCP, à contrôler séparément.

Ne pas confondre avec l’empoisonnement de cache ou le détournement de domaine

Quatre attaques différentes se rangent dans le langage courant sous « piratage DNS », et elles ne se corrigent pas au même endroit. DNSChanger s'attaque au client : votre machine ou votre routeur interroge sagement un serveur, mais ce n'est pas le bon. L'empoisonnement de cache s'attaque au résolveur récursif lui-même, en y injectant une fausse entrée (la faille Kaminsky de 2008 en est l'exemple, les contre-mesures sont décrites dans la RFC 5452). Le détournement de zone se joue chez le registrar, en changeant les serveurs NS déclarés pour le domaine, et affecte alors tous les visiteurs du monde entier.

Autre confusion fréquente, plus bénigne : changer volontairement de DNS pour 1.1.1.1, 9.9.9.9 ou 8.8.8.8 n'a évidemment rien d'une infection. La différence tient à qui a fait le changement et s'il est réversible. Un réglage que vous corrigez et qui revient tout seul au bout de quelques minutes est un symptôme, quelle que soit l'adresse configurée.

Attaque	Ce qui est modifié	Où se corrige la panne
DNSChanger	Le serveur DNS déclaré sur le poste ou le routeur	Configuration réseau locale, firmware du routeur
Empoisonnement de cache	Une entrée dans le cache d'un résolveur récursif	Côté opérateur du résolveur, validation DNSSEC
Détournement de zone	Les serveurs NS déclarés chez le registrar	Compte registrar, verrou de transfert, 2FA
Interception sur le réseau	Les réponses DNS en clair sur le port 53	DoT en 853 (RFC 7858) ou DoH en 443 (RFC 8484)

Reprendre la main sur la résolution

L'ordre compte : nettoyez le routeur avant les postes, sinon le prochain bail DHCP réinjecte le résolveur pirate sur une machine que vous venez de corriger. Et coupez le Wi-Fi des appareils que vous ne pouvez pas inspecter pendant l'opération.

Sur le chiffrement, une précision qui évite une fausse sécurité. DNSSEC (RFC 4033 à 4035) authentifie les données de la zone, mais si votre résolveur stub ne valide pas lui-même les signatures, un résolveur malveillant peut simplement répondre sans données DNSSEC et vous n'y verrez rien. DoH et DoT protègent le trajet vers un résolveur que vous avez choisi, ce qui neutralise l'interception réseau et rend le détournement plus visible. Aucun des deux n'arrête un malware qui tourne avec les droits administrateur sur la machine : il changera aussi le résolveur DoH configuré dans le navigateur. Ces protections réduisent la surface, elles ne remplacent pas la désinfection.

• Connectez-vous à l'interface du routeur, remettez les DNS voulus côté WAN et côté DHCP, puis changez le mot de passe d'administration : les identifiants d'usine sont la porte d'entrée exploitée depuis 2011.
• Désactivez l'administration accessible depuis le WAN et l'UPnP si vous n'en avez pas l'usage, mettez le firmware à jour.
• Si l'équipement est ancien et non maintenu, une réinitialisation d'usine suivie d'une reconfiguration manuelle vaut mieux qu'un correctif ponctuel.
• Sur chaque poste, repassez le DNS en automatique ou sur le résolveur de votre choix, videz le cache (ipconfig /flushdns sous Windows, resolvectl flush-caches sous Linux), puis passez un antimalware à jour.
• Contrôlez le fichier hosts, souvent modifié en parallèle : C:\Windows\System32\drivers\etc\hosts ou /etc/hosts.
• Revérifiez 24 heures plus tard : la persistance par tâche planifiée ou par cron ne se voit qu'au retour du réglage.

Questions fréquentes

DNSChanger est-il encore actif aujourd’hui ?

Le botnet de Rove Digital est mort : les serveurs de remplacement de l'ISC ont été éteints le 9 juillet 2012 et les plages IP concernées n'ont plus de rôle. La technique, elle, a été reprise, notamment par le kit d'exploitation documenté par Proofpoint en décembre 2016 et par la campagne GhostDNS en 2018. Aujourd'hui, le détournement vise le routeur bien plus souvent que le poste de travail.

Comment savoir si ma box est touchée ?

Regardez dans l'interface d'administration les deux champs DNS, celui du WAN et celui distribué par le DHCP, et comparez-les à ce que vous avez configuré. Depuis un poste du réseau, la commande dig +short whoami.akamai.net indique l'IP publique du résolveur qui traite réellement vos requêtes. Un résolveur que vous n'avez pas choisi est à traiter comme suspect jusqu'à explication.

Un antivirus suffit-il à régler le problème ?

Non, s'il n'a nettoyé que la machine. L'antivirus ne voit pas la configuration du routeur, et c'est là que le réglage pirate persiste dans les campagnes récentes. Il faut ouvrir l'interface d'administration, corriger les DNS et changer le mot de passe d'usine, sinon la réinfection des autres appareils continue via le DHCP.

Utiliser 1.1.1.1 ou 9.9.9.9 me protège-t-il de DNSChanger ?

Seulement si cette configuration est celle qui s'applique vraiment. Un malware qui a les droits d'écriture sur les réglages réseau peut la remplacer aussi facilement que celle de votre FAI. Un résolveur public de qualité réduit d'autres risques, comme l'interception sur le réseau local quand il est utilisé en DoH ou DoT, mais il n'empêche pas la réécriture du réglage.

DNSSEC empêche-t-il ce type de détournement ?

Pas dans ce scénario. DNSSEC signe les réponses au niveau de la zone et protège surtout contre l'empoisonnement de cache et la falsification en transit. Si votre stub resolver ne valide pas lui-même les signatures, un résolveur malveillant répond sans données DNSSEC et la vérification n'a jamais lieu. La protection utile ici est la maîtrise de la configuration et du routeur.

Testez vos connaissances

À lire aussi

cheval de troie · cloudflare dns 1 1 1 1 · commande dig · box internet