Breaking News
Home / Hacking / Tutoriels Hacking / ARP Poisoning

ARP Poisoning

I°) ARP Poisoning

Théorie
L'article du WatchGuard sur l'ARP Poisoning écrit "Les hackers mentent. Les hackers doués mentent bien. Et les hackers expérimentés peuvent mentir à la fois aux personnes et aux machines". Oui, l'art de l'ARP Poisoning est finalement l'organisation d'un gros mensonge à des machines qui peuvent être trop crédules.
Dans la partie sur la couche de liaison de données, nous avons expliqué le fonctionnement du protocole ARP. Le but de l'empoisonnement des caches ARP est simple, c'est d'envoyer des requêtes ARP de façon à ce que le cache d'un système soit réécrit avec les données que l'on veut et ceci est facilité par la flexibilité du protocole ARP. En réalité, l'idée est d'envoyer des paquets reply spoofés non-sollicités (c'est-à-dire qui ne font pas suite à un paquet ARPrequest). La conception d'ARP fait qu'une réponse non-sollicitée entraîne la réécriture du cache, comme si celle-ci faisait suite à une requête, tout simplement car il serait très couteux au niveau mémoire de retenir toutes les requêtes en local et parce qu'ARP a été conçu pour être un protocole simple et léger. Autrement dit, si un PC A envoie à un PC B une réponse ARP avec comme source un PC C, disant qu'il se trouve à 00:11:22:33:44:55, le PC B réécrira son cache ARP et associera l'IP du PC C avec l'adresse MAC fournie. Quand il voudra communiquer avec le PC C, il communiquera donc avec cette nouvelle adresse MAC. Vous comprenez désormais la puissance de ce type d'attaque, puisqu'elle permet de détourner n'importe quel flux réseau à sa guise. Etudions maintenant les 3 utilisations principales des ARP Poisoning.

MAC Flooding
Les attaques de type ARP Poisoning se retrouvent dans un réseau switché (par opposition aux réseaux hub, les réseaux switch ne distribuent pas tous les paquets sur tout le réseau, mais seulement aux destinataires, ce qui empêche le sniffing brut (puisque dans un réseau avec hub, il suffit de capturer les paquets arrivant sur eth0 pour avoir une vision de tout le traffic réseau, ce qui paraît relativement peu sécurisé). L'idée du MAC Flooding est d'utiliser une particularité de certains switchs : il arrive que quand certains switchs sont surchargés, ils passent en mode hub, ce qui leur évite de traiter beaucoup de données. Il suffit donc de flooder le switch avec beaucoup de fausses réponses ARP spoofées, ce qui va causer la surcharge du cache ARP et le passage en mode hub. Ainsi, l'attaquant peut sniffer le réseau entier tant que le switch est surchargé.

Denial of Service
Isoler un ordinateur paraît plutôt simple désormais. Si on empoisonne ses caches ARP en se faisant passer pour la passerelle du réseau et qu'on cause chez lui une fausse association entre l'IP de la passerelle et un MAC quelconque, dès qu'il voudra par exemple envoyer un paquet sortant du réseau vers Internet, il enverra ce paquet au MAC spécifié. Si le système présent au MAC spécifié ne reroute pas les paquets (le défaut sous UNIX par exemple), l'ordinateur ne peut plus communiquer avec l'extérieur, nous avons bien un Déni de Service. Il a été vu des attaques où les attaquants reroutaient tous les systèmes du réseau (en empoisonnant les caches de tout système duquel il voyait une transmission ARP quelconque). Ainsi, le réseau entier était coupé de l'extérieur. Ceci dit, il y a bien plus intéressant.

Man in the Middle
Effectivement, si on peut rediriger les flux réseaux, pourquoi ne pas se les envoyer ? Nous voici dans le principe de l'Active Sniffing qui consiste à faire en sorte que des paquets qui ne sont pas destinés au système local à y arriver et ensuite à les capturer. Cette technique s'appelle la redirection ARP. Finalement, la différence essentielle avec une attaque ARP de type DoS revient au reroutage des paquets. Pour cela, selon les systèmes, il faut modifier l'optionsip-forward de /etc/network/options à yes, ou ajouter la lignenet.ipv4.conf.default.forwarding=1 à /etc/sysctl.conf (ou du moins mettre l'option à 1 si elle était à 0). Maintenant nos paquets reroutés, voici ce qui va se passer :

  • On envoie un paquet spoofé à un système A, contenant pour source un système B en indiquant notre MAC. Le système A nous enverra donc ses paquets dès qu'il s'agira de communiquer avec B.
  • On envoie un paquet spoofé au système B, contenant pour source A en indiquant notre MAC. Le système B nous enverra donc ses paquets dès qu'il s'agira de communiquer avec A.
  • Dès qu'un paquet arrive sur notre système, il est rerouté s'il ne s'agit pas de notre IP. Ainsi, aucun des deux systèmes ne va, ni être DoS, ni se rendre compte de la supercherie. Il suffit de sniffer les paquets entrants du périphérique concerné pour lire les paquets que s'envoient ces deux systèmes.


Vous comprenez pourquoi on appelle cette technique "L'homme au milieu". En général, cette technique est utilisée entre un système cible et la passerelle, interceptant ainsi tous ses paquets externes. Elle est particulièrement redoutable contre les protocoles utilisant des identifications en clair, comme FTP, Telnet ou POP3.

Sécurisation
Bien que cette technique soit efficace à 100% sur une très grande majorité de réseaux, il est possible de l'éviter et cela est assez simple. Il faut demander la staticité des caches ARP : ainsi, dès la connexion d'un système au réseau et après le premier échange ARP, le cache est rempli et ne peut plus être réécrit par la suite. Bien sûr, c'est couteux sur des réseaux importants et présente un gros inconvénient sur un réseau personnel qui a besoin de flexibilité.

Nous allons maintenant illustrer les attaques de type Man-in-the-Middle avec un programme écrit en utilisant la librairie incontournable d'injection de paquets réseaux, libnet. Une connaissance du C est requise pour la compréhension du programme d'attaque que nous allons exposer dans cette section suivante.

 

 

Check Also

Scanner des failles VNC avec Dfind

    DOWNLOAD : Scanner des failles VNC avec Dfind Related posts:Injection SQLLes HTTP headers (en-têtes ...

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.