Vous êtes sur la page 1sur 5

ARP Cache Poisoning

Dans cet article je vais dcrire brivement le fonctionnement du protocole ARP et d'une attaque trs connue mais aussi trs efficace nomme le "ARP cache poisoning". Les exemples pratiques seront donns seulement pour les OS Gnu/Linux pour la simple et bonne raison que ce sont pdagogiquement les plus intressants. Pour ceux qui voudraient mettre en oeuvre cette technique sous Windows, je leur conseille de lire l'article pour bien comprendre la thorie et d'utiliser le logiciel Cain et Abel pour la mise en pratique : vous pouvez le tlcharger sur http://www.oxid.it/cain.html, puis onglet sniffer -> APR. I - Introduction Vous avez srement dj test des sniffers sur votre rseau personnel. Et vous savez aussi que dans des rseaux dits "switchs" (c'est dire 99% des rseaux actuels) leur intret peut paraitre limit, puisque ormis les broadcasts (paquets envoys toutes les machines) vous ne recevez que le trafic qui vous est rellement destin. Mais mme dans un rseau de ce type, il est possible de mettre en oeuvre des techniques d'coute du trafic et je vais vous en prsenter une. II - Prsentation du protocole ARP (Address Resolution Protocol) A quoi sert ce protocole ? C'est simple, sur un rseau informatique chaque lment actif (carte rseau, switch) possde une adresse "physique" unique, lie au constructeur et au modle de l'lment. Elle est appele adresse MAC (Medium Access Control) ou adresse Ethernet, ou addresse LAN, bref... 1 Mais pour que les ordinateurs de votre rseau 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 indpendant du matriel 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 prsente dans la table arp, donc A connait l'adresse MAC associe et peux envoyer son message. - B n'est pas prsent dans la table, A envoie donc une requte ARP en broadcast du type "Qui a cette adresse IP : XXX.XXX.XXX.XXX (adresse IP de B) ? rpondre xx:xx:xx:xx:xx:xx ( adresse MAC de A )". Toutes les machines reoivent donc cette requte mais seul B (normalement :p) y rpond ( tout en ayant mis sa propre table jour avec l'adresse de A contenue dans la requte 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 requtes ARP : les "rponses" et les "demandes". Les premiers ARP cache poisoning taient failits par une erreur de conception des OS : chaque machine acceptait les rponses ARP qui lui taient destines, mme si elle n'avait rien demand. Dsormais, ce n'est plus possible avec Windows XP et toutes les versions rcentes de Linux qui corrigent ce bug. Mais le "dtail" intressant qui rend toujours ces attaques possibles est le fait que quand une machine reoit une demande la concernant venant d'une adresse IP qu'elle connait, mais associ une adresse MAC diffrente de ce qui est contenu dans son cache, elle crase l'entre 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 rseau se basent sur une des caractristiques des protocoles de communication : il n'y a aucune vrification que l'adresse source d'un paquet reu est rellement l'adresse de la machine source. C'est la manipulation de cette adresse (spoofing) qui rend possible l'coute car la majorit des systmes/logiciels supposent qu'elle est exacte. Passons la mise en pratique, typiquement avec 3 machines la situation est la suivante :

ALICE IP : 192.168.1.1 MAC : 00:00:00:AA:AA:AA \ \ \ \ \____ SWITCH | |

BOB IP : 192.168.1.2 MAC : 00:00:00:BB:BB:BB / / / / ___/

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 rellement communiquer entre eux sans intermdiaire. La premire chose faire pour Eve est d'acqurir 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 rseau 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, premirement envoyer nos messages ARP trafiqus aux deux victimes. Pour cela nous allons utiliser l'outil Nemesis. Vous pouvez le rcuprer sous Debian/Ubuntu avec "apt-get install nemesis", et pas les procdures d'intallation classique des autres distrib ("emerge" sous gentoo etc..). http://hackever.n0ne.org/article/image/arp2.png Envoyons le premier paquet "spoofs" Alice :

http://hackever.n0ne.org/article/image/arp3.png Un broadcast est alors envoy, demandant qui est 192.168.1.1, et de rpondre 00:00:00:CC:CC:CC, associ l'IP 192.168.1.2. Alice rpond en utilisant les coordonnes 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 rpondre sur l'adresse IP de Bob, Alice enverra ses paquets l'adresse MAC associ c'est dire... Eve ! De mme 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 soupons. 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 rgulirement leur entres lorsqu'elles ne sont pas utilises. Ainsi pour ne pas perdre des paquets en route, il faut renouveler l'envoie de nos paquets "spoofs" dans un intervalle de temps assez court pour empcher les machines "cibles" de faire des demandes et de recevoir les vrais rponses ( mme 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 dfinir une table ARP "statique" c'est dire en empchant tout crasement des entres existantes et en les dfinissant la main. Mais c'est lourd mettre en oeuvre ds que votre rseau dpasse la dizaine de machines. La deuxime est l'utilisation d'outils spcialiss qui, en observant le rseau, dtectent les signes d'ARP cache poisonning ( frquence lev de paquets contradictoire avec les entres de la table arp, requte 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 possde 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 empche 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 rseau en reevant 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 rseau (bas sur ICMPv6). Il n'est pas plus scuris 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

Vous aimerez peut-être aussi