ARP Cache Poisoning Dans cet article je vais décrire brièvement le fonctionnement du protocole ARP et d'une attaque très connue mais aussi très efficace nommée le "ARP cache poisoning". Les exemples pratiques seront donnés seulement pour les OS Gnu/Linux pour la simple et bonne raison que ce sont pédagogiquement les plus intéressants. Pour ceux qui voudraient mettre en oeuvre cette technique sous Windows, je leur conseille de lire l'article pour bien comprendre la théorie et d'utiliser le logiciel Cain et Abel pour la mise en pratique : vous pouvez le télécharger sur http://www.oxid.it/cain.html, puis onglet sniffer -> APR. I - Introduction Vous avez sûrement déjà testé des sniffers sur votre réseau personnel. Et vous savez aussi que dans des réseaux dits "switchés" (c'est à dire 99% des réseaux actuels) leur intéret peut paraitre limité, puisque ormis les broadcasts (paquets envoyés à toutes les machines) vous ne recevez que le trafic qui vous est réellement destiné. Mais même dans un réseau de ce type, il est possible de mettre en oeuvre des techniques d'écoute du trafic et je vais vous en présenter une. II - Présentation du protocole ARP (Address Resolution Protocol) A quoi sert ce protocole? C'est simple, sur un réseau informatique chaque élément actif (carte réseau, switch) possède une adresse "physique" unique, lièe au constructeur et au modèle de l'élément. Elle est appelée adresse MAC (Medium Access Control) ou adresse Ethernet, ou addresse LAN, bref... 1 Mais pour que les ordinateurs de votre réseau communiquent entre eux en utilisant le protocole IP (celui qui permet notamment le routage) comme sur Internet ou dans votre LAN, ils utilisent des adresses IP, dites "logiques". Elles permettent d'être indépendant du matériel et un adressage dynamique. Il faut donc faire le lien entre MAC et IP : pour communiquer un ordinateur à besoin de connaitre l'addresse MAC associé à l'adresse IP de son interlocuteur. C'est justement le but du protocole ARP. Les correspondances sont contenues dans la table ARP (le "cache"), accessible en tapant "arp -a" sous Windows et Linux, par exemple : http://hackever.n0ne.org/article/image/arp1.png
Quand un ordinateur A veut communiquer avec un ordinateur B, il y a deux cas possibles : - l'adresse IP de B est présente dans la table arp, donc A connait l'adresse MAC associée et peux envoyer son message. - B n'est pas présent dans la table, A envoie donc une requète ARP en broadcast du type "Qui a cette adresse IP : XXX.XXX.XXX.XXX (adresse IP de B)? répondre à xx:xx:xx:xx:xx:xx ( adresse MAC de A )". Toutes les machines reçoivent donc cette requète mais seul B (normalement :p) y répond ( tout en ayant mis sa propre table à jour avec l'adresse de A contenue dans la requète ARP ) : "Salut je suis XXX.XXX.XXX.XXX, voici mon adresse MAC xx:xx:xx:xx:xx:xx" et ainsi les deux machines peuvent communiquer. Il y a donc deux types de requètes ARP : les "réponses" et les "demandes". Les premiers ARP cache poisoning étaient façilités par une erreur de conception des OS : chaque machine acceptait les réponses ARP qui lui étaient destinées, même si elle n'avait rien demandé. Désormais, ce n'est plus possible avec Windows XP et toutes les versions récentes de Linux qui corrigent ce bug. Mais le "détail" intéressant qui rend toujours ces attaques possibles est le fait que quand une machine reçoit une demande la concernant venant d'une adresse IP qu'elle connait, mais associé à une adresse MAC différente de ce qui est contenu dans son cache, elle écrase l'entrée existante pour la remplacer par la nouvelle correspondance. C'est cela qui rend possible le ARP cache poisoning avec les OS "modernes". III - Le ARP cache poisonning, ca poutre La majorité des techniques d'écoute de réseau se basent sur une des caractéristiques des protocoles de communication : il n'y a aucune vérification que l'adresse source d'un paquet reçu est réellement l'adresse de la machine source. C'est la manipulation de cette adresse (spoofing) qui rend possible l'écoute car la majorité des systèmes/logiciels supposent qu'elle est exacte. Passons à la mise en pratique, typiquement avec 3 machines la situation est la suivante :
ALICE BOB IP : 192.168.1.1 IP : 192.168.1.2 MAC : 00:00:00:AA:AA:AA MAC : 00:00:00:BB:BB:BB \ SWITCH / EVE IP : 192.168.1.3 MAC : 00:00:00:CC:CC:CC Alice et Bob sont donc nos deux machines "cibles" et Eve le gentil hacker (l'amour de la connaissance toussa). Pour pouvoir observer le trafic entre Alice et Bob, Eve va devoir faire croire à Alice qu'elle est Bob et à Bob qu'elle est Alice, tout en redirigant le trafic pour qu'ils aient l'impression de réellement communiquer entre eux sans intermédiaire. La première chose à faire pour Eve est d'acquèrir le maximum d'informations possibles : il est obligatoire pour elle de connaitre les adresses MAC et IP d'alice et Bob. Un simple scan du réseau suffit pour trouver les adresses IP, puis un ping rempli sa table ARP : Code: # ping 192.168.1.1... # ping 192.168.1.2... # arp -a? (192.168.1.2) at 00:00:00:BB:BB:BB [ether] on eth1? (192.168.1.1) at 00:00:00:AA:AA:AA [ether] on eth1 Bien maintenant l'attaque peut commencer, premièrement envoyer nos messages ARP trafiqués aux deux victimes. Pour cela nous allons utiliser l'outil Nemesis. Vous pouvez le récupérer sous Debian/Ubuntu avec "apt-get install nemesis", et pas les procédures d'intallation classique des autres distrib ("emerge" sous gentoo etc..). http://hackever.n0ne.org/article/image/arp2.png Envoyons le premier paquet "spoofés" à Alice :
http://hackever.n0ne.org/article/image/arp3.png Un broadcast est alors envoyé, demandant qui est 192.168.1.1, et de répondre à 00:00:00:CC:CC:CC, associé à l'ip 192.168.1.2. Alice répond en utilisant les coordonnées fournies dans le broadcast. On trouve donc dans la table ARP d'alice : Code: # arp -a? (192.168.1.2) at 00:00:00:CC:CC:CC [ether] on eth1 Pour répondre sur l'adresse IP de Bob, Alice enverra ses paquets à l'adresse MAC associé c'est à dire... Eve! De même sur Bob : http://hackever.n0ne.org/article/image/arp4.png Ainsi le trafic Alice <-> Bob passe automatiquement par Eve dans les deux sens. Il ne reste plus qu'à le rediriger pour ne pas éveiller les soupçons. Pour celà on peut utiliser IPtable ou Redir, en n'oubliant pas d'activer le IP forwarding (# echo "1" > /proc/sys/net/ipv4/ip_forward). Il ne faut pas perdre de vue que les tables ARP des machines suppriment régulièrement leur entrées lorsqu'elles ne sont pas utilisées. Ainsi pour ne pas perdre des paquets en route, il faut renouveler l'envoie de nos paquets "spoofés" dans un intervalle de temps assez court pour empécher les machines "cibles" de faire des demandes et de recevoir les vrais réponses ( même si vous les écrasez ensuite dans la table, vous avez perdu quelques paquets de la communication ). Il me semble que Cain utilise un intervalle de 5s, il suffit donc de faire un script qui renouvelle l'envoie toutes les 5s. IV - Parades La parade la plus naturelle serait de définir une table ARP "statique" c'est à dire en empèchant tout écrasement des entrées existantes et en les définissant à la main. Mais c'est lourd à mettre en oeuvre dès que votre réseau dépasse la dizaine de machines. La deuxième est l'utilisation d'outils spécialisés qui, en observant le réseau, détectent les signes d'arp cache poisonning ( fréquence élevé de paquets contradictoire avec les entrées de la table arp, requète en unicast etc..). Par exemple Arpwatch (http://www.securityfocus.com/tools/142). Finalement ce qui peut sembler le plus simple à mettre en oeuvre est l'authentification forte ( si Eve ne possède pas la clé privé d'alice et Bob, elle ne peut pas se faire passer pour eux ).
V - Conclusion Quelques remarques pour conclure : -cette attaque n'est possible que sur un LAN, mais rien ne vous empéche de la mettre en oeuvre entre une machine et le routeur internet pour observer le trafic vers le net. -une autre utilisation du ARP cache poisonning est la mise en oeuvre d'un DoS (Denial of Service) : vous pouvez isoler une machine du réseau en reçevant le trafic qui lui est destiné et en ne le redirigant pas. La machine est ainsi inacessible. - avec IPv6, le protocole ARP est remplacé par NDP (Neighbour Discovery Protocol), protocole similaire mais qui se situe plus haut dans la couche réseau (basé sur ICMPv6). Il n'est pas plus sécurisé mais par contre l'utilisation automatique de IPsec va surement rendre bien plus difficile le sniffing ^^. Ecrit par Kqkq. Lien original : http://hackever.n0ne.org/articlesmain.php?hacking=arppoisoning.html