Skip to main content

Fiche TP - Kali 02 - intrusion réseau

I. Introduction

Disclaimer : Merci de lire les notes suivantes avant d'aller plus loin dans ces TP.

  • Il est essentiel d'avoir pris connaissance et signé le contrat remis par le moniteur chargé des cours en cybersécurité.
  • Ces TP ont pour vocations à être utilisés dans les environnement de tests prévus à cet effet.
  • Pour rappel, toute utilisation des compétences évoqués plus bas à des fins malveillantes sont sévèrement punies par la loi.

1.1 Contexte

logo.pnglogo.png

 

 

 

Suite à son premier audit de sécurité, la société bancaire VulnBank à décidé d'auditer de nouveau son service, mais en se penchant plus cette fois-ci sur l'aspect réseau.

 

Elle vous a donc missionné pour tester plusieurs scénarii d'intrusion réseau et notamment en terme d'interception de données.

1.2 Objectifs

Déroulé d'une attaque : Processus de défense ( PICERL )
drawing-1-1772624600.pngdrawing-1-1772624600.png
drawing-1-1772115528.pngdrawing-1-1772115528.png

L'objectif de la team RED va être ici de dérouler les différents scenarii des attaques et d'en rapporter les résultats. Le but ultime est d'essayer de cibler les clients en interceptant des échanges ou des informations et de gagner ainsi l'accès à l'espace d'un client afin de réaliser un virement sur un compte fictif.

L'objectif de la team BLUE va être de suivre les agissements de la RED team afin d'analyser les indicateurs clés des symptômes des attaques et en essayant de trouver à posteriori des mesures pour contrer ce type d'attaques.


II. Préparation du TP

RED BLUE
  • Installer une machine Kali standard
  • Installer un serveur Debian et le préparer avec le script fourni.


III. Scenario 1 : Récupération d'identifiants par email

Pour la RED team

Objectif : Extraire les informations nécessaire à une usurpation d'identité depuis un mail intercepté.

 

L'équipe RED a eu accès à un fichier EML d'un email intercepté par un sniffeur.

image.pngimage.png

 

Dans ce mail, il y a en pièce jointe un fichier ZIP protégé par mot de passe.

Le mail contient déjà toutes les information nécessaires pour deviner le mot de passe.

 

Pour l'information manquante, 3 approches :

 

Pour la BLUE team

 

Scenario 2 : Man in the middle, MAC Spoofing

Pour la RED team

Objectif : Intercepter le flux de donnée afin de récupérer les identifiants.

 

Dans un premier temps, l'équipe RED va scaner le réseau pour déterminer l'ip de la victime dont nous allons intercepter les flux.

Ainsi que l'ip du serveur web duquel nous allons usurper l'identité sur le réseau ou le cas échéant du routeur.

image.pngimage.png

 

Ici : la victime est 192.168.41.231 et celle du serveur web à usurper est la 192.168.41.228.

 

Pour lancer l'attaque, la première action est d'activer l'IP forwarding.

Cela permettra de rediriger les requêtes après l'interception sur le serveur légitime afin d'être transparent vis à vis de la cible.

sudo sysctl -w net.ipv4.ip_forward=1

 

Puis lancer l'usurpation de la MAC address.

Info : Cette attaque cible la couche 2 du modèle OSI. Elle a pour but de spammer la cible de réponses ARP forgées pour empoisonner sa table ARP afin d'usurper l'identité d'une autre machine sur le réseau.

arpspoof -i <NomInterfaceRéseau> -t <ipVictime> <ipServeur>

image.pngimage.png


Il est temps de lancer une capture wireshark. Utiliser le filtre

ip.dst == <ipDuServerWeb> && tcp.port == 80

Attendre que la victime tente une connexion.

 

Retrouver sur wireshark la requête POST.

image.pngimage.png


Les informations apparaissent dans la requête, il n'y a plus qu'a tenter une connexion.

image.pngimage.png

 

Livrables attendus :

  • Preuves d'accès (captures d'écran de la page web).
  • Méthodes utilisées, captures d'écran (wireshark, etc...).

 

Pour la BLUE team

Objectif : Constater l'empoisonnement de cache ARP de la machine.

 

De son côté, l'équipe BLUE va vérifier initialement la table MAC de sa machine :

arp

image.pngimage.png

 

Puis, suite aux actions de RED, relancer cette vérification

image.pngimage.png

 

l'adresse MAC correspondant à l'ip de la machine à changé.

 

Au signal de l'équipe RED, l'équipe BLUE va se connecter sur le site web de la banque.

image.pngimage.png


 

L'idée pour l'équipe BLUE est d'arriver sur les pistes de réflexions suivantes :

  • Comment se prémunir d'une attaque par empoisonnement ARP ?
  • En quoi le protocole http est-il à proscrire ?
  • Si non possibilité de https, quelle aurait été la solution 

 

Mettre en place des politiques de filtrage MAC pour n'autoriser que les PC connus sur le réseau.

Mettre en place des sécurité sur les équipements réseaux.

Préférer le https au http car le trafic est chiffré. Faire également attention aux certificats.

Procéder au hash du mot de passe côté client en amont de la requête POST.


Phase intermédiaire : Passer les serveurs web en https.

Scenario 3 : Man in the Middle, DNS spoofing & fake page

Pour la RED team

 

Pour la BLUE team

 

Conclusion

A la fin de cet exercice, les deux équipes ont pu constater l'importance de la bonne sécurisation du réseau et l’intérêt d'une politique de zero trust.

Aujourd'hui, l'utilisation de protocoles sécurisés en lieu et place des anciens protocoles est primordiale pour éviter toute interception, falsification ou usurpation du trafic réseau.

Les failles exploitées ici sont avant tout des failles systémiques dans le fonctionnement des protocoles non sécurisés.

    Back to top