Sécurité des réseaux sans fil

Laboratoire 802.11 sécurité MAC

A faire en équipes de deux personnes

Auteurs : Dylan Canton & Christian Zaccaria

Date : 23.03.2022

1. Deauthentication attack
2. Fake channel evil tween attack
3. SSID Flood attack
4. Probe Request Evil Twin Attack
5. Détection de clients et réseaux
6. Hidden SSID reveal
7. Livrables
8. Échéance

Pour cette partie pratique, vous devez être capable de :

• Détecter si un certain client WiFi se trouve à proximité
• Obtenir une liste des SSIDs annoncés par les clients WiFi présents

Vous allez devoir faire des recherches sur internet pour apprendre à utiliser Scapy et la suite aircrack pour vos manipulations. Il est fortement conseillé d'employer une distribution Kali (on ne pourra pas assurer le support avec d'autres distributions). Si vous utilisez une VM, il vous faudra une interface WiFi usb, disponible sur demande.

Des routers sans-fils sont aussi disponibles sur demande si vous en avez besoin (peut être utile pour l'exercices challenge 6).

ATTENTION : Pour vos manipulations, il pourrait être important de bien fixer le canal lors de vos captures et/ou vos injections (à vous de déterminer si ceci est nécessaire pour les manipulations suivantes ou pas). Une méthode pour fixer le canal a déjà été proposée dans un laboratoire précédent.

airodump-ng --channel 6 wlan0mon

Quelques pistes utiles avant de commencer :

• Si vous devez capturer et injecter du trafic, il faudra configurer votre interface 802.11 en mode monitor.
• Python a un mode interactif très utile pour le développement. Il suffit de l'invoquer avec la commande python. Ensuite, vous pouvez importer Scapy ou tout autre module nécessaire. En fait, vous pouvez même exécuter tout le script fourni en mode interactif !
• Scapy fonctionne aussi en mode interactif en invoquant la commande scapy.
• Dans le mode interactif, « nom de variable + » vous retourne le contenu de la variable.
• Pour visualiser en détail une trame avec Scapy en mode interactif, on utilise la fonction show(). Par exemple, si vous chargez votre trame dans une variable nommée beacon, vous pouvez visualiser tous ces champs et ses valeurs avec la commande beacon.show(). Utilisez cette commande pour connaître les champs disponibles et les formats de chaque champ.
• Vous pouvez normalement désactiver la randomisation d'adresses MAC de vos dispositifs. Cela peut être utile pour tester le bon fonctionnement de certains de vos scripts. Ce lien vous propose une manière de le faire pour iOS et Android.

Partie 1 - beacons, authenfication

1. Deauthentication attack

Une STA ou un AP peuvent envoyer une trame de déauthentification pour mettre fin à une connexion.

Les trames de déauthentification sont des trames de management, donc de type 0, avec un sous-type 12 (0x0c). Voici le format de la trame de déauthentification :

Le corps de la trame (Frame body) contient, entre autres, un champ de deux octets appelé "Reason Code". Le but de ce champ est d'informer la raison de la déauthentification. Voici toutes les valeurs possibles pour le Reason Code :

Code	Explication 802.11
0	Reserved
1	Unspecified reason
2	Previous authentication no longer valid
3	station is leaving (or has left) IBSS or ESS
4	Disassociated due to inactivity
5	Disassociated because AP is unable to handle all currently associated stations
6	Class 2 frame received from nonauthenticated station
7	Class 3 frame received from nonassociated station
8	Disassociated because sending station is leaving (or has left) BSS
9	Station requesting (re)association is not authenticated with responding station
10	Disassociated because the information in the Power Capability element is unacceptable
11	Disassociated because the information in the Supported Channels element is unacceptable
12	Reserved
13	Invalid information element, i.e., an information element defined in this standard for which the content does not meet the specifications in Clause 7
14	Message integrity code (MIC) failure
15	4-Way Handshake timeout
16	Group Key Handshake timeout
17	Information element in 4-Way Handshake different from (Re)Association Request/Probe Response/Beacon frame
18	Invalid group cipher
19	Invalid pairwise cipher
20	Invalid AKMP
21	Unsupported RSN information element version
22	Invalid RSN information element capabilities
23	IEEE 802.1X authentication failed
24	Cipher suite rejected because of the security policy
25-31	Reserved
32	Disassociated for unspecified, QoS-related reason
33	Disassociated because QAP lacks sufficient bandwidth for this QSTA
34	Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions
35	Disassociated because QSTA is transmitting outside the limits of its TXOPs
36	Requested from peer QSTA as the QSTA is leaving the QBSS (or resetting)
37	Requested from peer QSTA as it does not want to use the mechanism
38	Requested from peer QSTA as the QSTA received frames using the mechanism for which a setup is required
39	Requested from peer QSTA due to timeout
40	Peer QSTA does not support the requested cipher suite
46-65535	Reserved

a) Utiliser la fonction de déauthentification de la suite aircrack, capturer les échanges et identifier le Reason code et son interpretation.

Question : quel code est utilisé par aircrack pour déauthentifier un client 802.11. Quelle est son interpretation ?

Le code 7 est utilisé, ce code indique le message Class 3 frame received from nonassociated station, ce qui signifie que le client a essayé de transférer des données avant qu'il ne soit associé.

On peut constater sur Wireshark le résultat suivant (les adresses MAC ne sont pas similaires car la capture est faite dans un second temps) :

Question : A l'aide d'un filtre d'affichage, essayer de trouver d'autres trames de déauthentification dans votre capture. Avez-vous en trouvé d'autres ? Si oui, quel code contient-elle et quelle est son interprétation ?

wlan.fixed.reason_code != 0x0007

En utilisant le filtre ci-dessus, nous avons trouvé d'autres trames de déauthentification avec un reason code tel que le 6 : Class 2 frame received from nonauthenticated station

b) Développer un script en Python/Scapy capable de générer et envoyer des trames de déauthentification. Le script donne le choix entre des Reason codes différents (liste ci-après) et doit pouvoir déduire si le message doit être envoyé à la STA ou à l'AP :

• 1 - Unspecified
• 4 - Disassociated due to inactivity
• 5 - Disassociated because AP is unable to handle all currently associated stations
• 8 - Deauthenticated because sending STA is leaving BSS

Question : quels codes/raisons justifient l'envoie de la trame à la STA cible et pourquoi ?

Code 1 : Ne spécifie pas la raison de l'envoi à la STA

Code 4 : Indique que la STA est inactive depuis un certain temps et qu'il faut donc la déconnecter

Code 5 : L'AP est surchargé et incapable de répondre aux tentatives de connexions supplémentaires

Question : quels codes/raisons justifient l'envoie de la trame à l'AP et pourquoi ?

Le Code 1 car il ne spécifie pas la raison de l'envoi à l'AP.

Le Code 8 car il indique à l'AP que la station quitte son BSS.

Question : Comment essayer de déauthentifier toutes les STA ?

Si l'on utilise l'adresse MAC client FF:FF:FF:FF:FF:FF permettant de cibler toute les STA connectées à l'AP.

Question : Quelle est la différence entre le code 3 et le code 8 de la liste ?

Le Code 3 défini que le client est désauthentifié et quitte donc l'ESS. Or, avec le Code 8 le client va être désassocié du BSS par un AP.

Question : Expliquer l'effet de cette attaque sur la cible

Va déconnecter l'hôte cible de l'AP auquel il était connecté. Il ne sera pas possible de pouvoir accéder aux différentes ressources sur internet et il sera obligé de se reconnecter.

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

sudo python3 script1_deauth.py -n <NB_DE_PAQUETS_A_ENVOYER> -a <BSSID_AP> -c <CLIENT_MAC> -i <INTERFACE_SEND_ATTACK> -r <REASON_CODE>

EXAMPLE:
sudo python3 script1_deauth.py -n 300 -a B8:D9:4D:80:8C:1C -c 20:79:18:B2:20:E6 -i wlan0 -r 8

Trame Wireshark :

2. Fake channel evil tween attack

a) Développer un script en Python/Scapy avec les fonctionnalités suivantes :

• Dresser une liste des SSID disponibles à proximité
• Présenter à l'utilisateur la liste, avec les numéros de canaux et les puissances
• Permettre à l'utilisateur de choisir le réseau à attaquer
• Générer un beacon concurrent annonçant un réseau sur un canal différent se trouvant à 6 canaux de séparation du réseau original

Question : Expliquer l'effet de cette attaque sur la cible

La cible peut essayer de s’authentifier auprès de l’AP qui a été attaqué : la cible tentera de se connecter au "faux" AP, permettant ainsi de pouvoir récupérer ses credentials.

Fonctionnement du script

Lancement du script sans paramètres supplémentaires.

Il faut ensuite définir l'interface à écouter ainsi que le numéro (défini dans une liste) du réseau que l'on souhaite changer de canal

Nos résultats ont été confirmé à l'aide du capture Wireshark. On a alors essayé de changer le canal du réseau Krikri-AP.

Lors de la première capture, on a vu que le canal était bien le 1 :

On a ensuite executé le script, et l'on a bien constaté que le canal à changé bien sur le 7 :

3. SSID flood attack

Développer un script en Python/Scapy capable d'inonder la salle avec des SSID dont le nom correspond à une liste contenue dans un fichier text fournit par un utilisateur. Si l'utilisateur ne possède pas une liste, il peut spécifier le nombre d'AP à générer. Dans ce cas, les SSID seront générés de manière aléatoire.

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

script3_ssidflood.py -i <INTERFACE_NAME> -f <TXT_FILENAME> ou <INT_NUMBER>

Exemple :
script3_ssidflood.py -i wlan0 -f names.txt
ou
script3_ssidflood.py -i wlan0 -f 5

Lors qu'on lance le script, il est possible de visualiser les noms des SSID qu'il a crée :

Partie 2 - probes

Introduction

L’une des informations de plus intéressantes et utiles que l’on peut obtenir à partir d’un client sans fils de manière entièrement passive (et en clair) se trouve dans la trame Probe Request :

Dans ce type de trame, utilisée par les clients pour la recherche active de réseaux, on peut retrouver :

• L’adresse physique (MAC) du client (sauf pour dispositifs iOS 8 ou plus récents et des versions plus récentes d'Android).
  • Utilisant l’adresse physique, on peut faire une hypothèse sur le constructeur du dispositif sans fils utilisé par la cible.
  • Elle peut aussi être utilisée pour identifier la présence de ce même dispositif à des différents endroits géographiques où l’on fait des captures, même si le client ne se connecte pas à un réseau sans fils.
• Des noms de réseaux (SSID) recherchés par le client.
  • Un Probe Request peut être utilisé pour « tracer » les pas d’un client. Si une trame Probe Request annonce le nom du réseau d’un hôtel en particulier, par exemple, ceci est une bonne indication que le client s’est déjà connecté au dit réseau.
  • Un Probe Request peut être utilisé pour proposer un réseau « evil twin » à la cible.

Il peut être utile, pour des raisons entièrement légitimes et justifiables, de détecter si certains utilisateurs se trouvent dans les parages. Pensez, par exemple, au cas d'un incendie dans un bâtiment. On pourrait dresser une liste des dispositifs et la contraster avec les personnes qui ont déjà quitté le lieu.

A des fins plus discutables du point de vue éthique, la détection de client s'utilise également pour la recherche de marketing. Aux Etats Unis, par exemple, on "sniff" dans les couloirs de centres commerciaux pour détecter quelles vitrines attirent plus de visiteurs, et quelle marque de téléphone ils utilisent. Ce service, interconnecté en réseau, peut aussi déterminer si un client visite plusieurs centres commerciaux un même jour ou sur un certain intervalle de temps.

4. Probe Request Evil Twin Attack

Nous allons nous intéresser dans cet exercice à la création d'un evil twin pour viser une cible que l'on découvre dynamiquement utilisant des probes.

Développer un script en Python/Scapy capable de detecter une STA cherchant un SSID particulier - proposer un evil twin si le SSID est trouvé (i.e. McDonalds, Starbucks, etc.).

Pour la détection du SSID, vous devez utiliser Scapy. Pour proposer un evil twin, vous pouvez très probablement réutiliser du code des exercices précédents ou vous servir d'un outil existant.

Question : comment ça se fait que ces trames puissent être lues par tout le monde ? Ne serait-il pas plus judicieux de les chiffrer ?

Les trames Prob Request doivent être en clair car elles sont utilisées par les clients pour la recherche active des réseaux.

Si les trames étaient chiffrées, il ne serait pas garantis que les APs interceptant ces trames puissent en déchiffrer le contenu et donc fournir une réponse avec une Prob Response.

Question : pourquoi les dispositifs iOS et Android récents ne peuvent-ils plus être tracés avec cette méthode ?

Car les dispositifs récents utilisent désormais des adresses MAC aléatoires à la place d'adresses MAC fixes. Ce mécanisme permet de rendre plus difficile la traque de ces dispositifs puisqu'ils ne possèdent plus une adresse MAC fixe.

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

script4_evilTwin.py -i <INTERFACE> -s <SSID>

Exemple :
script4_evilTwin.py -i wlan0 -s Pilon

Lorsque le script est lancé, il va essayer pendant 30 secondes de trouver l'SSID que on lui fourni en paramètre. Si il trouve le SSID, il va envoyer alors des paquets à l'infini, simulant ainsi l'existence d'un AP :

On peut voir le résultat suivant sur Wireshark lorsqu'on le SSID est trouvé :

5. Détection de clients et réseaux

a) Développer un script en Python/Scapy capable de lister toutes les STA qui cherchent activement un SSID donné

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

script5_listSta.py -i <INTERFACE> -s <SSID>

Exemple :
script5_listSta.py -i wlan0 -s Krikri-AP

Lors qu'on lance le script, il est possible de visualiser les MAC des STA qui ont effectué une probe request pour l'SSID donné :

A l'aide de Wireshark, on a pu bien confirmé le résultat obtenu

b) Développer un script en Python/Scapy capable de générer une liste d'AP visibles dans la salle et de STA détectés et déterminer quelle STA est associée à quel AP. Par exemple :

STAs                                       APs

B8:17:C2:EB:8F:8F             08:EC:F5:28:1A:EF

9C:F3:87:34:3C:CB             00:6B:F1:50:48:3A

00:0E:35:C8:B8:66             08:EC:F5:28:1A:EF

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

script5_linkApSta.py -i <INTERFACE> 

Exemple :
script5_linkApSta.py -i wlan0

Lors qu'on lance le script, il est possible de visualiser les MAC des STA et des AP qui sont reliés entre eux :

On peut alors confirmer le résultat en exectuant un airodump-ng sur la même interface afin de visualiser le BSSID correspondant à la STA :

6. Hidden SSID reveal (exercices challenge optionnel - donne droit à un bonus)

Développer un script en Python/Scapy capable de reveler le SSID correspondant à un réseau configuré comme étant "invisible".

Question : expliquer en quelques mots la solution que vous avez trouvée pour ce problème ?

On a procédé de la manière suivante pour trouver une solution :

• Chaque paquet "Beacon" est analysé afin de pouvoir extraire les BSSID des paquets sans SSID
• Au même temps, chaque paquet Probe Response est analysé afin de récupérer les SSID dont le BSSID correspond au BSSID des paquets "Beacon"

Fonctionnement du script

Il est nécessaire de lancer la commande suivante avec les paramètres suivant :

script6_hiddenSsid.py -i <INTERFACE> 

Exemple :
script6_hiddenSsid.py -i wlan0

Voici un petit scénario afin de prouver le bon fonctionnement :

On a en premier lancé le script en ayant un AP avec un SSID caché. On constate bien qu'il trouve le BSSID mais qu'il n'arrive pas trouver le SSID (en rouge dans la capture)

Ensuite, on relance le script et pendant l'analyse de ce dernier, on s'est connecté sur l'AP "caché". Le résultat est que l'on va trouvé le SSID car un échange de Probe Request/Response a eu lieu (encadré vert).

Livrables

Un fork du repo original . Puis, un Pull Request contenant :

• Script de Deauthentication de clients 802.11 abondamment commenté/documenté

• Script fake chanel abondamment commenté/documenté

• Script SSID flood abondamment commenté/documenté

• Script evil twin abondamment commenté/documenté

• Scripts détection STA et AP abondamment commenté/documenté

• Script SSID reveal abondamment commenté/documenté

• Captures d'écran du fonctionnement de chaque script

• Réponses aux éventuelles questions posées dans la donnée. Vous répondez aux questions dans votre README.md ou dans un pdf séparé

• Envoyer le hash du commit et votre username GitHub par email au professeur et à l'assistant

Échéance

Le 31 mars 2022 à 23h59