Hostapd-wpe : Attaquer un réseau Wi-Fi d’entreprise !

To the non-french speaker, note that you can translate the articles using the Google Trad widget situated at the bottom of all pages.


Jusqu’à présent je ne vous avais parlé que d’attaques Wi-Fi relatives au réseau domestique. C’est à dire les réseaux Wi-Fi utilisant WEP ou WPA/WPA2-PSK. Ces protocoles reposent sur un secret commun : la clé WEP ou WPA/2.

En entreprise on utilise d’autres moyens d’authentification : des tokens, des certificats ou encore des comptes Active Directory. Ces moyens sont privilégiés en entreprise car ils permettent à chaque utilisateur d’accéder au réseau Wi-Fi via des informations que eux seuls possèdent.

Dans cet article nous allons parlé de l’authentification via compte AD (WPA2-PEAP MSCHAPv2) : comment ça fonctionne et surtout comment on peut s’en servir pour attaquer un environnement Active Directory.

I/ Fonctionnement de WPA2-PEAP MSCHAPv2

Alors déjà, pourquoi WPA2-PEAP MSCHAPv2 ? Eh bien parce qu’il va permettre aux utilisateurs de s’authentifier au réseau via leurs comptes Active Directory. Pour cela on va passer par un serveur RADIUS (Remote Authentication Dial-In User Service).

Le protocole RADIUS :

« permet de faire la liaison entre des besoins d’identification et une base d’utilisateurs en assurant le transport des données d’authentification de façon normalisée »

Wikipédia

Ici nous allons faire la liaison entre notre formulaire d’authentification Wi-Fi et notre Active Directory Windows.

RADIUS repose sur deux composants :
-Un serveur (le serveur RADIUS) qui est lié à une base de données (AD, LDAP, SQL etc.).
-Un client RADIUS (que l’on appelle un NAS : Network Access Server) et qui va jouer le rôle d’intermédiaire entre l’utilisateur et le serveur.

1.png

Pour faire simple (et parce que ce n’est pas le but de cet article), le client WPA va envoyer une demande de connexion au client NAS. Ce dernier va la relayer au serveur RADIUS. Puis le client WPA va s’authentifier via un couple d’identifiants (username et password). Alors bien évidemment le mot de passe n’est pas envoyé en clair… Sur un environnement Active Directory c’est un hash Net-NTLM qui est envoyé.

Du coup pour s’authentifier sur un tel réseau Wi-Fi, pas le choix, il faut avoir un compte Active Directory. Là où ça devient intéressant pour un pentester, c’est que s’il réussit à catcher un identifiant et un hash Net-NTLM alors il pourra se connecter sur l’intranet d’une entreprise (à condition qu’il ait réussi à cracker le hash). Et si l’attaquant a catché le hash Net-NTLM d’un admin du domaine… Eh bien le domaine est compromis !

Mais alors comment faire pour catcher ces credentials ? A priori il semble compliquer de se mettre en position de Man In The Middle… En revanche rien ne nous empêche de monter un faux point d’accès avec un serveur RADIUS afin d’usurper le vrai serveur RADIUS !

Vous l’avez compris, on va encore jouer avec un Rogue AP 😀 !

II/ Hostapd-WPE

L’outil Hostapd-WPE est une version améliorée d’Hostapd qui prend en charge l’authentification via serveur RADIUS. Pour télécharger cet outil il faudra ajouter ce dépôt :

deb http://http.kali.org/kali kali-rolling main non-free contrib

dans le fichier /etc/apt/sources.list puis faire un :

apt update

Suivi d’un :

apt install hostapd-wpe

Le fichier de configuration d’hostapd-wpe se trouve dans le répertoire /etc/hostapd-wpe. Dans ce fichier on va pouvoir configurer pas mal de chose dont notamment le SSID de notre point d’accès :

2.png

Pour les besoins de l’article on va dire que le point d’accès à falsifier s’appelle AuthenticateAP. Du coup dans le champ ssid du fichier de conf on va mettre ce même nom.

Ensuite il va falloir modifier le nom de l’interface Wi-Fi à utiliser. Mais avant tout il va falloir passer notre carte Wi-Fi en mode monitoring. Et pour ça il faut rentrer cette commande :

sudo airmon-ng start 'votre_interface_wifi'

Pour ma part ça donne ça :

3.png

Pour éviter tout conflit, il va falloir kill les process listés par airmon-ng en utilisant la commande suivante :

sudo kill 'PID'

Si maintenant vous tapez la commande :

ip a

Vous allez voir que le nom de votre carte Wi-Fi a changé. Le suffixe « mon » s’y est ajouté :

4.png

C’est ce nom d’interface qu’il faudra donner à hostapd-wpe. Une fois que c’est fait, lancer hostapd-wpe via cette commande :

hostapd-wpe 'votre_fichier_de_configuration'

Et voilà ! Votre point d’accès est fonctionnel :

8.png

Maintenant tentez de vous y connecter et vous verrez que des informations apparaîtront sur votre terminal :

6

Ici on peut voir qu’un utilisateur avec le nom d’utilisateur « test » a tenté de se connecter et on a même capturé le hash Net-NTLM de son mot de passe !

Il ne nous reste plus qu’à tenter de cracker ce hash via John The Ripper pour récupérer le mot de passe en clair du compte :

7.png

Comme vous pouvez le voir, le mot de passe était « test ».

Bon tout ça c’est bien beau mais comment on va obliger quelqu’un à se connecter à notre Rogue AP ? Eh bien pour ça on va tout simplement se servir des requêtes deauthenticate qui vont nous permettre de déconnecter tout les utilisateurs sur un réseau Wi-Fi. En plus de les déconnecter on va aussi faire en sorte que le point d’accès légitime ne soit plus utilisable.

En créant un point d’accès qui utilise le même nom et la même adresse MAC on pourra forcer la reconnexion de ces utilisateurs sur notre faux point d’accès et donc on obtiendra les identifiants de toooooooooooouuuuuuuuuuuuut le monde !

Reste plus qu’à cracker les hash pour potentiellement avoir un accès au domaine ! Mais du coup comment on fait pour se protéger de cette attaque ?

III/ Se protéger contre les Evil Twin

Il est très simple techniquement parlant de se protéger contre les Evil Twin utilisant PEAP-MsCHAPv2 par contre c’est extrêmement complexe de déployer la protection sur tout un domaine.

En fait la meilleure manière de se protéger contre ces faux points d’accès, c’est d’ajouter à notre serveur RADIUS un certificat auto signé et sur tous nos clients, ajouter le certificat d’autorité.

Comme ça, à chaque fois que le client se connectera à un serveur RADIUS, ce dernier va lui envoyer son certificat. Comme le certificat du serveur RADIUS a été signé à l’aide du certificat d’autorité dont dispose le client, ce dernier va considérer que le certificat est authentique et donc envoyer les identifiants.

En revanche si le serveur RADIUS renvoie un certificat bidon, le client va refuser la connexion.

8.png

Du coup j’imagine que vous avez compris pourquoi ça devient difficile de déployer ce mécanisme… Eh oui, toutes les devices d’un domaine ne supportent pas les certificats… C’est le cas d’une grosse partie de l’IoT ! Pareil pour les smartphones, suivant l’OS ça peut être trèèèèèèès relou d’installer un nouveau certificat !

Heureusement sur Windows c’est plutôt simple à faire. Allez dans le panneau de configuration puis dans Réseau et Internet et enfin dans Centre Réseau et partage. Cliquez sur « Configurer une nouvelle connexion ou un nouveau réseau ».

9.png

Choisissez « Se connecter manuellement à un réseau sans fil »  puis entrez les informations du point d’accès. Par exemple :

10.png

Ensuite cliquez sur « Suivant ». Une nouvelle fenêtre va s’ouvrir vous demandant si vous voulez « Modifier les paramètres de connexion ». Cliquez dessus, allez dans l’onglet « Sécurité » puis cliquez sur « Paramètres ». Assurez vous que la case « Vérifier l’identité du serveur en validant le certificat » est cochée :

11.png

Puis choisissez votre autorité de certification racine et cliquez sur OK. A partir de maintenant votre client ne devrait plus envoyer ces identifiants à l’Evil Twin. D’ailleurs si on regarde l’output d’hostapd-wpe on voit bien que le client n’envoie plus rien :

12.png

On voit même que le certificat d’autorité n’est pas reconnu ce qui implique que le client n’envoie pas ses identifiants.

Au final on peut déployer assez facilement cette protection via GPO mais ça reste quand même assez dur de la déployer sur tout un domaine qui utilise plusieurs devices différentes.

 

9 commentaires

    1. Hello ! A moins que je dise une bêtise (ce qui est fort possible), je crois que PEAP n’a besoin que d’un certificat et d’une clé publique côté serveur. Comme nous sommes le serveur nous pouvons donc déchiffrer le contenu des trames.

      J'aime

  1. Je ne suis pas sur là dessus, c’est pour ca que je pose la question. Mais moi de ce que j’avais compris, le client à une certificat qui contient une clé publique. Donc grace à une authentification avec cette clé publique on arrive à créer un tunnel TLS sécurisé. Donc si le serveur n’a pas la bonne clé privée, ca ne peut pas marcher. C’est cette partie que je ne comprend pas. Comment votre serveur peut réussir à s’authentifier avec le client ?

    J'aime

  2. Car lorsque je regarde wikipedia : https://fr.wikipedia.org/wiki/Extensible_Authentication_Protocol#PEAP

    PEAP se déroule en deux phases :

    La phase 1 permet l’identification du serveur grâce à une Infrastructure à clés publiques. Une fois le serveur identifié, il y a la création d’un tunnel sécurisé qui permettra à la phase 2 d’être chiffrée.
    La phase 2 permet l’identification du client au travers du tunnel chiffré.

    Il y a bien marqué que le serveur s’authentifie avec le client. Donc si le serveur n’a pas la bonne clé privée, ca ne peut pas marcher.

    J'aime

    1. Effectivement, les informations ont l’air de concorder. Je vais me renseigner de mon côté et j’ajouterais des modifications dans un commentaire et dans l’article en fonction des réponses que j’ai trouvé !
      Merci pour tes retours 🙂

      J'aime

Répondre à mickae1 Annuler la réponse.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l'aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s