[Ettercap – Partie 1] Introduction et rappels

Par Moussa Diallo, secuobs.com
Le 04/10/2006


Résumé : Ettercap est un outil développé par Alberto Ornaghi (ALoR) et Marco Valleri (NaGA). La dernière version stable est la version 0.7.3. Il est décrit par ses auteurs comme un outil permettant de sniffer les réseaux switchés. De nombreuses évolutions l'ont doté de fonctions avancées (MitM, Os Fingerprinting).



Ettercap est un outil développé par Alberto Ornaghi (ALoR) et Marco Valleri (NaGA). La dernière version stable est la version 0.7.3.

Ettercap est décrit par ses auteurs comme un outil permettant de sniffer les réseaux switchés (donc par extension les réseaux locaux organisés autour d'un HUB). De nombreuses évolutions au cours du développement ont doté Ettercap de fonctions avancées permettant la mise en place d’attaques de type "Man in the middle" ainsi que la prise d'empreinte d'Os passive et active.

Une fois qu'Ettercap s'est inséré au milieu d'une connexion, il capture et examine toutes les communications entre les hôtes victimes et par conséquent peut tirer avantage de la situation pour accomplir les tâches suivantes :

- Injection de commandes : insérer des commandes dans la connexion en cours afin d'émuler des requêtes envoyées par le client ou des réponses du serveur,

- Filtrage de paquet : filtrer automatiquement le contenu de paquets TCP ou UDP en cherchant des chaînes de caractères ASCII ou hexadécimales et les remplacer par un contenu offensif (oupa :),

- Récupération de mots de passe : un module (aussi appelé dissecteur) est capable de reconnaître et d'extraire les informations utiles d'un grand nombre de protocoles tels que TELNET, FTP, POP3, SSH v1, X11, VNC, LDAP, SNMP, NFS, IRC, MySQL,

- Support de SSHv1: capturer les logins/mots de passe et les données d'une connexion SSH v1,

- Support du protocole HTTPS : insertion dans une session HTTPS en faisant accepter à la victime un faux certificat,

- Support du protocole PPTP : mise en place d'attaques Man In the Middle contre un tunnel PPTP.

Ettercap inclut également une série d'outils, très utile, de reconnaissance réseau :

- Os fingerprinting (prise d'empreintes de système d'exploitation afin de les identifier),
- Scan passif,
- Sniffer IP / MAC.

Avant d’entrer dans les détails du fonctionnement et de l’utilisation d’Ettercap nous allons faire quelques rappels sur les concepts de base nécessaires à la compréhension et à une utilisation efficace d'Ettercap.


Le protocole ARP

Le protocole ARP est utilisé au sein d'un réseau local pour faire la correspondance entre les adresses physiques MAC et les adresses logiques IP. Le protocole ARP interroge les machines du réseau pour connaître leurs adresses physiques, puis crée une table de correspondance entre les adresses logiques et les adresses physiques dans une mémoire cache.

Sur un réseau connecté autour d'un HUB, les trames Ethernet sont envoyées à tous les ports (Broadcast) sans se soucier de l'adresse MAC de destination, ce qui rend l'écoute passive triviale. Il suffit juste d'une carte configurée en mode "promiscious" pour intercepter le trafic.

Sur un réseau organisé autour de Switchs, les trames ne sont plus automatiquement envoyées à tous les ports, ce qui permet notamment de réduire les congestions sur le réseau. Un Switch étant capable d'apprendre quelles sont les adresses MAC connectées à ses ports il peut stocker ces informations dans une table, que l’on appelle table de transmission. Pour cela, il va extraire les adresses MAC sources des trames Ethernet, noter le port sur lequel la trame est arrivée et ajouter l'association dans sa table.

Lorsqu'une trame de niveau deux arrive, un Switch examine l'adresse de destination et consulte sa table de transmission. S'il ne connait pas encore le port correspondant, à cette adresse, il va envoyer la trame à tous les ports. A contrario si la table de transmission contient déjà un port correspondant à une adresse MAC la trame sera envoyée uniquement à ce port.

Ce mécanisme rend plus difficile l’écoute passive sur un réseau switché. Si l'on place un sniffer sur un port d’un Switch, il récupérera uniquement le trafic à destination de ce port ou le trafic broadcasté.

Lorsqu'un hôte encapsule un paquet IP dans une trame Ethernet, il connait l'adresse MAC source (normalement la sienne ;), mais il ne connait peut être pas l'adresse MAC de destination. Cependant il connait l'adresse IP de destination contenue dans l'en-tête IP du paquet.

Il lui faut donc un moyen de récupérer l'adresse MAC correspondant à cette adresse IP. Pour cela, il utilise le protocole ARP :

- une requête ARP est envoyée sur l'adresse Ethernet de broadcast en posant la question "Qui à l'adresse MAC aa:bb:cc:dd:ee:ff correspondant à l'adresse IP w.x.y.z ?",

- une réponse ARP est envoyée en unicast à une requête ARP, du genre "J'ai cette adresse IP et mon adresse MAC est aa:bb:cc:dd:ee:ff".

Chaque hôte sur le réseau maintient sa propre table de correspondance adresse IP, adresse MAC que l'on appelle cache ARP. Si le système doit envoyer un paquet à une adresse IP, il consulte son cache ARP pour voir s’il connait déjà l'adresse MAC correspondant à l'adresse IP de destination. Si c'est le cas, il utilise l'adresse MAC pour adresser la trame.





Si l'adresse de destination n'est pas dans le cache, l'hôte envoie une requête ARP à toutes les machines du réseau. Comme nous l'avons vu, si une machine ayant reçue la requête ARP reconnait son adresse IP, elle renvoie une réponse ARP contenant son adresse IP et son adresse MAC. L'hôte source utilisera alors cette réponse ARP pour mettre à jour son cache ARP et l'utiliser comme future référence.


18:08:48.299911 arp who-has crashtest tell 192.168.1.27
0x0000: 0001 0800 0604 0001 000b 6a50 3346 c0a8
0x0010: 011b 0000 0000 0000 c0a8 01c8 ffff ffff
0x0020: ffff ffff ffff ffff ffff ffff ffff
18:08:48.433620 arp reply crashtest is-at 00:12:3f:f9:2b:a0 (oui Unknown)
0x0000: 0001 0800 0604 0002 0012 3ff9 2ba0 c0a8
0x0010: 01c8 000b 6a50 3346 c0a8 011b



Il est important de noter que le cache ARP expire après un certain temps au cours duquel il est effacé.


ARP cache poisoining

En manipulant le cache ARP de potentielles victimes, un attaquant peut modifier la direction du trafic entre deux hôtes (ou plus), afin de rediriger le flux vers une machine contrôlée par un attaquant

Une attaque de ce type consiste à envoyer une requête ARP (« arp who-has ») à une machine A. Ce paquet spécialement forgé contiendra, en adresse IP source, l'adresse IP de la machine B dont l'attaquant veut recevoir le trafic et en adresse MAC source l'adresse MAC de la carte réseau de la machine C de l'attaquant.

La machine A va ainsi créer une entrée dans son cache ARP associant l'adresse MAC de C à l'adresse IP de la machine de B. Lorsque A va communiquer avec B au niveau IP, c'est le poste de l'attaquant qui recevra les trames de A puisque son adresse MAC est associée à l'adresse IP de B.

Nous pouvons voir sur la figure suivante la corruption du cache de la machine 192.168.1.27. En effet l'adresse MAC de la machine 192.168.1.254 n'est pas la même entre les deux inspections de cache.





A ce stade plusieurs choix d'attaques se présentent dont notamment le Déni de Service (DoS) et l'écoute de communication (Sniffing). Cette dernière est plutôt intéressante afin de récupérer des données confidentielles vu la position d'"homme du milieu" (Man in the Middle) de l'attaquant.


Man In the Middle ?

Les attaques Man In The Middle (MitM - Homme du milieu) sont une classe d'attaques dans laquelle l'attaquant se situe entre deux parties communicantes, ce qui est le cas après une attaque de cache poisoning couronnée de succès.

Cette position avantageuse permet à l'attaquant de capturer (attaque visant la confidentialité), insérer (attaque visant l'intégrité) ou modifier (attaque visant la confidentialité et l'intégrité) les communications chiffrées (oupa :) entre les deux entités et ceux quel que soit le niveau de chiffrement utilisé.





D'un point de vue pratique, l'attaquant « écoute » (sniffe) les paquets du réseau, les modifient et les réinjectent au destinataire initiale.

La configuration de réseau suivante a été utilisée pour réaliser les exemples suivants :





Autres ressources dans ce dossier

[Ettercap – Partie 2] Ettercap par l'exemple - Man In the Middle et SSL sniffing - lien

[Ettercap – Partie 3] Ettercap par l'exemple - Affaiblissement de protocoles et attaque par injection - lien

[Ettercap – Partie 4] Contre mesure, conclusion et webographie - lien