Les attaques sur les routeurs de la classe “SOHO” (Small Office, Home Office) sont courantes depuis un certain temps maintenant, et il existe même des logiciels malveillants, tels que Zlob.P, qui manipulent le routeur dans le réseau local d’un ordinateur Windows infecté. En général, un attaquant externe ne peut attaquer ces routeurs que de manière indirecte, en redirigeant l’attaque via un client local, par exemple lors d’une attaque de type Cross-Site-Request-Forgery. Les inconvénients pour l’attaquant sont nombreux : il doit adapter son attaque à chaque routeur spécifique, il doit deviner au moins le type de routeur ainsi que l’adresse IP interne. De plus, il ne peut pas voir les résultats de son attaque en raison de la politique Same-Origin des navigateurs web.
Toutes ces limites peuvent être contournées avec une attaque DNS-Rebinding, qui fonctionne comme suit : un utilisateur est incité à charger du code JavaScript à partir du serveur de l’attaquant. Une fois chargé, le nom de domaine du serveur de l’attaquant est lié à l’adresse IP du routeur local grâce au DNS-Rebinding. Ensuite, le code JavaScript peut envoyer des XMLHttpRequests au routeur sans être bloqué par la politique Same-Origin, car il est considéré comme provenant du même domaine que celui auquel il accède.
DNS-Rebinding en général : Un changement d’adresse IP pour un domaine
Le DNS-Rebinding peut être mieux expliqué à l’aide d’un exemple. Supposons que le serveur www.victime.exemple soit attaqué avec l’adresse IP 1.2.3.4.
- L’utilisateur accède à la page du serveur de l’attaquant www.attaquant.exemple pour une raison quelconque, par exemple à la suite d’une attaque de type Cross-Site-Scripting. Pour cela, le navigateur doit obtenir l’adresse IP correspondante auprès du serveur DNS compétent, qui lui indique l’adresse IP 9.8.7.6 avec un délai d’expiration (TTL) de la réponse DNS d’une seconde.
- La page chargée contient un appel de rafraîchissement après plus d’une seconde, par exemple deux secondes. Le rafraîchissement peut être effectué à l’aide de la balise meta rafraîchissement ou de code JavaScript.
- L’entrée DNS est maintenant obsolète car le TTL a expiré. L’adresse IP de www.attaquant.exemple est à nouveau demandée au serveur DNS. Le serveur DNS de l’attaquant peut maintenant renvoyer une fausse adresse IP, par exemple l’adresse 1.2.3.4 de www.victime.exemple.
- Lorsque le navigateur accède ensuite à l’adresse IP 1.2.3.4, il croit qu’il se trouve sur www.attaquant.exemple alors qu’il se trouve en réalité sur www.victime.exemple. Ainsi, par exemple, du code malveillant chargé à partir de www.attaquant.exemple peut accéder aux données de www.victime.exemple.
DNS-Pinning complique le DNS-Rebinding
Le DNS-Rebinding est un problème bien connu auquel les navigateurs web tentent de faire face de différentes manières. L’approche la plus courante consiste à utiliser le DNS-Pinning : la réponse à la première requête DNS effectuée par le navigateur pour un nom de domaine est mise en cache pendant une certaine période. Pour les requêtes ultérieures vers ce domaine, l’adresse IP mise en cache est utilisée et aucune autre requête DNS n’est effectuée. Une nouvelle requête DNS n’est effectuée que lorsque le délai du cache a expiré ou lorsque le navigateur est redémarré.
Avec le DNS-Pinning, l’attaque DNS-Rebinding décrite ci-dessus ne fonctionne pas, car le navigateur stocke indépendamment de la durée de vie des enregistrements DNS l’association entre les adresses IP et les noms de domaine dans son cache.
Les attaquants contournent le DNS-Pinning en utilisant des attaques anti-DNS-Pinning, qui tentent d’empêcher la mise en cache et de forcer une deuxième requête DNS, dans laquelle le nom de domaine de l’attaquant est lié à une autre adresse IP.
Attaque DNS-Rebinding avec des adresses doubles
Une autre attaque DNS-Rebinding bien connue utilise deux enregistrements “A”. La réponse du serveur DNS de l’attaquant à l’étape 2 de l’exemple contient alors deux adresses IP : l’adresse réelle de www.attaquant.exemple, 9.8.7.6, et l’adresse à laquelle l’attaquant souhaite lier son nom de domaine, 1.2.3.4. Le navigateur de la victime se connecte à la première adresse IP indiquée et y charge une page HTML contenant un code JavaScript malveillant. Une fois la page chargée, l’attaquant bloque par exemple les nouvelles connexions provenant de l’adresse IP de la victime en ajustant les règles de pare-feu. Si le code malveillant intégré envoie une demande XMLHttpRequest à www.attaquant.exemple, le serveur n’est pas accessible via la première adresse IP connue du navigateur, qui utilise alors la deuxième adresse IP connue, 1.2.3.4, qui appartient en réalité à www.victime.exemple – le DNS-Rebinding a réussi.
Dans cette attaque, les adresses IP internes, telles que celles du routeur, ne peuvent pas être utilisées car elles ne sont pas routables et les navigateurs les évitent. Même si l’adresse interne est la deuxième adresse dans la réponse DNS, le navigateur l’utilise en premier. Ainsi, la première requête serait déjà envoyée à l’adresse IP interne, de sorte que le code malveillant de l’attaquant ne serait pas chargé du tout.
Ce qui est impossible à l’intérieur devient possible à l’extérieur
Craig Heffner a trouvé une solution à ce problème : il utilise comme deuxième adresse IP l’adresse IP externe et publique du routeur, celle par laquelle il est accessible sur Internet. De nombreuses implémentations TCP/IP acceptent tous les paquets entrants dès lors qu’ils sont destinés à l’une des adresses IP propres. L’adresse IP n’a pas besoin d’appartenir à l’interface par laquelle le paquet est reçu. En particulier, les paquets adressés à l’adresse IP externe sont également acceptés par l’interface interne et traités immédiatement, ils ne parviennent donc pas à l’interface externe. Cette configuration non sécurisée concerne notamment Linux et de nombreux routeurs SOHO.
L’utilisation de l’adresse IP publique présente un autre avantage pour l’attaquant : il n’a pas besoin de connaître l’adresse IP interne du routeur. Et il obtient l’adresse publique lorsqu’il accède à son serveur.
Un dernier élément…
Une autre vulnérabilité contribue à rendre possible l’attaque développée par Craig Heffner : souvent, tous les services du routeur, notamment le serveur web de l’interface d’administration, sont liés à toutes les interfaces. Les connexions entrantes sur l’interface publique (WAN) sont généralement bloquées par des règles de pare-feu, de sorte qu’il est impossible d’accéder à l’interface d’administration depuis l’extérieur. Le trafic réseau est identifié en fonction de l’interface et non de l’adresse IP, ce qui est loin d’être idéal, mais difficile à changer, car l’adresse externe est généralement attribuée dynamiquement par le fournisseur d’accès à Internet et peut donc changer à tout moment.
Qu’est-ce que cela signifie lorsque le client interne souhaite accéder à l’adresse IP externe via l’interface interne ? L’accès est possible car les données sont déjà traitées par l’interface interne et elles ne parviendront jamais à l’interface externe, qui ne les accepterait pas.
Dans le prochain article, nous vous expliquerons comment ces attaques et vulnérabilités peuvent être utilisées pour attaquer l’interface d’administration basée sur le Web.
Carsten Eilers
Résumé de tous les articles sur le sujet
- WEP, WPA, WPA2 – Protégez votre réseau Wi-Fi correctement !
- “Hole196” – Une nouvelle vulnérabilité dans le WPA2
- DNS-Rebinding – Une attaque bien connue compromet les routeurs
- De l’extérieur vers le routeur via le client
- Le “mode de migration WPA” de Cisco ouvre la voie aux attaques sur les réseaux Wi-Fi
- NAT-Pinning, attaques sur les WLAN Cisco et un outil
- Attaques sur le client Wi-Fi
- BEAST – Une nouvelle attaque sur SSL et TLS 1.0
- Modifications de configuration du routeur via UPnP – depuis Internet
- Sécurité des réseaux Wi-Fi – État des lieux
- La vulnérabilité WPS met en danger les réseaux Wi-Fi
