Dans les chapitres précédents nous avons mis à mal le protocole WEP, nous allons voir maintenant comment exploiter le successeur de WEP, WPA !

WPA : s’appuie sur l’utilisation de TKIP (comme WEP), pas besoin de changer d’hardware, il suffit de mettre à jour les firmware des différents périphériques pour l’utiliser.

On a eu ensuite quelques choses d’encore plus robuste ; WPA2 qui utilise CCMP (basé sur AES).

WPA et WPA2 ont chacun une « personnal » et « enterprise » édition.

« personnal » édition repose sur quelque chose appelé « psk » (pre shared key).

« enterprise » édition utilise  802.1x + serveur raidus .

Le WPA enterprise nécessitant la mise en place d’un serveur Radius, vous vous douterez que tous les particuliers / petite structures utilisent donc le WPA psk.

C’est ce que nous allons étudier par la suite et ce que je vais tenter de vous expliquer et faire comprendre le fonctionnement du WPA.

Ce qui est intéressant se passe lors de la connexion d’un client au point d’accès (certains petits malins auront sans doute entendu parler du fameux « 4-way handshake » utile pour bruteforcer du WPA) .

Prérequis et vocabulaire pour la suite :

Supplicant : est le client qui tente d’accéder au réseau

Authenticator : est le point d’accès.

Une clé dynamique est crée à chaque connexion permettant la communication / déchiffrage des données  entre le client et l’AP.

Dans un première temps le supplicant (client) saisit la passphrase (ou clé WPA).

Cette clé est hashé à l’aide d’une fonction « PBKDF2 »  qui prend en entrée : le SSID, la longueur du SSID, la paraphrase.

Cette fonction hash la clef 4096 fois pour avoir en sortie une « pre-shared key » sur 256 bit.

L’authenticator fait de même et à lui aussi la pre-shared key.

Tant que l’utilisateur ne change pas la clé WPA ou le nom du SSID la psk (pre-shared key) est toujours la même (logique puisque le hash est généré en fonction de la clé WPA / SSID).

Donc si l’utilisateur a rentré la bonne clef, le « pre-shared key » du supplicant et de l’authenticator sont bien les mêmes…

Regardez attentivement ce schéma réalisé par notre ami Vivek, c’est ce qui se produit à chaque fois qu’un supplicant (client) veut se connecter sur l’authenticator (AP) .

Une fois que l’utilisateur s’est authentifié (Authentifcation RR + Association RR)

L’authenticator  envoie un  « ANounce » (message 1) contenant une valeur arbitraire et aléatoire

Le supplicant génère à son tour un SNounce qui est aussi une longue chaine aléatoire puis crée ce que l’on appelle PTK (pairewise transient key).

Ce PTK (la fameuse clé dynamique) c’est une fonction qui prend en entrée entre autres (le ANounce, le SNounce, l’adresse MAC du supplicant, l’Authenticator MAC) pour générer une clé uniquement valide pour cette connexion. (Si l’utilisateur se déconnecte puis reconnecte, le processus recommencera et une nouvelle PTK sera généré).

Une fois le PTK généré, le client envoie le SNounce au client accompagné du MIC.

A ce stade l’authenticator reçoit le « SNounce » la seule information qui lui manquait pour générer le PTK. Il peut donc le générer. Il reçoit aussi du supplicant le « MIC ».

 Le MIC c’est simplement un hash permettant de contrôler l’intégrité (vérifier dans un premier temps que le supplicant ont la même PSK, puis le même PTK).

Désormais si le MIC est ok, l’authenticator renvoie un message 4 « key install » afin d’établir la communication et le client / AP communiquent en chiffrant leur message à l’aide entre autres du PTK généré.

Si le MIC n’est pas bon, c’est que l’utilisateur n’a pas renseigné la bonne clé WPA donc l’AP envoie un paquet de desauth au client.

Faisons un petit résumé des notions que nous venons de voir :

PMK = Pre-shared key, la clé maître qui est la même à chaque connexion (tant que le SSID, où la passphrase de l’AP n’est pas changé !).

ANounce = Chaine aléatoire envoyée par l’AP, différente à chaque connexion…

SNounce = Chaine aléatoire envoyée par le supplicant , différente à chaque connexion…

Ce « ANounce » et « SNounce » permettent de générer une clé dynamique, unique/ connexion appellé « PTK ».

MIC : pour vérifier l’intégrité : (permet de vérifier que le client à la même PSK que l’authenticator / même PTK).

La phase de dérivation du PMK vers PTK est ce que l’on appelle le « 4-way handshake » nécessaire pour réaliser un bruteforce de crack WPA.

Pour le récupérer c’est très simple, on lance airodump en ciblant le bssid victime.

Après soit on attend passivement qu’un client se connecte, ou on  envoye un paquet de desauthentification afin de le forcer à se reconnecter.. et ainsi récupérer notre « 4-way handshake ».

Encadré en vert : airodump à récupéré le WPA handshake lors de la connexion du client sur le point d’accès.

Sous Wireshark vous pouvez vous amuser (et je vous le conseille !) à regarder le contenu de ces 4 paquets :  (filtre « eapol » afin de voir seulement les paquets qui nous intéressent ici).

  Conclusion : le WPA est un protocole plus solide que le WEP mais nous allons voir qu’il n’est pas « incassable » et qu’en faisant preuve d’imagination nous pouvons assez facilement récupérer une clé WPA/ WPA2…