Search courses ▾
Semaine 0 TP : ICMP REDIRECT (3/5 points)
ENONCÉ DISPONIBLE EN TÉLÉCHARGEMENT
Semaine 1 :
Menaces liées OBJECTIF
aux réseaux
L’objectif de ce TP est de réaliser une attaque de type ICMP Redirect afin
de rerouter le trafic IP par une machine malveillante qui sera capable
S1L1 : Menaces
sur la couche
alors d’écouter les messages échangés. Un outil permettant de réaliser
liaison
cette attaque est fourni avec la machine virtuelle mais vous devez bien
due Nov 20, 2023 at en comprendre son mode de fonctionnement pour l’utiliser. En parallèle
23:55 UTC vous observerez comment l’attaque se traduit au niveau du réseau en
utilisant le logiciel wireshark.
S1L2 - Menaces
sur la couche
réseau Dans ce TP, nous considérons quatre machines :
due Nov 20, 2023 at
23:55 UTC machine client telnet, la victime
S1L2 - TP : ICMP machine serveur telnet
Redirect
TP due Nov 20, 2023 routeur servant de passerelle entre les deux réseaux
at 23:55 UTC
machine malveillante
S1L3 - Menaces
sur la couche
transport
due Nov 20, 2023 at
23:55 UTC
S1L3 - TP : TCP
Threats
TP due Nov 20, 2023
at 23:55 UTC
S1L4 - Menaces
sur la couche
application
due Nov 20, 2023 at
23:55 UTC
S1 - Pour en
Une fois l’attaque effectuée, nous verrons alors comment il est alors
savoir plus
possible de facilement récupérer les identifiants d’une connexion non
sécurisée de type telnet.
Semaine 2 :
Architectures LANCEMENT DU TP
de filtrage
Dans la machine virtuelle Labtainers, lancez le TP de la manière suivante
à partir du répertoire courant (~/labtainer/labtainer-student)
Semaine 3 :
VPN et
protocoles de 1. Lancez les conteneurs labtainers via la commande :
sécurité labtainer icmp-redirect Search courses ▾
Pour réaliser ce TP, nous devons désactiver certaines fonctionnalités de
Semaine 4 :
Doker en exécutant le script clean_ipt.sh dans le dossier
Synthèse des
~/labtainer/trunk/labs/icmp-redirect (rappel : mot de passe =
mécanismes
password123)
de sécurité
2. sudo ./clean_ipt.sh
Votre avis
nous intéresse Pour le reste du TP, les commandes préfixées par @attacker et
@victim sont à utiliser dans le terminal de la machine attaquante et
Pour terminer victime respectivement.
le MOOC...
Sur la machine de l’attaquant ouvrez wireshark en démarrant la capture
sur l’interface eth0 liée à l’adresse IP 192.168.1.2
@attacker : wireshark -i eth0 -k
FONCTIONNEMENT NORMAL
Sur la machine victime, connectez-vous au serveur telnet en tant que
l’utilisateur ubuntu avec le mot de passe ubuntu :
@victim : telnet 192.168.2.1
S1.L2.E.1. Pouvez-vous observer une session telnet sur wireshark
avec la machine attaquant ?
oui, j’observe bien la session telnet entre les adresses IP du client
et du serveur
oui, j’observe bien la session telnet mais initialisé à partir de
l’adresse de l’attaquant
non car le client se connecte sur le serveur en passant
seulement par la passerelle
non car wireshark n’est pas capable de décoder une session
telnet
EXPLICATION
Nous sommes encore dans le cas d’un fonctionnement normal. Il n’y
a donc aucune raison pour que la passerelle Search courses
redirige le trafic vers ▾
l’attaquant lorsque celui-ci est destiné au serveur
RÉALISATION DE L'ATTAQUE
Pour réaliser l’attaque ICMP redirect, nous allons utiliser l’outil ./redirect
installé dans le répertoire home de l’attaquant avec les droits root
(rappel du mot de passe : ubuntu)
Pour accéder aux options de l’outil, utilisez le paramètre -h et examinez
les options disponibles :
@attacker : ./redirect -h
Afin de réaliser l’attaque, vous allez lancer la commande suivante :
@attacker : sudo ./redirect -D -A 192.168.1.2 -G 192.168.1.2 -V 192.168.1.1
Depuis la victime, connectez-vous au serveur telnet:
@victim : telnet 192.168.2.1
S1.L2.E.2. Qu’observez-vous dans la capture réseau effectué sur la
machine attaquante ?
Un message ICMP redirect a bien été émis mais vers la mauvaise
destination
Un message ICMP redirect a bien été émis vers la bonne
destination et j’observe bien la session telnet
Un message ICMP redirect a bien été émis vers la bonne
destination mais il est impossible d’observer la session telnet car le
contenu du message est erroné pour réaliser l’attaque
Un message ICMP redirect a bien été émis mais un autre
message d’erreur ICMP est retourné
Search courses ▾
EXPLICATION
Le message ICMP redirect n’a pas comme adresse IP source la
passerelle. Le client a donc rejeté ce message car ne provenant pas
d’une de ses passerelles par défaut. C’est le comportement
recommandé pour éviter ce type d’attaque.
S1.L2.E.3. En regardant de plus près la capture vous devriez voir un
paquet ICMP echo request, pourquoi ?
Ce message n’a rien à voir avec l’attaque.
L’outil d’attaque s’assure de la disponibilité de l’hôte à attaquer.
Ce message oblige la victime à envoyer une reponse (echo reply)
à laquelle l’attaquant répond par une erreur de type ICMP redirect.
Ce message permet d’ouvrir une session ICMP dans laquelle on
peut ensuite envoyer le message ICMP redirect.
EXPLICATION
Ce message est obligatoire pour que le message ICMP redirect soit
envoyé en réponse à un message réel. Il sert donc en fait de
déclencheur au niveau de la victime pour générer ce message réel
(réponse de la victime)
Corrigez la commande pour réaliser l’attaque et vérifiez que celle-ci
fonctionne en capturant la session telnet avec wireshark, par exemple
en vérifiant que vous voyez bien le mot de passe utilisateur.
@attacker : sudo ./redirect -D -A 192.168.1.2 -G [param] -V 192.168.1.1 -T
S1.L2.E.4. Quelle valeur param doit-il prendre ?
Search courses ▾
192.168.1.1
192.168.1.2
192.168.1.10
192.168.2.10
192.168.2.1
EXPLICATION
Le paramètre -G permet de spécifier la passerelle à usurper de
façon à ce que le client accepte l’ICMP redirect.
S1.L2.E.5. Combien d’entêtes ICMP contient le message ICMP
redirect et quel est leur contenu ?
Aucune entête
Une seule entête correspondant à un message ICMP echo reply
en réponse au message ICMP echo request
Uns seule entête contenant les informations de redirection vers
la nouvelle passerelle (l’attaquant)
Deux entêtes ICMP, l’une correspondant au message de
redirection et l’autre au contenu du message echo request envoyé en
premier par l’attaquant
Deux entêtes ICMP, l’une correspondant au message de
redirection et l’autre au contenu du message echo reply envoyé par la
vicitme
EXPLICATION
Search courses ▾
Dans les systèmes standards suivants les recommandations, un
message ICMP redirect, qui est pour rappel un message d’erreur, ne
peut être accepté que s’il est effectivement déclenché par un
message initial. C’est pour cela que l’attaquant envoie un echo
request à la victime et répond à cette dernière avec un ICMP redirect
en déterminant le contenu du paquet IP du message ICMP echo
reply qu’il ne peut pas observer (puisqu’envoyé au serveur).
Sur la machine victime, vous pouvez vérifier l’état de la redirection avec
la commande :
@victim : ip route get 192.168.2.1
Vous remarquerez que la redirection est limitée dans le temps. Il est
donc nécessaire pour une attaque effective de maintenir la redirection
en envoyant régulièrement le message ICMP redirect. L’outil fourni
permet de le faire avec l’option -l.
La redirection permet d'intercepter uniquement le trafic entre le client et
le serveur et non dans le sens opposé. S'il le souhaite, l'attaquant peut
activer la fonctionnalité de NAT (Network Address Translation). Dans le
cas le plus simple, le NAT permet de réécrire l'adresse IP source de la
victime dans les paquets que cette dernière émet et qui sont maintenant
émis à travers la fausse passerelle. Les réponses seront alors envoyées
du serveur vers l'attaquant dont le NAT fera la réécriture inverse. A noter
que dans ce cas l'attaquant n'est plus tout à fait transparent puisque le
serveur lui envoie les réponses. Dans la majorité des cas, cela n'est pas
suspect puisque c'est le client qui sollicite la connexion.
Pour tester, vous pouvez utiliser la commande ci-dessous et observer
dans wireshark les réponses envoyées par le serveur.
@attacker : sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Désactivez la redirection avec la commande suivante
@victim : sudo ip route flush cache
Search courses ▾
Et observez le résultat :
@victim : ip route get 192.168.2.1
Pour terminer le lab, utilisez la commande stoplab icmp-redirect
You have used 1 of 1 submissions
About...
Help and Contact
Terms of use
Usage policy
Privacy policy
Terms and conditions
