Récemment, j'ai lu que le WEP c'était pareil que le WPA. Tenir de tels propos est honteux, tellement que le WEP est à la ramasse et ne vaut rien niveau sécurité. Dans ce billet, je vais vous expliquer le fonctionnement du WEP, puis vous montrer ses faiblesses et comment les exploiter.

Un point sur la notation que je vais employer durant ce billet :

  • || opérateur de concaténation. Exemple :
    ABCD || E = ABCDE
  • + représente le XOR (ou exclusif), à ne surtout pas confondre avec la simple addition. Exemple :
    1010(2) + 1100(2) = 0110(2)
  • M représente le message clair
  • C représente le chiffré
  • K représente la clé WEP

De plus dans la suite de l'article, je vais dire que l'AP ou le client va envoyer comme requête :

IV||C

Cela est pour simplifier les choses. En fait, Il faut garder à l'esprit qu'il y a l'header 802.11, le BSSID, l'IV et l'adresse de destination en clair. Ensuite, en chiffré vienne LLC, SNAP, le message, et l'ICV.

Le WEP en une phrase

Le WEP (Wired Equivalent Privacy) est un protocole de chiffrement pour les réseaux Wi-Fi IEEE 802.11. Pour plus d'informations à ce sujet : go to wiki

Explication du protocole

Un paquet est formé respectivement de :

  • IV +Pad + KeyID (4 octets)
  • PDU (> 0)
  • ICV (4 octets)

IV (Initialisation Vector) + Pad + KeyID

Ce champ de 4 octets se compose en trois sous-champs :

  • IV (3 octets) : qui va être utilisé comme seed
  • Pad (6 bits)
  • KeyID (2 bits)

Le dernier octet (Pad + KeyID) n'est pas important pour la suite de l'article.

PDU (Protocol Data Unit)

Ce champ représente l'information envoyée par la couche 3 (réseau) qui va être chiffrée. Une fois déchiffré, et si tout s'est bien déroulé, le message sera passé à la couche réseau. Par la suite, j'utiliserai la notation M (au lieu de PDU) dans les calculs pour les alléger.

ICV (Integrity Check Value)

Ce champ de redondance de 4 octets permet de prévenir l'altération de données accidentelles pendant la transmission. J'insiste sur le mot "accidentelle", car cela n'a pas le même but que les fonctions de hachage permettant de s'assurer de l'altération d'un message par un tiers. WEP utilise le fameux CRC32 comme ICV.

Le chiffrement WEP

WEP utilise un chiffrement par flot (XOR) pour crypter les données, la clé étant obtenu par le PRNG du chiffrement RC4. Prenons l'exemple d'une clé WEP 128 bits. L'utilisateur choisit en fait 104 bits, soit 26 caractères hexadécimaux. Ceci représentera véritablement la clé WEP qu'on notera K par la suite. Elle sera concaténée avec l'IV qui changera pour chaque paquet. 104 bits (K) + 24 bits (IV) donne bien 128 bits. Ouf !

Et sans plus attendre, l'algorithme du chiffrement WEP :

C = RC4(IV||K) + (M||CRC(M))

Alors, le paquet qui sera envoyé sera :

IV||C

Pour le déchiffrement, le destinataire va recevoir donc le paquet ci-dessus. Il va décapsuler l'IV et calculer :

RC4(IV||K) + C = RC4(IV||K) + (RC4(IV||K) + (M||CRC(M)) = M||CRC(M)

Il ne lui reste plus qu'à décapsuler M, de calculer son ICV et de le comparer avec CRC(M). Si la vérification s'avère correcte, le PDU sera envoyé à la couche supérieure, sinon WEP générera une erreur MAC.

L'authentification

Tout dépend du mode utilisé :

  • Open System Authentication
  • Shared Key Authentication

Dans le premier mode (Open System Authentication), le client n'a aucune donnée à fournir pour s'authentifier. Il tente donc directement l'association (le filtrage par adresses MAC peut faire échouer cette étape par exemple). Le client devra quand même posséder la clé WEP pour pouvoir dialoguer par la suite, et c'est heureux.

Dans le second mode (Shared Key Authentication), un 4 Way Challenge-response aura lieu :

  • le client envoie une requête d'authentification,
  • l'AP envoie un challenge en clair,
  • le client chiffre le challenge en utilisant sa clé WEP et l'envoie à l'AP,
  • l'AP déchiffre la trame reçu et compare au challenge. Le résultat de la comparaison donnera lieu ou non à l'authentification. Même remarque pour l'association.

Les faiblesses ?

L'authentification

On pourrait penser que l'authentification par clé partagé est meilleure, puisqu'en fait l'autre n'offre aucune authentification proprement dite. Et pourtant...

Lors de l'authentification (Shared Key Authentication), l'AP va envoyer un challenge en clair, qu'on va noter M. Et le client va renvoyer le challenge chiffré, qu'on va noter C. Ainsi, une personne malveillante (Oscar) sniffant le réseau peut récupérer M et C.

IV||C avec :
C = RC4(IV||K) + (M||CRC(M)
donc : RC4(IV||K) = C + (M||CRC(M)) = P

Donc Oscar va pouvoir récupérer le PRNG (P) sur 128 octets (taille du challenge) correspondant à l'IV utilisé par le client. Et comme rien dans WEP n'empêche le rejeu, cette quantité sera acceptée par l'AP. Maintenant Oscar tente de s'authentifier sur l'AP qui va lui envoyer un challenge M'. Oscar, sans connaître la clé K enverra :

IV||C' avec :
C' = P + (M'||CRC(M')

De son côté l'AP déchiffrera C' avec l'IV envoyé par Oscar.

RC4(IV||K) + C' = RC4(IV||K) + P + (M'||CRC(M') = M'||CRC(M')

Et, paf, voilà Oscar authentifié, sans aucun calcul si ce n'est que le CRC du challenge. Donc, il vaut mieux ne pas utiliser l'authentification par clé partagé sous risque de donner à Oscar un PRNG valide avec son IV correspondant et qu'il pourra réutiliser à volonté.

Le chiffrement

Le chiffrement est guère mieux que l'authentification étant donné la faiblesse du chiffrement RC4. Il est possible de :

  • déchiffrer un quelconque paquet facilement,
  • injecter des données,
  • et deviner la clé K
Faiblesse

Dans un réseau IEEE 802.11 chiffré, il n'est pas dur de prédire le payload des en-têtes. Généralement, le début de la sortie RC4 sera "Xoré" avec le payload LLC/SNAP. Ce qui donne :

  • AAAA030000000800 pour un paquet IP
  • AAAA030000000806 pour un paquet ARP

Si on applique le chiffrement WEP au payload LLC/SNAP, cela donne :

C=RC4(IV||K) + M||CRC(M) 
Soit RC4(IV||K) = C + (M||CRC(M)) avec IV, M, IV connus.

M a une taille de 8 octets (taille LLC/SNAP) et CRC(M) a une taille de 4 octets. Ce qui donne une sortie de 12 octets pour le flux RC4 qu'on peut calculer pour l'IV donné. En jouant avec la fragmentation 802.11 (qui imite à 16 fragments), nous pouvons chiffrer une trame suffisamment longue pour stimuler le réseau. Par exemple :

  1. AAAA0300 CRC
  2. 00000800 CRC
  3. Débu         CRC
  4. t de           CRC
  5.  not           CRC
  6. re p           CRC
  7. aylo           CRC
  8. ad.            CRC
  9. ETC           CRC

Et si la trame est destinée au réseau local, l'AP défragmentera le paquet et l'enverra par onde avec une nouvelle IV. Nous allons donc recevoir une nouvelle trame C de longueur 128 (8*16). Puis on recommence la fragmentation pour obtenir un paquet de longueur 1024 (128*16). Et en répétant une dernière fois ce processus, nous aurons connaissance d'un flux RC4 de la taille du MTU correspondant à un IV particulier. L'injection de n'importe quel paquet est désormais possible.

Exploitation

Et maintenant si on simule le réseau, (avec des paquets ARP comme le fait très bien aireplay), on peut se constituer une table RC4 en fonction d'un IV. Avec le recul qu'on a sur le chiffrement RC4, plusieurs faiblesses ont été décrites. Et le résultat est impressionnant : cassage de la clé WEP en 10 minutes (puis 1 minute avec le dopage apporté par la version PTW).

Il est important de remarquer que l'attaque n'a rien à voir avec du brute-force. Auquel cas, casser une clé 104 mettrait beaucoup plus de temps que 40 bits (puisqu'exponentiel). Là, il en est autrement, et on observe que l'attaque met à peine deux fois plus longtemps.

Camouflage de l'ESSID et filtrage MAC

Certains pensent avoir trouvé la parade en empêchant la diffusion du SSID et en filtrant les adresses MAC. Oui mais parade sans réel efficacité.

En effet, si on camoufle l'ESSID, un client légitime donnera la liste de ses ESSID enregistrés sur la machine jusqu'à connexion. Et si quelqu'un sniffe le réseau à ce moment-là, il obtient non seulement le bon ESSID, mais en plus les autres enregistrés chez le client. Donc pas efficace à part une fuite d'informations.

Et le filtrage MAC, c'est guère mieux. Si Oscar sniffe le réseau, il va obtenir l'adresse MAC d'un client autorisé (sinon autant désactiver le Wi-Fi). Il ne reste plus qu'à usurper ladite adresse MAC, et hop retour au cassage du WEP.

Et donc, que faire ?

La conclusion est sans appel et très simple. Il ne faut plus utiliser le WEP. Qu'il soit en 64, 128 ou 256 bits, il reste très faible. Il faut donc utiliser WPA ou mieux encore WPA2 pour l'authentification, et TKIP* (ou CCMP/AES si cela est compatible avec le driver de votre carte, avec votre OS et avec le firmware de l'AP). A noter que la version PSK de WPA est beaucoup moins sécurisé que WPA enterprise. Mais tout le monde ne peut pas se monter un serveur radius.

Il est également possible d'utiliser un VPN.

(*) TKIP : La version TKIP a vu quelques attaques dirigées contre elle. Il est donc conseillé d'utiliser CCMP/AES.

Lien

  1. http://wiki-files.aircrack-ng.org/doc/wepexp.txt
  2. http://sid.rstack.org/blog/index.php/56-pourquoi-c-est-pourri-le-wep-part-1-comment-ca-marche
  3. http://sid.rstack.org/blog/index.php/57-pourquoi-c-est-pourri-le-wep-part-2-cassage-en-regle
  4. http://sid.rstack.org/blog/index.php/60-pourquoi-c-est-pourri-le-wep-part-3-comment-se-protege-t-on-alors
  5. http://standards.ieee.org/getieee802/download/802.11i-2004.pdf