Les attaques contre les routeurs de classe “SOHO” (Small Office, Home Office) existent depuis un certain temps, et il existe même des Trojan, tels que Zlob.P, qui manipulent les routeurs du 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 dirigeant l’attaque à travers un client local, par exemple lors d’une attaque de type Cross-Site Request Forgery. Les inconvénients pour l’attaquant sont les suivants : il doit adapter son attaque à chaque routeur spécifique, l’attaquant 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 limitations peuvent être contournées avec une attaque de type DNS-Rebinding, qui se déroule de la manière suivante : un utilisateur est amené à charger du code JavaScript à partir du serveur de l’attaquant. Après le chargement, le nom de domaine du serveur de l’attaquant est lié à l’adresse IP du routeur local via le DNS-Rebinding. Ensuite, le code JavaScript peut envoyer des requêtes XMLHttpRequest vers le routeur sans aucune restriction imposée par la politique Same-Origin, car l’adresse IP utilisée pour l’envoi des requêtes est celle du domaine de l’attaquant. Les requêtes sont autorisées par la politique Same-Origin car l’origine du domaine est utilisée pour l’association et le code JavaScript provient du domaine sur lequel il accède.
DNS-Rebinding en général : un changement d’adresse IP pour un domaine
DNS-Rebinding peut être mieux expliqué à travers un exemple. Supposons que le serveur www.victime.exemple soit attaqué et qu’il possède l’adresse IP 1.2.3.4.
L’utilisateur accède au domaine de l’attaquant, www.attaquant.exemple, pour une raison quelconque, par exemple à cause d’une attaque de type Cross-Site Scripting. Pour cela, le navigateur doit demander l’adresse IP associée et reçoit l’adresse IP 9.8.7.6 du serveur DNS avec un délai de mise en cache (TTL) d’une seconde.
La page chargée contient une instruction de rafraîchissement après plus d’une seconde, par exemple, deux secondes. Le rafraîchissement peut être réalisé via la balise meta de rafraîchissement ou du code JavaScript.
Entre-temps, l’entrée DNS devient invalide 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 alors renvoyer n’importe quelle fausse adresse IP, par exemple l’adresse IP 1.2.3.4 de www.victime.exemple.
Lorsque le navigateur web accède à l’adresse IP 1.2.3.4, il pense qu’il se trouve sur www.attaquant.exemple, alors qu’il atterrit 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.
Le 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 répandue est 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 prochains accès à 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 est effectuée uniquement lorsque le délai de mise en cache expire 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 enregistre l’association entre les adresses IP et les noms de domaine dans son cache, indépendamment des paramètres TTL du DNS.
Les attaquants utilisent des attaques anti-DNS-Pinning pour contourner cette protection, en tentant d’empêcher la mise en cache et en forçant une deuxième requête DNS au cours de laquelle le nom de domaine de l’attaquant est lié à une autre adresse IP.
L’attaque DNS-Rebinding avec des adresses multiples
Une autre attaque DNS-Rebinding bien connue fonctionne avec 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 associer son nom de domaine, 1.2.3.4. Le navigateur de la victime se connecte à la première adresse IP indiquée et charge par exemple une page HTML contenant du code JavaScript malveillant. Une fois la page chargée, l’attaquant bloque les connexions provenant de l’adresse IP de la victime en ajustant les règles du pare-feu. Lorsque le code malveillant intégré envoie une requête XMLHttpRequest à www.attaquant.exemple, le serveur n’est pas accessible via la première adresse IP connue du navigateur, et il utilise donc la deuxième adresse IP connue, 1.2.3.4, qui appartient en réalité à www.victime.exemple. Ainsi, 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 les navigateurs préfèrent utiliser des adresses non routables. Même si l’adresse interne est la deuxième dans la réponse DNS, elle serait utilisée en premier par le navigateur. Ainsi, la première requête serait envoyée à l’adresse IP interne, ce qui empêcherait même le chargement du code malveillant de l’attaquant.
Ce qui est impossible à l’intérieur devient possible à l’extérieur
Craig Heffner a trouvé une solution à ce problème : il utilise l’adresse IP externe publique du routeur comme deuxième adresse IP. De nombreuses implémentations TCP/IP acceptent tous les paquets entrants, tant qu’ils sont adressés à l’une des propres adresses IP. L’adresse IP n’a pas besoin d’appartenir à l’interface via laquelle le paquet est reçu. En particulier, les paquets adressés à l’adresse IP externe sont également réceptionnés et traités à l’interface interne, ils n’atteignent donc jamais l’interface externe. Cette configuration peu sécurisée affecte, entre autres, 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 en accédant à son serveur.
Et un autre élément…
Un autre point faible contribue à la faisabilité de l’attaque développée par Craig Heffner : souvent, tous les services du routeur, en particulier le serveur web pour 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, ce qui empêche tout accès à l’interface d’administration depuis l’extérieur. Le fait que le trafic réseau soit identifié en fonction de l’interface et non de l’adresse IP est peu pratique, mais difficile à modifier, car l’adresse externe est généralement dynamiquement attribuée par le fournisseur d’accès Internet et peut donc changer à tout moment.
Qu’est-ce que cela signifie lorsque un 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 n’atteignent jamais l’interface externe.
Dans le prochain épisode, 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 – Protection des réseaux WLAN, mais la bonne façon de faire !
- “Hole196” – Une nouvelle vulnérabilité dans WPA2
- DNS-Rebinding : une attaque bien connue compromet les routeurs
- De l’extérieur vers l’intérieur via le client jusqu’au routeur
- Le “WPA Migration Mode” de Cisco ouvre la voie à un réseau WLAN
- Le NAT-Pinning, les attaques sur les réseaux WLAN Cisco et un outil
- Attaques sur le client WLAN
- BEAST – Une nouvelle attaque contre SSL et TLS 1.0
- Modifier la configuration du routeur via UPnP depuis Internet
- Sécurité des réseaux WLAN – Point de situation
- Vulnérabilité WPS : un danger pour les réseaux WLAN
