ARP Cache Poisoning

L'ARP poisoning consiste à modifier l'association entre l'adresse IP (niveau 3) et l' adresse MAC, ou ethernet (niveau 2) d'une machine cible.

En effectuant ces modifications, il est possible de faire croire à une machine que l'adresse IP de son correspondant se trouve en fait à l'adresse Ethernet d'une machine pirate.

Rappel ARP

Les machines d'un réseau local utilisent un protocole de la couche Internet, appelé ARP, pour faire correspondre les adresses IP aux adresses physiques. Afin de lui envoyer des données, une machine source doit connaître l'adresse physique de la carte réseau de la machine de destination. Cependant, TCP/IP est implémenté de telle façon que ARP et les détails de translation d'adresses soient masqués à l'utilisateur. Celui-ci n'aura à se préoccuper que de l'adresse IP. Ainsi, en arrière plan, l'adresse IP doit être convertie en adresse physique afin que le message puisse atteindre sa destination.

Chaque machine du segment de réseau doit maintenir en mémoire une table appelée table ARP ou cache ARP. Le cache ARP associe les adresses IP d'autres machines du segment à leurs adresses physiques. Lorsqu'une machine a besoin d'envoyer des données à une autre machine du segment, elle vérifie le cache ARP afin de déterminer l'adresse physique du destinataire. Si l'adresse réceptrice des données n'est pas dans le cache ARP, la machine envoie un broadcast appelé trame de requête ARP.

La trame de requête ARP contient l'adresse IP non résolue. Elle contient également l'adresse IP et l'adresse physique de la machine qui a envoyé la requête. Les autres machines du segment du réseau reçoivent la requête ARP et la machine dont l'adresse n'était pas résolue répond en retournant son adresse physique à celle qui a émis la requête. Cette nouvelle correspondance adresse IP - adresse physique est alors ajoutée au cache ARP de la machine ayant émis la requête.

Les entrées du cache ARP ont une durée de vie prédéterminée. Lorsque ce temps est écoulé, l'entrée est supprimée de la table. Le processus de résolution recommence dès que la machine a besoin d'envoyer les données à l'adresse IP de l'entrée supprimée.

Trois propriétés du protocole ARP sont à noter, car importantes pour la suite :

• D'une part, aucune vérification n'est faite sur l'authenticité de l'adresse source. Cela signifie qu'un élèment réseau qui reçoit une trame ARP dont l'adresse source est 00:11:22:33:44:55 sera persuadé que le paquet reçu vient bien de cette interface
• Ensuite, quand un élèment reçoit une trame ARP Reply, et qu'il possède déjà une entrée pour associer cette adresse à une adresse IP (voire un port pour un routeur ou un switch, alors l'entrée sera mise à jour avec les informations contenues dans le paquet reçu (à moins que l'entrée soit statique)
• Enfin, aucun suivi d'état n'est fait. Cela signifie qu'une réponse ARP sera traitée même si aucune requête n'a été émise. Ceci parce que le protocole ARP a été conçu pour être le plus simple et le plus léger possible.

Ces trois propriétés permettent d'exploiter le protocole afin de rediriger un flux.

Attaque ARP

Les rappels de base étant faits, on peut maintenant s'intéresser à notre sujet : les attaques ManInTheMiddle en réseau local.

Si l'on a rappelé le principe du protocole ARP, c'est parce que c'est principalement lui, et son utilisation détournée, qui va nous permettre de détourner les flux de données au sein d'un réseau local. En effet, à sa création, il n'a été prévu aucun système de vérification des requêtes émises et reçues. Cela signifie que l'on peut envoyer des requêtes à une machine de façon à ce qu'elle modifie son cache ARP.

Supposons un réseau simple, constitué de deux machines A et B accédant à Internet par le biais d'un routeur R.

Lorsque A veut se connecter, elle va actualiser sa table ARP pour y placer le couple IP/MAC du routeur.

Le routeur fera de même avec le couple d'adresses du serveur auquel A veut se connecter.

On souhaite détourner ce flux de façon à ce qu'il passe par B.

Il suffit d'envoyer des requêtes ARP Reply à R, dans lesquelles on stipule que la machine avec l'IP de A possède l'adresse MAC de B. R va actualiser sa table, et enverra alors les paquets destinés à A vers B.

En faisant de même avec B (on envoie des requêtes stipulant que la machine avec l'IP de R possède l'adresse MAC de B), alors tout le flux transitant entre A et R passera désormais par B.

Il suffit d'activer le routage sur B pour laisser la connexion active.

L'envoi de paquets ARP peut se faire soit par l'intermédiaire de forgeurs de paquets (WinJect, hping2 entre autres), soit en utilisant des outils crées dans ce but. Arpoison en est un exemple ( site http://arpoison.sourceforge.net)

B se voit alors en mesure d'intercepter et modifier n'importe quel flux de données émis ou reçu par A. Lorsqu'on connait le nombre de protocoles ne cryptant pas leurs paquets, ou l'importance de la récupération des ISNs en vue de l'établissement d'une attaque par IP Spoofing, la position acquise ici est plus que confortable ;)

Mise en pratique

Rien ne vaut une bonne illustration pour remettre les choses au clair. La situation, quelle est-elle ?

Nous disposons d'un réseau comme suit :

Le but de la manipulation est de détourner le flux de A vers le routeur afin qu'il passe par B.

Nous devons tout d'abord faire croire au routeur que la machine avec l'IP 172.16.23.64 a pour adresse MAC 02:0E:A6:48:E2:47. Avec arpoison, cela se traduit par la commande suivante :

root@SoH#arpoison -i eth0 - d172.16.23.1 -s172.16.23.64 -t00: 01:01:F7:2F:90 -r 02:0E:A6:48:E2:47 -n1

Nous forgeons ainsi un paquet ARP Reply que nous envoyons au routeur (Se reporter au man page de arpoison pour plus de détails). Ce dernier adaptera alors sa table RAP en fonction des informations nouvelleement acquises, et nous recevrons donc alors tous les paquets émis du routeur en direction de A. Il faut ensuite faire de même pour rediriger les paquets émis par A en direction du routeur :

root@SoH#arpoison -i eth0 -d172.16.23.64 -s172.16.23.1 -t00: 13:D4:C7:FD:A4 -r 02:0E:A6:48:E2:47 -n1

Bien entendu, pour ne pas couper la connexion de A, il est nécessaire d'activer le routage sur B :

root@SoH#echo 1 > /etc/sys/net/ipv4/ip_forward

Vous êtes alors placés sur le chemin entre A et le routeur, et en mesure d'intercepter tout flux transitant entre eux deux. Vous êtes «l'Homme du Milieu» ;)