Exploiter à distance une faille XSS sur un Intranet avec les cookies persistants et le DNS Rebinding

Par Xavier Poli, secuobs.com
Le 21/01/2009

---

Résumé : Une nouvelle technique, s'appuyant sur les attaques par DNS Rebinding, permet d'utiliser les cookies persistants d'un navigateur Web afin de placer une charge utile ayant pour objectif d'exploiter à distance une faille de type Cross Site Scripting présente sur un site Intranet local. - Lire l'article



Un chercheur spécialisé dans le domaine de la sécurité des applications web, Robert Hansen ( RSnake - lien ), vient de publier un article sur les différents risques que représentent l’utilisation des cookies de nature persistante avec les navigateurs Web les plus usuels. Par ce biais, il existe notamment des possibilités d’attaques à distance de type DNS Rebinding ( lien ) qui exposent les sites Intranet à des conséquences fâcheuses d’un point de vue sécuritaire.

Un scénario, qui pourrait probablement être envisagé pour une attaque de ce style, consisterait en la mise en place d’un environnement de test incluant conjointement un site Intranet, avec un FQDN ( lien ) équivalent par exemple à « intranet.exploitable.com » dont l’adresse IP résolue aurait pour valeur 10.10.10.10, et un second site distant, plus précisément celui de l’attaquant, présentant quant à lui le FQDN « www.attacker.com » pointant vers l’adresse IP correspondant à 222.222.222.222.

Coté pratique, l’utilisateur victime se connecte dans un premier temps via son navigateur sur le site Intranet « intranet.exploitable.com », celui-ci fixe un cookie ( lien ), qui présente, de manière involontaire, une vulnérabilité de type XSS Cross Site Scripting (voir notre dossier - lien ). Cette faille XSS pourrait être imputable à l’utilisation d’une solution faillible sur laquelle serait basée le site « intranet.exploitable.com » et que l’attaquant aurait pu au préalable identifier, en tant qu’ancien utilisateur ou intégrateur par exemple ou via un complice.

L’utilisateur victime est ensuite amené à visiter le site « www.attacker.com », par ingénierie sociale ( lien ) ou autres, qui va lui aussi fixer un cookie avec un nom similaire au cookie fixé auparavant par le site Intranet « intranet.exploitable.com ». Ce nouveau cookie va remplacer l’ancien tout en y injectant une charge utile dont l’objectif sera d’exploiter de façon concrète la faille XSS citée précédemment. A cette étape de l’attaque, il est alors nécessaire que l’utilisateur ferme son navigateur et toutes les instances qui lui sont relatives.

L’attaquant pourrait également forcer cette fermeture par l’emploi d’une attaque de Déni de Service DoS ( lien ) et cela à partir de l’exploitation d’une vulnérabilité propre au navigateur utilisé ou au système d'exploitation sous-jacent. L’attaquant, quant à lui, opère maintenant un changement au niveau de l’enregistrement DNS ( lien ) de son site Web « www.attacker.com » afin de faire pointer ce FQDN vers la même adresse IP que celle du serveur hébergeant le site « intranet.exploitable.com », en l’occurence 10.10.10.10.

Lors d’une prochaine ouverture de son navigateur, l’utilisateur est amené à retourner sur le site de l’attaquant « www.attacker.com », il sera redirigé vers le serveur à l’adresse IP 10.10.10.10 et non plus vers celui en 222.222.222.222 ; le navigateur ayant été fermé entre temps, le changement d’adresse IP a été pris en compte. En lieu et place de « www.attacker.com », il visite alors « intranet.exploitable.com », déclenchant ainsi la charge utile contenue dans le cookie de remplacement qui a persisté à la fermeture préalable du navigateur ; cette charge va exploiter la faille XSS précédemment citée.

Bien que cette exploitation ne puisse pas nativement permettre à l’attaquant de lire les cookies originaux de l’utilisateur et à s’authentifier de façon autonome sur le compte de la victime auprès du site « intranet.exploitable.com », cela pourrait néanmoins lui permettre de visualiser l’environnement actif de ce compte et de prendre le contrôle des fonctionnalités qui lui sont associés. Cette hypothèse peut être concrétisée par l’utilisation d’un canal XSS initié par une invite de commande XSS ( XSS Shell - lien ) faisant office de charge utile.

Même si le nom d'hôte « www.attacker.com », présent dans l’entête de la requête, diffère de celui du site réellement visité « intranet.exploitable.com », on constate que la requête est néanmoins traitée normalement par le serveur Web en charge de ce dernier ; ces serveurs ne portant pas une grande attention à ce genre d'irrégularités. Une valeur vide ne présentera pas plus de problème particulier, exception faite cependant des environnements d’hébergement virtuel ( Apache Virtual Host - lien ) où plusieurs sites Web sont configurés sur une même adresse IP.

Pour que l’attaque soit furtivement réalisable, il est impératif que la navigation de l’utilisateur sur « intranet.exploitable.com » ne soit pas liée à l’utilisation d’une session chiffrée à l’aide du protocole SSL ( voir notre dossier - lien ). L’utilisation des versions HTTPS s’avère même une solution efficace pour contrer ces attaques puisque l’utilisateur pourrait alors être alerté par une erreur de FQDN au niveau SSL sauf dans des cas exceptionnels aux conditions particulières ( lien ).

Malgré le fait que cette attaque puisse prendre un peu de temps à l’attaquant pour être réalisée avec succès, il n’en demeure pas moins qu’elle reste relativement aisée dans ses processus de mise en œuvre. Coté utilisateur, le moyen le plus efficace de la contrer reste à l’heure actuelle l’activation de la fonction de nettoyage automatique des cookies au sein du navigateur Web utilisé habituellement. Lors de chaque fermeture du navigateur, tous les cookies seront alors effacés et l’attaque impossible à réaliser.

Source : Ha.ckers ( lien )