Contribuez à SecuObs en envoyant des bitcoins ou des dogecoins.
Nouveaux articles (fr): 1pwnthhW21zdnQ5WucjmnF3pk9puT5fDF
Amélioration du site: 1hckU85orcGCm8A9hk67391LCy4ECGJca

Contribute to SecuObs by sending bitcoins or dogecoins.



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

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


Résumé : Présentation des différentes interfaces d'utilisation de Ettercap. Description des possibilités d'attaques ARP Poisoning et Man in The Middle avec Ettercap, ainsi que leur intégration dans les attaques de type SSL sniffing.



L'interface

Ettercap permet d'utiliser trois interfaces distinctes. Une interface graphique en GTK, une interface en mode texte qui utilise ncurses et la dernière en mode texte, ligne de commande. Nous allons principalement nous intéresser à cette dernière.

La page d'aide peut être affichée avec la commande classique --help, ce qui permettra d'afficher les options de la ligne de commande les plus courantes.


$ ettercap --help


Etre au milieu ...

Nous allons tout d'abord procéder à l'attaque de base afin de se positionner en "homme du milieu". Pour cela nous allons attaquer la machine de la victime afin de corrompre son cache ARP (ARP poisoning) et de se retrouver en position favorable pour la suite des opérations.


Ettercap -T -M arp /192.168.1.27/ /192.168.1.254/


On lance Ettercap en mode texte (option -T), on active l'attaque de MItM (option -M) en utilisant la technique de la corruption de cache ARP (option arp) entre les hôtes 192.168.1.27 et 192.168.1.254.

Une fois que l'attaque a réussi, l'attaquant est en position d'homme du milieu et de ce fait en position pour intercepter les communications. Toutes les requêtes en provenance de l'hôte 192.168.1.27 à destination de l'hôte 192.168.1.254 vont transiter par la machine de l'attaquant 192.168.1.200.

Dans notre architecture l'hôte 192.168.1.254 est le routeur de sortie vers internet. Si l'on veut être capable de sniffer les connexions distantes transitant par la passerelle, entre l'hôte victime 192.168.1.27 et l'Internet, il est nécessaire d'ajouter le paramètre "remote" à l'option "arp" dans la ligne de commande.


ettercap -T -M arp:remote /192.168.1.27/ /192.168.1.254/


Il sera alors aisé de récupérer un certain nombre de données sensibles (mots de passe ?!) entre la victime et le reste du monde.


ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Listening on eth0... (Ethernet)

eth0 -> 00:12:3F:F9:2B:A0 192.168.1.200 255.255.255.0

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Privileges dropped to UID 65534 GID 65534...

28 plugins
39 protocol dissectors
53 ports monitored
7587 mac vendor fingerprint
1698 tcp OS fingerprint
2183 known services

Randomizing 255 hosts for scanning...
Scanning the whole netmask for 255 hosts...
* |===========================>| 100.00 %

5 hosts added to the hosts list...

ARP poisoning victims:
GROUP 1: 192.168.1.27 00:0B:6A:50:33:46

GROUP 2: ANY (all the hosts in the list)
Starting Unified sniffing...


Text only Interface activated...
Hit 'h' for inline help

HTTP: 193.34.36.37 -> USER: Administrateur PASS: password_secret INFO: monsiteweb.com/admin/



Lors d'une identification via un formulaire il est possible d'indiquer dans le fichier etter.fields (/usr/share/ettercap) au dissecteur HTTP d'Ettercap les champs qui correspondent au login et au mot de passe afin que ce dernier puisse s'en servir.

Une autre méthode proposée par Ettercap, afin de mettre en place une attaque de MitM, est l’utilisation de l’ICMP redirect. En envoyant des paquets "ICMP redirect" un attaquant peut demander à un équipement réseau à ce que tous les paquets émis lui soient transmis (il se fait passer pour le routeur par défaut).

La syntaxe est sensiblement identique à l'attaque précédente. Il faut simplement modifier le type d'attaque qui n'est plus ARP mais ICMP.


SSL sniffing

Ettercap permet également des attaques sur des protocoles chiffrés comme HTTPS.

En temps normal lorsqu'un client se connecte à un serveur Web utilisant le protocole HTTPS, ils échangent leurs données via un tunnel SSL dans lequel les données HTTP sont encapsulées. Si un attaquant était amené à intercepter les données il ne pourrait pas les déchiffrer.

Grossièrement nous pourrions résumer la connexion HTTPS comme suit :

- le client établit une connexion vers un serveur HTTPS,
- le serveur lui présente son certificat
- le client vérifie la validité du certificat (dans l’idéal …),
- si le certificat est valide le client crée une clé de session qu'il va chiffrer avec le certificat du serveur.
- le serveur déchiffre la clé de session
- les deux parties utilisent la clé de session commune pour chiffrer et échanger leurs données.

La sécurité des échanges va donc dépendre du certificat du serveur et surtout de la confiance que va lui porter le client. La validité d'un certificat repose sur trois points :

- avoir été émis par une autorité de confiance.
- être en cours de validité
- correspondre au nom de domaine du site

Si ces conditions ne sont pas respectées le client verra apparaître une fenêtre (pop-up) l'informant que le certificat n'est pas valide pour une (ou plusieurs) des trois raisons précédentes. Si le certificat est valide, la connexion se fait de manière transparente et aucun pop-up n'apparaît.

Nous allons voir comment exploiter avec Ettercap la confiance de l'utilisateur afin de récupérer le trafic émis dans le tunnel chiffré.

L'attaque repose sur l'acceptation par la victime d'un certificat invalide. L'attaquant se place en homme du milieu de la même façon que précédemment (par exemple en effectuant une attaque d'ARP cache poisoning entre la victime et la passerelle internet) puis va intercepter la requête HTTPS de la victime vers le serveur et lui présenter un faux certificat (de préférence ressemblant le plus possible au vrai).

Si le client accepte le certificat, Ettercap va établir un tunnel SSL entre le client et l'attaquant. Il va ensuite établir un second tunnel SSL vers le serveur légitime. Cette position permet donc à l'attaquant de chiffrer/déchiffrer les données des deux cotés et ainsi de récupérer les données du client avant de les transmettre au serveur de destination.

Ettercap va donc échanger le vrai certificat avec le sien. Le faux certificat est créé à la volée et tous les champs sont remplis en fonction de ceux du certificat original, présenté par le serveur. Seul l'émetteur du certificat est modifié et il est signé avec la clé privée de Ettercap, que l'on peut trouver (suivant les distributions) dans le fichier suivant : /usr/share/ettercap/etter.ssl.crt

On se place en homme du milieu :


ettercap -T -M arp:remote /192.168.1.27/ /192.168.1.254/


Lorsque la victime fera une requête vers un site HTTPS, Ettercap présentera le faux certificat et après acceptation du certificat, par l'utilisateur, toutes les informations transmises par la victime pourront être déchiffrées.


HTTP : 64.233.183.99:443
-> USER: too_secure PASS: aZ3bnG*/if INFO:
//www.google.com/accounts/ServiceLogin?s
service=mail&passive=true&rm=false&continue
=//mail.google.com/mail/?ui=html&zy=ls
<mpl=yj_blanco



Autres ressources dans ce dossier

[Ettercap – Partie 1] Introduction et rappels - 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