Cassage de WEP hors des sentiers battus

1. Le cas d'école

Le cas classique d'application de la technique de cassage de WEP est celui d'un point d'accès (AP) et d'un client sans-fil associés, tous deux configurés en WEP, forcément. L'AP est configuré pour proposer une authentification de type Open. Comprendre par là qu'il ne nécessite pas d'authentification...

Le processus de cracking se déroule assez simplement, en plusieurs étapes successives.

1.1 Passage de la carte en mode monitor

L'attaque nécessitant de capturer le trafic au format 802.11, il est nécessaire de passer sa carte Wi-Fi. Ceci se fait au moyen de l'outil airmon-ng.

1.2 Identification du réseau cible par scan de l'environnement Wi-Fi

Pour scanner l'environnement Wi-Fi, on utilise l'outil airodump-ng qui, lancé sans option, permet d'écouter sur tous les canaux en séquence (channel hopping).

Comme seuls les réseaux protégés en WEP nous intéressent, on peut également préciser à l'outil de n'afficher que les réseaux ainsi protégés.

1.3 Capture du trafic du réseau cible

Pour capturer le trafic nécessaire au cassage de la clé WEP, on utilise encore une fois l'outil airodump-ng, en lui fixant un canal à écouter, un fichier de sortie, et éventuellement, le BSSID du réseau pour filtrer la capture.

La capture, au format PCAP, sera écrite dans un fichier nommé miscwep-01.cap. Pour filtrer le trafic au seul réseau visé, on utilisera l'option --bssid. C'est une option pouvant se révéler utile quand plusieurs points d'accès actifs cohabitent sur le même canal.

On laissera tourner cette capture jusqu'à la fin de l'attaque.

1.4 Authentification d'une adresse MAC factice

Pour pouvoir injecter du trafic en provenance d'une adresse MAC factice, il est d'abord nécessaire d'associer cette dernière au point d'accès. Pour ce faire, on utilise l'outil aireplay-ng. Ce dernier est un peu le couteau suisse de l'attaque WEP, implémentant la plupart des attaques contre ce type de protection.

En cas de fort trafic parasite en provenance d'autres réseaux, on peut toujours passer une option de filtrage à aireplay-ng via l'option -b.

1.5 Préparation de l'injection ARP

L'étape essentielle de l'attaque consiste à rejouer du trafic ARP capturé sur le réseau cible de manière à générer du trafic. Là encore, on utilisera l'outil aireplay-ng qui se chargera de l'identification de trames susceptibles d'être des requêtes ARP, de les capturer et les rejouer sur le réseau cible.

À l'instar de la capture, ce processus de rejeu devra tourner jusqu'à la fin de l'attaque.

1.6 Désauthentification d'un client légitime

Pour que l'étape précédente fonctionne, il faut qu'au moins une requête ARP soit émise par le réseau cible pour qu'elle puisse être rejouée. L'émission de cette requête peut être déclenchée par la désauthentification des clients légitimes du réseau cible, laquelle aura pour effet de vider leur cache ARP. Une fois revenus sur le réseau, ils émettront à nouveau des requêtes ARP.

Comme la sortie de l'outil le suggère, il est souvent plus efficace, et plus discret, de cible un client spécifique.

Au bout de quelques envois, on arrête l'émission des trames de désauthentification pour laisser les clients se réassocier et émettre leur trafic ARP. On doit alors voir le processus d'injection ARP détecter des requêtes et commencer l'injection de trames. Au même moment, on constate que le compteur de trames de données capturées par airodump-ng augmente très rapidement.

1.7 Cassage de la clé WEP

La dernière étape consiste à lancer le processus de cassage de clé sur la capture générée par airodump-ng. Ceci se fait au moyen de l'outil aircrack-ng.

Le processus tournera jusqu'à ce que la capture ait atteint la taille critique permettant à l'attaque de donner des résultats significatifs, c'est-à-dire environ 50000 trames de données. C'est alors que devrait tomber la clé...

2. Les variations sur la configuration du point d'accès

Malheureusement, dans la nature, on ne croise pas que des réseaux configurés de manière à ce que ce scénario idéal se déroule sans heurt. Loin de là. Il est donc nécessaire d'adapter sa stratégie en fonction de la situation rencontrée.

2.1 Le SSID du réseau cible est masqué

Il peut arriver qu'on soit capable d'identifier le réseau cible sans pour autant découvrir son SSID lorsque celui-ci est masqué (SSID cloaking). Dans ce cas, airodump-ng vous affichera <length: 0> comme valeur de SSID. Or, nous avons besoin de cette donnée pour réaliser l'étape 4, à savoir l'authentification d'une adresse MAC factice qui servira de source à nos injections de trafic.

On peut contourner ce problème de deux manières. La première consiste à ignorer complètement le SSID qui n'est nécessaire qu'à cette étape et ne pas en tenir compte. On utilisera alors l'adresse MAC d'un client légitime associé au moment de l'attaque comme source de nos trames. Dans le cas présent, on pourrait utiliser l'une des deux adresses visibles, 00:12:F0:26:52:9D ou 00:0E:8E:0D:FD:D9, qu'on passera alors à l'option -h (en lieu et place de 00:11:22:33:44:55 dans les exemples précédents).

La seconde méthode, souvent plus satisfaisante pour la curiosité, consiste à désauthentifier un client légitime associé au réseau afin de l'amener à se réassocier. Se faisant, il transmettra le SSID du réseau en clair dans sa requête. Vous pourrez alors le voir s'afficher dans la sortie de airodump-ng en lieu et place du fâcheux <length: 0>. Cette attaque sera donc à réaliser entre les étapes 3 et 4 précédemment décrites.

2.2 Le réseau cible utilise le filtrage d'adresses MAC

Une fonctionnalité de sécurité très populaire sur les points d'accès est le filtrage d'adresse MAC. Il s'agit d'une liste blanche que l'utilisateur peuple d'adresses autorisées à s'associer au point d'accès. Certaines box d'opérateurs implémentent ce mécanisme de manière détournée en nécessitant de la part de l'utilisateur une action physique pour l'ajout d'un nouvelle adresse à la liste.

Comme précédemment, on peut passer outre cette restriction en utilisant l'adresse d'un client légitime associé au moment de l'attaque. Mais plus généralement, toute adresse MAC dont on aura constaté qu'elle parvient à s'associer à l'AP cible pourra être utilisée à la place de 00:11:22:33:44:55 dans les exemples précédents.

2.3 Le réseau cible nécessite une authentification

Certains réseaux, rares cependant, demandent une authentification en mode Shared. Ceci implique une réponse à un challenge, qui nécessite la connaissance de la clé WEP. Or c'est précisément ce qu'on cherche à trouver...

Dans ce cas de figure, l'AP va rejeter la tentative d'authentification de l'adresse MAC factice.

Là encore, la solution simple consiste à utiliser l'adresse d'un client légitime associé. Comme on peut le voir, c'est une méthode assez générique qui permet de contourner l'essentiel des restrictions mises en place au niveau de l'AP en une seule fois.

L'autre méthode consiste à exploiter une faille dans le mécanisme d'authentification de WEP pour le contourner. Cette faille est une situation de clair connu entre deux messages du handshake d'authentification, qui nous permet de récupérer un keystream utilisable pour générer une réponse valide à partir d'un challenge sans connaissance de la clé WEP.

Pour y parvenir, il faut que airodump-ng capture l'authentification d'un client légitime, soit parce qu'il s'associe naturellement au réseau cible, soit parce que vous l'avez désauthentifié à cet effet. L'outil affiche alors SKA dans la colonne AUTH de sa sortie et génère un fichier contenant le fameux keystream, par exemple sharedkey-01-00-14-BF-63-1E-42.xor.

Muni de ce précieux sésame, on pourra s'authentifier au réseau.

3. Variation sur les conditions de l'attaque

Parfois, les conditions de l'attaque peuvent s'éloigner du cas d'école, ce qui oblige à se montrer quelque peu... imaginatif...

3.1 Pas de client associé en vue

Le cas d'école suppose un client associé à l'AP du réseau cible. Si c'est souvent le cas, parfois, on se retrouve dans une situation quelque peu différente, à savoir sans aucun client associé... C'est un cas assez courant, mais aussi parfois fastidieux à résoudre, qui peut néanmoins se contourner si la partie filaire du réseau émet du trafic visible sur le réseau Wi-Fi ou si on dispose d'une capture de trafic valide du réseau cible.

3.1.1 Une solution simple

La solution la plus simple consiste à capturer un paquet émis par le point d'accès et à le réémettre à destination de l'adresse de broadcast Ethernet. Recevant un tel paquet, l'AP va le réémettre, mais après l'avoir rechiffré, générant un nouvel IV utilisable pour casser la clé WEP. Cette technique s'utilise avec l'option d'injection interactive de aireplay-ng, qui permet de sélectionner soi-même le paquet qu'on veut injecter dans le réseau cible.

aireplay-ng va alors vous proposer des trames à injecter. En choisir une assez petite permettra d'accélérer le déroulement de l'attaque.

On notera que si on dispose d'une capture de trafic valide du réseau cible, on peut utiliser celle-ci comme source pour la génération de la trame à injecter. Il suffira de passer le fichier PCAP en option à aireplay-ng pour ce faire.

Tout ceci vient remplacer les étapes 5 et 6 du cas d'école. Ce qui suppose évidemment que l'adresse 00:11:22:33:44:55 a été au préalable associée comme dans l'étape 4, avec l'option --fakeauth de aireplay-ng. Si ce n'est pas possible du fait d'un filtrage d'adresse MAC, il vous faudra une adresse autorisée. Si c'est une authentification en mode Shared ou un SSID masqué qui vous en empêche, dans la mesure où vous avez besoin d'un client légitime pour contourner le problème, vous êtes malheureusement bloqué...

Il existe cependant un petit hic à cette solution, avec une fonctionnalité couramment appelée « isolation de stations », qui consiste à bloquer au niveau de l'AP tout trafic émis par une station Wi-Fi associée à destination du réseau sans-fil. Si elle a été créée avant tout pour empêcher la propagation de malwares sur les réseaux publics, son utilisation dans un réseau protégé en WEP va tout simplement bloquer l'émission sur le segment sans-fil de la trame que nous essayons d'injecter...

3.1.2 Une solution un peu plus compliquée

Une autre solution ne manquant pas de style existe. Elle suppose également que vous ayez été capable d'associer une adresse MAC. Sinon, dommage... Dans ce cas de figure, il va s'agir de générer une requête ARP à la main, en obtenant dans un premier temps un keystream à l'aide d'une attaque par fragmentation ou de type Chopchop, de s'en servir pour générer une requête ARP à l'aide de packetforge-ng, puis de l'injecter dans le réseau. Autant dire que ça demande de l'huile de coude et un peu de chance...

Les attaques par fragmentation ou de type Chopchop s'exécutent avec aireplay-ng respectivement de la manière suivante :

En cas de succès, la première produit un fichier de la forme fragment-1105-210332.xor alors que pour la seconde, ce sera plutôt replay_dec-1105-211123.xor. Ces fichiers contiennent un keystream qui va nous permettre de générer une trame chiffrée valide.

Selon qu'on aura obtenu son keystream par fragmentation ou Chopchop, on fera respectivement ainsi :

Nous générons ainsi un fichier PCAP, arprequest.cap contenant une trame chiffrée, laquelle est une requête ARP de l'IP 255.255.255.255 pour l'IP 255.255.255.255. En effet, n'ayant aucune idée de l'adressage utilisé sur le réseau cible, il faut bien trouver quelque chose. Et ce quelque chose est l'adresse de broadcast qui fonctionne globalement assez bien sur un AP. Dans le cas contraire, il faudra s'orienter vers une séance de devinettes consistant à générer des requêtes pour les adresses en .1 et .254 des plages privées classiques et les injecter pour voir laquelle génère une réponse, ce qui se scripte facilement.

L'étape finale consiste à injecter la requête ARP ainsi formée.

Comme précédemment, ces manipulations viennent remplacer les étapes 5 et 6 du cas d'école. En cas de succès, vous verrez le nombre d'IV utilisables dans la sortie de aircrack-ng augmenter à un rythme soutenu et pourrez espérer récupérer la clé WEP.

Comme dans la méthode simple, l'isolation de stations va nous poser un réel problème parce ce qu'elle bloquera les attaques par fragmentation et de type Chopchop.

3.2 Le point d'accès refuse vos injections

Dans tous les cas précédemment évoqués, le trafic injecté l'est à destination de l'AP, lequel se chargera de le relayer vers sa destination. Parfois, ce dernier se montre sourd à toutes vos tentatives d'injection, comme lorsque l'isolation de stations est activée. Une solution est alors de se tourner directement vers un éventuel client légitime associé.

Ceci peut se faire de plusieurs manières différentes. La première consiste à capturer du trafic à l'aide de airodump-ng et de l'analyser à l'aide d'un outil comme wireshark pour ne conserver dans un nouveau fichier, par exemple interesting.cap, que les trames que vous jugerez intéressantes à destination de ce client, à savoir celles qui auront une bonne tête et auront surtout généré une réponse. On utilisera ces trames en injection interactive avec aireplay-ng.

Une seconde méthode consiste à faire la même chose en live, directement depuis aireplay-ng en mode interactif. Pour capturer une requête ARP, l'idée ici est de ne conserver que les trames émises en broadcast Ethernet par le point d'accès et ayant une taille comprise entre 68 et 86 octets environ.

Vous trouverez des tutoriaux vous expliquant comment faire la même chose en vous appuyant sur les attaques par fragmentation ou de type Chopchop déjà utilisées précédemment pour récupérer le fameux keystream qui vous permettra de générer la trame à injecter. Le souci, c'est que si vous visez un client parce que le comportement de l'AP ne vous donne pas satisfaction, ni une attaque par fragmentation, ni un Chopchop ne passeront, dans la mesure où ces dernières s'appuient justement sur l'AP...

Notez toutefois, pour la curiosité, que si vous êtes en face d'un AP exigeant une authentification en mode Shared et que vous êtes parvenu à capturer une authentification, alors le fichier sharedkey-01-00-14-BF-63-1E-42.xor généré par airodump-ng est suffisamment long pour être utilisé afin de créer une requête ARP à l'aide de packetforge-ng.

Le souci avec cette méthode est que vous allez devoir deviner l'espace d'adressage du réseau cible, et en particulier l'adresse IP du client que vous visez, ce qui n'est pas terriblement efficace. Une attaque de type Chopchop aurait pu vous donner la réponse, si vous pouviez la lancer...

Conclusion

Ce petit tutoriel couvre l'essentiel des cas qu'on rencontre couramment lorsqu'on doit démontrer la faiblesse d'un réseau Wi-Fi protégé en WEP. Il vise également à montrer que les fonctionnalités additionnelles que sont le masquage de SSID, le filtrage d'adresses MAC ou encore l'isolation de station n'ont qu'un impact réduit sur les chances de succès d'un attaquant motivé.