Les attaques "Man In the Middle" (MIM) sur un réseau local sont les pires qui puissent exister, et elles ne sont pas si difficile que ça à mettre en oeuvre. Il s'agit, pour une machine ayant de mauvaises intentions, d'arriver à faire en sorte que la communication entre deux ordinateurs cibles passe par l'intermédiaire de la machine attaquante, et ceci de manière invisible. Ce type d'attaque est extrêmement puissante, car l'attaquant peut espionner toute la communication et modifier au passage ce qu'il veut, ce qui en pratique revient souvent à la compromission d'au moins un des deux systèmes mis en jeu, à la découverte des mots de passe, etc, etc...

Cette attaque a été utilisée par les pirates de la conférence DEFCON 9 de Las Vegas. J'ai déjà parlé dans le HZV 7 de l'icmp_redirect (la machine attaquante se fait passer pour un routeur). Une autre possibilité est d'exploiter le protocole ARP qui permet de faire la correspondance entre les adresses physiques et les adresses IP (car la communication entre deux ordinateurs sur un réseau local ne se fait pas par rapport aux adresses IP, mais par rapport aux adresses physiques !). En faisant croire à une machine victime que l'adresse physique de la machine avec laquelle elle veut communiquer est en fait notre propre adresse physique, on récupère tous les paquets qu'elle envoie même s'ils ne sont pas destinés à notre adresse IP ! Ceci est possible grace au protocole ARP... (mais ne fonctionne que sur le réseau local)

Je vais vous détailler une attaque qui a été utilisée par les pirates de la conférence DEFCON 2001 à Las Vegas.

Le protocole ARP (pour Address Resolution Protocol) est utilisé par toutes les machines pour connaitre l'adresse physique (qui est l'adresse MAC de la carte réseau sur un réseau ETHERNET) d'une machine dont on connait l'adresse IP. Typiquement, lorsque vous tapez "www.securityfocus.com", vous avez trois étapes :

A partir de là, la transaction de résolution de nom peut être effectuée avec le serveur DNS ("à quelle ip correspond www.securityfocus.com ?", réponse du DNS: "1.2.3.4").

Considérons que l'adresse physique du routeur est connue (on lui a déjà demandé par exemple pour aller voir le site www.antionline.com et l'adresse physique du routeur est dans la table de correspondances ARP (disons de:ad:ba:db:ee:ff pour l@MAC du routeur)). A ce propos, le système conserve une table contenant les dernières correspondances @IP/@MAC

trouvées, et cette table est mise a jour regulièrement. Vous pouvez la consulter en tapant "arp -a".

Dans ce cas, notre machine n'a qu'à envoyer la requête HTTP pour voir la page du site securityfocus en mettant comme @IP destination la valeur 1.2.3.4 et comme @MAC destination celle du routeur utilisé (de:ad:ba:db:ee:ff). Le routeur se charge de transmettre cette requête, et on récuperera la réponse du serveur HTTP comme il se doit.

Bon, je suis allé un peu loin pour cette introduction au protocole ARP, la partie qui nous concerne directement est celle ou je parle d'ARP request et d'ARP reply !!! Le reste c'est pour votre culture generale (enjoy :)))

Je n'ai pas lu à fond la RFC sur ARP (=> il peut y avoir des erreurs dans ce que je dis), mais en observant le fonctionnement sur le reseau "gris" de la Defcon9, j'ai compris que le protocole ARP fonctionnait de la maniere suivante :

Si l'@IP dont on recherche la correspondance n'est pas connue, on envoie directement une requête en broadcast physique (ff:ff:ff:ff:ff:ff).

Si il s'agit de la confirmer, on ne fait pas de broadcast physique, mais seulement un unicast vers l'@MAC précédemment enregistrée. Dans le cas ou nous n'aurions pas reçu de réponse au bout de plusieurs requêtes, nous effectuons la requête en broadcast physique.

Voici des exemples tout droit tirés du dump ramené de la Defcon9. J'ai récupéré ces logs grace à tcpdump sous linux, c'est un sniffeur qui permet de voir tout ce qui passe sur le réseau. Pour ne sélectionner que le trafic ARP, qui était ce à quoi je m'intéressais, j'ai utilisé un filtre avec la commande 'tcpdump -n arp -w fichier_log_arp'.

Tou d'abord, je dois vous prevenir : je ne sais pas avec quel programme cette attaque a ete effectuee... dans le domaine du MIM utilisant l'ARP poisonning, il y a le choix !

Je vais vous montrer comment j'ai analyse et observe son fonctionnement pour comprendre ce qu'il faisait. Tout a commence lorsque j'ai vu sur le reseau un paquet de requetes ARP provenant de la machine 10.255.0.192 (on va l'appeler evil_box). Ca m'a semble enormement bizarre et je me suis mis a logguer le traffic tout en l'observant grace a tcpdump. Voici ce que ca donnait :

(les commentaires sont a lire APRES l'explication placee sous le dump... ils sont la pour que vous compreniez mieux lors de la deuxieme lecture et pour se placer du point de vue du programme (soit sur evil_box) :)

# chouette ! enfin un qui reponds ! :) je l'ajoute dans ma liste de correspondances et je continue

Ici nous pouvons donc observer ces fameuses requetes ARP qui montrent tout de meme que quelque chose de pas clair est en cours... Une machine qui cherche a connaitre les @MAC de toutes les machines du reseau, c'est pas tres courant ! Peu de machines repondent car la plupart des IP sont libres ou les machines sont eteintes...

# au terme de ce premier cycle, nous connaissons deux correspondances @IP/@MAC :

Le programme continue, à intervalles reguliers et aggressifs, de faire ces requetes sur toutes la tranche d'@IP qu'il lui a ete definie. Des qu'une correspondance est trouvee, il l'ajoute dans sa table et cesse de faire des requetes ARP sur cette @IP.

Pour le moment, les machines effectuent leur resolution d'@ de maniere conforme et habituelle (comme nous l'avons vu plus haut). Au bout d'un certain temps, le comportement du programme a change :

# tiens ! voici une petite requete ARP sur l'@IP 10.255.0.17 en provenance de 10.255.0.66

# chouette ! vu que je suis un petit coquin, je vais m'amuser un peu :)

# "oui oui, c'est moi la machine 10.255.0.17" (chuis un sacre menteur !)

# "heho, 10.255.0.17 habite a mon adresse MAC !" (j'insiste pour les durs d'oreille !)

# "si ya encore des tebes qui ont pas compris, 10.255.0.17 est disponible au 0:0:86:5d:31:8d"

# bon, la j'espere que 10.255.0.66 a bien ajoute mon adresse MAC dans son cache ARP et qu'il lui a bien fait correspondre l'@IP du povre innocent que je connais meme pas et dont je vais recuperer tous les paquets que 10.255.0.66 va lui adresser ! gnark gnark :)

Tiens donc ! L'ami evil_box s'amuse a faire croire aux gens qu'il est la machine 10.255.0.17 !

Ca c'est pas tres cool... En effet, la machine qui vient de se faire pieger va lui envoyer tous ses paquets en pensant bien les envoyer a la machine quelle cherchait (la 10.255.0.17). Ca va permettre a evil_box de lire tous les paquets qu'elle envoie... (ce genre de choses est très puissant sur un réseau switché, sur lequel on ne peut normalement pas sniffer le trafic réseau des autres machines). Enfin, pour le moment il apprendra pas grand chose, mais il est en train de se passer autre chose sur le reseau...

# bon, elle va bien me repondre si j'insiste un peu !

# bingo !!! je sais ou elle habite maintenant :)

Bon, la ca commence a chauffer, je le vois venir le petit chenapan ! Recapitulons :
* evil_box a fait croire a la machine .66 que l'@MAC de la machine .17 etait celle de sa carte rezo
* il connait l'@MAC de la machine .66 (c'est celle utilisee dans la requete ARP)
* il a recupere l'@MAC reelle (pas la sienne ! ;) de la machine .17

Bin maintenant, il va faire quoi a votre avis ???

Et bin il va etre bien sage et attendre que la machine .66 lui envoie des paquets (croyant les envoyer directement a la machine .17).

A ce niveau, j'ai pas recupere de logs concernant les paquets qu'il envoie, mais bon... le principe est simple : en gros, mathieu veut appeler thomas et compose votre numero. vous decrochez et appelez thomas sur une deuxieme ligne aussitot. vous prenez les combines et vous mettez l'ecouteur sur le micro d'un cote et pareil de l'autre de maniere a ce que lorsque thomas parle, le son qui sort de l'ecouteur arrive sur le micro qui va vers mathieu et lorsque mathieu parle, le son qui sort de l'ecouteur arrive sur le micro qui va vers thomas. et vous vous etes au milieu a ecouter tout ce qu'ils se disent d'indiscret sans qu'ils sachent qu'ils sont epies (bon, ok, si vous faites ca avec des telephones ca se verra tout de suite : le son sera pourri... mais c'est pour le principe !).

Pour ceux qui connaissent, c'est le principe de l'appel dans les familles de Difool sur Sky ya quelques temps... dire que Difool s'est inspire des techniques de Man In The Middle !!! J'aurais jamais cru ca ;)

La différence avec les téléphones, c'est que la machine qui attaque peut très bien modifier les données qui sont échangées dans la communication entre les deux machines, ce qui peut permettre par exemple d'insérer des commandes dans une session telnet (et gagner un accès à une des deux machines), de changer les fichiers téléchargés en ftp (pour y insérer une backdoor par exemple), de faire récupérer des faux mails parfaitement imités si la communication est du POP3...

Mais il manque encore une etape pour que ceci soit vraiment possible....

# je l'ai envoye a .17 en ne modifiant que l'@MAC source et en mettant la mienne a la place

# de celle de .66 !

pas de logs pour ces transferts (j'ai la flemme de faire un semblant de tcpdump pour tcp)

# bon, il me demande si il a bien le bon numero (@MAC)... on va le rassurer !

# "mais voui mon petit, je suis bien la pour toi !"

toujours pas de log pour les donnees tcp (ou autre...)

# et hop ! je recupere la reponse de .17 :)

# je l'envoie avec la meme technique que precedemment : je remplace l'@MAC source par la mienne

Bon, bin a ce stade des operations, il reste plus rien a faire pour .66 et .17 !

Ils sont completement empoisonnes et ne savent pas qu'ils sont en train de discuter par l'intermediaire de evil_box qui au passage doit certainement enregistrer tout ce qu'ils se disent dans un fichier qu'il pourra examiner plus tard... a moins qu'il ne sagisse d'une connexion telnet ou ssh, auquel cas evil_box est tout a fait capable d'inserer des commandes dans le flux des commandes de l'utilisateur qui vient de s'authentifier...

En réalité, evil_box ne s'est pas contente de tromper deux machines sur le reseau... il cherchait en fait a tromper (a empoisonner le cache ARP) de TOUTES les machines qui effectuaient des requetes ARP. Par exemple, les machines qui voulaient aller sur Internet devaient passer par le routeur 10.255.0.1. Pour pouvoir s'adresser au routeur en vue de lui transmettre des paquets a destination d'internet, elles faisaient bien evidemment des requetes ARP auxquelles evil_box repondait prestement et de maniere insistante (voir etape 1) afin de faire croire aux machines qui voulaient acceder a Internet que l'@MAC du routeur etait son @MAC a lui (evil_box).

Resultat des courses, il etait en mesure de recuperer tout le traffic oriente vers le web et tout le traffic destine aux autres reseaux du defcon. Le traffic local etait egalement recupere par le mecanisme que je viens de detailler juste au dessus.

Quand j'ai vu cela, je me suis dis "bin.... euh.... bin ya rien a faire ! j'ai juste a attendre !". Cette attaque de Man In the Middle est extrement puissante car elle est invisible (sauf pour les experts en securite que nous sommes ! ;), elle ne laisse pas de trace (si on n'utilise pas d'outils pour surveiller le traffic ARP et les changement d'@MAC des @IP du reseau (cf arpwatch)), elle peut s'arreter a tout moment (le systeme de timeout du cache ARP permettra aux machines de se resynchroniser automatiquement et sans intervention de evil_box sur la bonne @MAC) et elle permet de recuperer la TOTALITE du traffic destine a une (ou plusieures) machine !!!

Comme il est dit dans ADMwanasux.c : "$!@#$!@# and pHeAR ARP p0w4h ph0r 3v3r $!#@"

PS: sisi, ya une solution quand meme !

c'est de desactiver ARP (avec ifconfig) et de mettre la correspondance @IP / @MAC de maniere statique. La commande arp est la pour ca.

"arp -a" vous donne l'etat de la table de correspondance ARP, arp -s permet de fixer une @MAC a une @IP au coup par coup, mais le mieux est encore de mettre les correspondances @MAC @IP dans le fichier /etc/ethers (nom non officiel d'apres le man arp) qui sera utilise pour la commande "arp -f /etc/ethers".

Dans tous les cas, bon courage pour maintenir votre liste des @MAC a jour !!!