Attaque par déni de service dans le Wi-Fi

Par définition, une attaque de dénis de service (Denial of Service ou DoS en anglais) consiste à rendre un service inutilisable par ses utilisateurs potentiels. Le service généralement fourni par le Wi-Fi est la mise à disposition d’une connectivité réseau à des appareils. Une attaque DoS va ainsi viser à rendre ce lien de connectivité inopérant (voir figure 1). Une attaque DoS peut être implémentée de différentes manières, par exemple en épuisant une ressource nécessaire à fournir le service, ou en exploitant des fonctionnalités du service.

Dans le contexte de la technologie Wi-Fi décrite par la famille de spécifications 802.11, les attaques DoS peuvent prendre plusieurs formes. Nous allons nous intéresser à deux types d’attaques : premièrement, une attaque, dite logique, qui exploite le mécanisme de Deauthentification de 802.11 ; deuxièmement une attaque, dite physique, qui impliquera un brouillage du signal radio afin de bloquer les communications. Nous laisserons de côté les attaques visant les couches supérieures.

1. Attaque par Deauth

La première méthode d'attaque par dénis de service que nous allons voir exploite le mécanisme de Deauthentication du protocole 802.11, qui lorsqu’il est exploité à mauvais escient, permet de mettre en place des attaques DoS extrêmement efficaces. Cette attaque exploite un élément de la couche liaison et se place donc en haut du sous-ensemble de la pile couvert par le protocole 802.11.

1.1  Mécanismes de connexion et déconnexion

Avant de nous lancer dans la présentation de cette attaque, il convient de rappeler quelques éléments concernant les mécanismes de connexion et de déconnexion du protocole 802.11. La connexion d’une station à un point d’accès passe par une phase en 2 étapes : l’authentication puis l’association. L’authentication est effectuée à la demande d’une station auprès d’un point d’accès, elle permet à la station de déclarer son identité auprès du point d’accès en lui présentant son adresse MAC. L’étape d’association arrive après et achève la connexion ; lors de celle-ci, le point d’accès alloue les ressources qui permettront à la station d’accéder à son réseau.

Le point d’accès peut révoquer l’authentication d’une station en le lui signalant via une trame management de sous-type Deauthentication ; la station considèrera alors qu’elle est n’est plus authentifiée et donc plus connectée au point d’accès. En général, les mécanismes de connexion automatique intégrés à l’OS font qu’une station qui se déauthentifie va immédiatement chercher à se reconnecter au point d’accès en suivant la procédure précédemment décrite (Authentication puis Association).

1.2 Principe de l’attaque

Si une trame Deauthentication est normalement émise par un point d’accès à destination d’une station, rien n’empêche une autre entité d’émettre une telle trame à destination d’une station connectée. Une station recevant cette trame suivra alors la procédure prévue par le standard et considèrera qu’elle est deauthentifiée. Ceci est possible, car la source de la trame Deauthentication n’est pas authentifiée et il est facile pour un attaquant de forger une telle trame en usurpant l’identité du point d’accès. En effet, il suffit pour cela d’émettre une trame pour laquelle l’adresse émettrice est celle du point d’accès.

À partir de là, une attaque Deauth est assez simple à mettre en place. Elle consiste à envoyer en série de trames Deauthentication à destination d’une station connectée à un point d’accès. Plus particulièrement, il suffit d’envoyer une trame Deauthentication dès que cette station termine la procédure de connexion au point d’accès. Ainsi, le lien réseau entre la station et le point d’accès est systématique coupé juste après sa mise en place et la station ne peut plus bénéficier des services du point d’accès. D’où le déni de service.

En plus du déni de service, une attaque Deauth sert également de base à plusieurs attaques contre les mécanismes de protection WEP et WPA. En effet, elle permet de forcer une station à se reconnecter au point d’accès et force ainsi la station et le point d’accès à exposer certaines données nécessaires pour ces attaques.

1.3 Deauth avec aireplay-ng

Une attaque Deauth peut très facilement être mise en place avec l’outil aireplay-ng de la suite aircrack-ng. Celui-ci inclut un mode d’attaque –deauth=<count> qui permet de générer count trames de deauthentication. Ces trames sont envoyées aux stations connectées à un point d’accès (le BSSID du point d’accès est indiqué via l’option –a <bssid>). Une fois le BSSID du point d’accès identifié (avec l’aide d’airodump-ng par exemple), on peut lancer l’attaque de la manière suivante :

Par défaut, aireplay-ng envoie des trames avec une adresse destination broadcastff:ff:ff:ff:ff:ff, mais il est possible de cibler une station via l’option -c <dmac>.

On peut observer les trames générées dans Wireshark (voir figure 2) : des trames de type management (Type : 0) et de sous-type deauth (Subtype : 12) ayant les champs adresse transmitter, source et BSSID égaux à l’adresse MAC du point d’accès. Les adresses destination et receiver sont quant à elles égales à l’adresse de la station ciblée, ici broadcast (voir premier cas au-dessus). On constate également que cette trame contient une « explication » inclue dans le corps de la trame sous la forme d’un reason code. Dans le cas présent, le reason code a comme valeur 0x0007 indiquant que la Deauthentication intervient, car des trames de class 3 ont été reçues de la station. Cette justification est bien entendu dans notre cas totalement infondée.

1.4 Deauth ciblé avec scapy

Plutôt que d’utiliser un outil comme aireplay-ng qui nous mâche le travail, on peut monter une attaque Deauth en forgeant nous-mêmes des trames à l’aide d’un outil tel que scapy. Pour rappel, scapy est un outil écrit en Python qui permet de recevoir, analyser, forger et envoyer des paquets réseaux pour un grand nombre de protocoles réseaux, et en particulier le protocole 802.11 (Dot11 dans scapy).

Les fonctionnalités de scapy permettent de mettre en place des attaques beaucoup plus subtiles et ciblées. Ici, nous proposons une attaque de type Deauth qui ne va cibler qu’un sous-ensemble des appareils connectés à un point d’accès. Plus particulièrement, cette attaque n’affectera que les appareils d’un fabricant particulier grâce à un ciblage via l’adresse MAC. En effet, la première partie d’une adresse MAC correspond à l’OUI (Organisation Unique Identifier) qui permet d’identifier le fabricant du chipset Wi-Fi qui correspond en général au fabricant de l’appareil. Par exemple, l’OUI 68:5a:cf correspond à Samsung Electronics Co., Ltd.

Puisque notre attaque ne doit pas affecter la totalité des appareils associés au point d’accès, il n’est plus possible d’utiliser une adresse destination broadcast. Il va donc nous falloir capturer des trames 802.11 pour découvrir les appareils connectés au point d’accès. Scapy permet de capturer les paquets reçus par une interface via la méthode sniff. En plus de l’interface réseau, il est possible de fournir une fonction qui devra être appliquée à chaque paquet. Dans notre cas, notre interface s’appelle interface et nous utilisons la fonction selectivedeauth qui sera détaillée par la suite. Notre appel prend alors la forme suivante :

Il reste maintenant à définir cette fonction selectivedeauth qui prend en paramètre une trame 802.11 t et envoie une trame Deauthentication à destination de sa source si certaines conditions sont remplies. Les conditions à remplir sont les suivantes :

• La trame correspond au BSSID du point d’accès ciblé : t.addr3 == bssid ;
• La trame est de type Data. Elle implique une station associée au point d’accès (les trames Data ne sont échangées qu’avec les stations associées) : t.type == 2 ;
• La trame n’est pas émise par le point d’accès : t.addr2 != bssid (elle est donc émise par une station) ;
• La trame est émise par un appareil dont l’adresse MAC correspond à l’OUI ciblé : t.addr2.startswith(targetoui).

Le début de notre fonction selectivedeauth ressemble alors à cela :

Une fois cette étape de filtrage effectuée, nous avons en notre possession une trame t émise par une station que nous souhaitons Deauthentifier. Il faut maintenant forger une trame de type deauth. Sous scapy, le forgeage d’une trame suit l’ordre d’encapsulation des différentes couches protocolaires. Nous créons donc une trame de la couche physique (RadioTap) qui contiendra une trame 802.11 (Dot11), elle-même contenant le corps de la trame Deauthentication (Dot11Deauth). Scapy se charge de renseigner les champs des trames par des valeurs par défaut, cependant il est possible (et souvent nécessaire) de spécifier certains champs. Ici il nous faut en particulier renseigner les champs différents champs adresse et BSSID de la trame 802.11 :

Notre trame est maintenant prête et peut être envoyée via la fonction sendp à qui on aura spécifié l’interface qui sera chargée de l’envoi :

Le script complet ressemble maintenant à cela :

Après avoir enregistré ce script dans un fichier selective_deauth_scapy.py, on peut alors l’exécuter de la manière suivante :

2. Protection contre les attaques Deauth (802.11w)

Nous venons de voir que les attaques par Deauth sont extrêmement efficaces et faciles à mettre en place. La faille exploitée par ces attaques par Deauth est l'absence de mécanisme de vérification des trames de type management qui permettrait d'identifier que la trame Deauth ne provient pas du point d'accès légitime. Heureusement, il existe un moyen de s'en protéger : l'extension  802.11w [1] du standard IEEE 802.11 [2].

2.1 L’extension 802.11w « Protected Management Frames »

Finalisée en 2009, suite à la mise en évidence des faiblesses du protocole original, l’extension 802.11w baptisée « Protected Management Frames » vise à ajouter un mécanisme de protection des trames de type management.

Plus précisément, cette extension propose l’ajout d’un code d’authentification aux trames de type management. Un code d’authentification repose sur l’utilisation d’une fonction cryptographique et d’une clef secrète. Étant donné un message et une clef, on calcule un code d’authentification que l’on adjoint au message. Ce code permettra au destinataire, également en possession de la clef, de vérifier l’authenticité du message en recalculant celui-ci et en le comparant à la valeur reçue. La confiance dans ce mode d’authentification vient de la difficulté qu’aurait un attaquant ne connaissant pas la clef à forger un code d’authentification valide. Dans le 802.11w, le calcul du code d’authentification repose sur une fonction éprouvée (AES-128 en mode CMAC) qui permet d’avoir un niveau de confiance élevé. Le principe du fonctionnement d’un code d’authentification est présenté sur la figure 3. En général, un code d’authentification est appelé MAC (Message Authentication Code), mais dans le cadre du standard 802.11, on lui préfère MIC (Message Integrity Code) pour éviter la confusion avec MAC (Medium Access Control).

Dans le cadre du 802.11, le message correspond à la trame au niveau MAC, et la clef utilisée est soit la clef de session PTK (dans le cas d’une trame unicast) soit la clef de session de groupe IGTK (dans le cas d’une trame multicast). Nous allons nous concentrer sur le premier cas puisque nous allons regarder le fonctionnement de la trame Deauthentication destinée à une seule station (unicast). Pour chaque trame, le code d’authentification est alors calculé à partir des données de la trame (entête et corps). Ce code d’authentification est ensuite ajouté à la fin de la trame. À la réception de la trame, le récepteur en possession de la clef, est en mesure de vérifier l’authenticité de la trame grâce au code d’authentification.

2.2 Activation du 801.11w sur OpenWRT/LEDE

Depuis sa publication officielle en 2009, l’extension 802.11w a progressivement été intégrée au sein des points d’accès et des clients Wi-Fi. En particulier, il a été intégré à hostapd et wpa_supplicant depuis leurs versions v0.7.0 (2009-11-21). La distribution OpenWRT/LEDE, spécialisée pour les routeurs Wi-Fi, n’est pas en reste et intègre maintenant cette fonctionnalité, et nous allons maintenant voir comment activer cette protection.

2.2.1 Activation via fichier de configuration

Il est possible activer le 802.11w via un fichier de configuration, il suffit d’ajouter une ligne dans le fichier /etc/config/wireless et d’y ajouter l’option ieee80211w suivit d’un paramètre numérique : 0 désactivé, 1 optionnel, 2 obligatoire.

La section correspondante du fichier /etc/config/wireless ressemble alors à cela :

Une fois ce fichier modifié, il suffit de redémarrer le point d'accès pour que celle-ci soit prise en compte :

Ou alors on peut tout simplement redémarrer notre routeur :

2.2.2 Activation via interface Web LuCI

La fonctionnalité du 802.11w peut également être activée via l’interface web LuCI d’OpenWRT/LEDE. Depuis la page de gestion du Wi-Fi (Network > WiFi), éditer les paramètres de l’interface Wi-Fi, et dans la section Interface configuration - Wireless security, passer l’option 802.11w Management Frame Protection à Optional ou Required comme indiqué sur la figure 4. Attention : pour pouvoir bénéficier de cette option, il faut :

1. avoir une version récente d’OpenWRT/LEDE avec la version full de wpad/hostapd (et non pas wpad-mini) ;
2. avoir une interface 802.11 et des drivers compatibles (pour le moment seuls sont supportés les ath9k, ath10k et aussi mwlwifi et mt76 dans LEDE).

2.3 Test des fonctionnalités 802.11w

Une fois l’option 802.11w activée sur le point d’accès, on peut commencer par constater que cette fonctionnalité est bien indiquée dans les trames beacons au sein du champ Capabilities de l’Information Element RSN (voir figure 5). On peut également observer que les trames deauth légitimes (voir figure 6) incluent maintenant deux éléments supplémentaires : un champ CCMP parameters qui indique que la partie data est chiffrée, et un corps de trame (Data) contenant 10 octets.

Ces 10 octets du corps de la trame correspondent en fait à deux éléments distincts. Les derniers 8 octets correspondent au code d’authentification de la trame tandis que les deux premiers contiennent la donnée chiffrée de la trame management (ici le reason code du deauth). En effet, en plus de l’authentification du message, le 802.11 peut également protéger la confidentialité des données contenues dans les trames management lorsque le mode de protection est CCMP. Ainsi une trame de management de type Deauth verra son reason code chiffré de la même manière que le corps d’une trame de type Data.

Avec le 802.11w activé sur le point d’accès et à condition que la station Wi-Fi supporte également le 802.11w, l’ensemble ne sera plus vulnérable aux attaques Deauth présentées précédemment. Nous l’avons vérifié avec un routeur LEDE (LEDE Reboot 17.01.4) équipé d’une interface compatible (TP-Link TL-WN722N avec driverath9k 4.4.92+2017-01-31-3) et un smartphone Galaxy A5 (Android 7.0) : les trames Deauth étaient totalement ignorées par notre appareil !

3. Brouillage radio

Une autre façon de faire du déni de service est de s’attaquer au medium de communication en mettant en place un brouillage radio. Cela consiste à émettre un signal radio sur la même fréquence que celle du signal que l’on cherche à brouiller. Si le signal ainsi généré par le brouilleur est suffisamment fort, il va perturber voire empêcher la bonne réception du signal légitime par le récepteur.

3.1 Approche frontale avec GNU Radio

Dans le cas du Wi-Fi, les signaux sont transmis sur un canal déterminé par le point d’accès. Par exemple, sur la bande des 2.4GHz, il existe 14 canaux, chacun d’une largeur de 20 MHz. Ainsi il est possible de brouiller les communications d’un point d’accès et de toutes les stations associées en générant un bruit de largeur 20MHz sur le canal correspondant. Un simple générateur de bruit peut permettre de créer un tel brouilleur. Par exemple, à l'aide du logiciel GNU Radio[3] et d'un USRP (carte électronique pour la radio logicielle) on peut émettre un bruit gaussien sur un canal de la bande des 2.4GHz. Pour cela, on utilise un simple bloc USRP Sink que l’on alimente avec un bloc Fast Noise Source tel que présenté sur le schéma GNU Radio Companion de la figure 7. La carte USRP va alors émettre un signal radio (correspondant à un bruit) de largeur 20MHz autour de la fréquence 2.412GHz (canal 1 du Wi-Fi). Le canal 1, ainsi que ses voisins proches, sera donc brouillé par ce signal.

En plus de reposer sur du matériel spécialisé et coûteux (1000 euros l’USRP), cette approche est très peu subtile et surtout très peu discrète. L’injection d’un bruit continu a toutes les chances d’attirer l’attention et d’être détecté. Comme nous allons le voir, il est possible de faire beaucoup mieux avec du matériel grand public en mettant en place un brouilleur réactif comme l’a fait Mathy Van Hoef avec son travail intitulé « Advanced Wi-Fi Attacks Using Commodity Hardware » [4]. Ce dernier a démontré qu’il est possible de modifier le firmware (code binaire chargé et exécuté par le microcontrôleur) de certaines cartes Wi-Fi pour brouiller certaines trames spécifiquement ciblées. C’est ce que nous allons voir par la suite.

3.2 Brouillage réactif

L’idée du brouillage réactif est de ne cibler que certaines trames, par exemple les trames émises par une station particulière. Le brouilleur réactif écoute les trames transmises sur le canal, et s'il détecte une trame à brouiller, il initie immédiatement l’émission d’un signal sur ce même canal. N’importe quel signal peut être utilisé pour le brouillage, et une trame Wi-Fi émise par une interface Wi-Fi peut très bien jouer ce rôle. C’est d’ailleurs ce que nous allons faire dans la suite. Lorsque deux trames Wi-Fi se superposent sur le canal, on obtient une collision. Au niveau du récepteur, cette collision peut avoir deux effets : soit les deux trames sont perdues, soit seule la trame avec le signal le plus fort est reçue. Ainsi, si notre trame arrive avec suffisamment de puissance à l’émetteur, la trame légitime sera écrasée et donc perdue pour le récepteur.

3.2.1 Implémentation sur une carte Wi-Fi

L’enjeu principal de l’implémentation d’un brouilleur réactif est de pouvoir réagir suffisamment rapidement pour brouiller une trame que l’on vient de détecter. Ainsi, il n’est pas envisageable d’implémenter cette attaque sur l’hôte, car les temps de transferts des données avec la carte Wi-Fi sont beaucoup trop longs.

La solution proposée par Mathy est d’implémenter ce mécanisme de brouillage réactif dans le firmware même du chipset de la carte Wi-Fi. Lors de la réception d’une trame 802.11, celle-ci est progressivement décodée et la donnée décodée est placée au fur et à mesure dans un tampon mémoire. Dans un mode de fonctionnement normal, le microcontrôleur de la carte attend que la trame soit décodée dans son ensemble avant de la transférer à l’hôte, mais dans le mode de fonctionnement proposé ici, le microcontrôleur analyse la trame à mesure que son décodage progresse à la recherche de certains critères de sélections. En particulier, parmi les premiers éléments décodés d’une trame, on trouve l’adresse MAC de l’émetteur qui se trouve être en quatrième position dans l’entête. Dans le cas où la trame satisfait à certains critères de sélections (par exemple, une adresse émetteur particulière), le microcontrôleur interrompt immédiatement la réception de la trame et initie l’émission d’une trame sur le même canal. Si le délai de réaction est suffisamment court, les deux trames vont partiellement se superposer sur le canal générant une collision (voir figure 8). Cette superposition pourra alors induire une perte de la trame ciblée.

Pour développer son brouilleur réactif, Mathy s’est basé sur le firmwareopen source ath9k et l’a modifié pour ajouter la fonctionnalité de brouillage réactif, ainsi que plusieurs autres attaques. Le code associé est disponible en ligne (https://github.com/vanhoefm/modwifi-ath9k-htc). Au sein de ce code, on peut trouver dans le fichier modwifi-ath9k-htc/target_firmware/wlan/attacks.c le corps de la fonction int attack_reactivejam(struct ath_softc_tgt *sc, unsigned char source[6], unsigned int msecs) qui est en charge du brouillage réactif. On peut y lire la partie du code traitant de la détection d’une adresse MAC émetteur et de l’émission d’une trame pour créer la collision :

Dans cette version, seules les trames de type Beacon (buff[0] == 0x80) et Probe Response (buff[0] == 0x50) sont affectées.

En plus du firmware, l’outil de reactive jamming est accompagné d’un utilitaire qui permet de communiquer par  ioctl()[5] des informations de l’hôte vers le microcontrôleur de l’interface, telles que le type d’attaque à enclencher et ses paramètres (par exemple, l'adresse MAC cible).

3.2.2 Test du brouillage réactif

Le code source ainsi que des packages prêts à l’utilisation sont disponibles en ligne à l'adresse suivante : https://github.com/vanhoefm/modwifi. Pour les plus fainéants d’entre nous, une image VMWare est également disponible à cette même URL. Une fois le driver, le firmware et les utilitaires installés, nous pouvons nous lancer dans une session de brouillage réactif.

Pour démarrer le brouillage réactif, il suffit de préparer l’interface (wlan1 dans notre cas) :

Puis de lancer la commande :

Où LEDE_wireless_network est le SSID du point d’accès que nous cherchons à brouiller. Le brouillage réactif est alors effectué jusqu’à ce que la commande reactivejam soit interrompue.

Pour vérifier l’effet de l’attaque, nous avons mis en place une petite expérience impliquant un point d’accès que l’on souhaite brouiller, une station d’observation et un attaquant. Comme indiqué précédemment, la version publiée ne permet que de brouiller les trames utilisées pour la découverte de service (Beacon et Probe Request), mais cette fonctionnalité est suffisante pour rendre inutilisable un point d’accès.

Pour vérifier l’effet de notre attaque, nous avons observé les trames émises pas le point d’accès à l’aide de l’interface Wi-Fi de la station d’observation. Après avoir placé cette interface en mode monitor, nous lançons une capture que nous analysons avec Wireshark. Après quelques secondes nous lançons l’attaque de brouillage réactif sur la machine de l’attaquant pendant environ 1 minute.

Ce que nous observons dans notre capture Wireshark (voir figure 9) est sans équivoque. On observe que la trame No 57 a été reçue presqu’une minute (59.9 secondes) après la trame 56, alors que les trames beacons sont habituellement transmises toutes les 100 ms environ. Cette période de silence correspond à l’activation de l’attaque par brouillage réactif : aucune trame en provenance du point d’accès ciblé n’a été reçue par notre station d’observation. Et pourtant si l’on observe les numéros de séquence des trames (SN pour Sequence Number) on voit bien qu’il nous manque 585 trames. Le point d’accès a donc bien continué d’émettre des beacons pendant cette période, mais l’attaque de brouillage réactif a empêché leur réception.

Conclusion

À la vue de la facilité de monter des attaques Deauth, l’adoption de mécanismes de protection de l’extension 802.11w est donc salutaire. Cependant, cette protection n’est pas sans faille. Si elle nous protège contre un attaquant extérieur, elle n’empêchera pas un attaquant interne qui est connecté au point d’accès de lancer une attaque Deauth. En effet, en étant connecté, il a connaissance des clefs nécessaires à la génération de codes d’authentification valides.

S'il existe des solutions contre les attaques logiques tels que le Deauth, il est beaucoup plus difficile de se protéger contre les attaques physiques de type brouillage. En effet, la seule parade semble être de s’assurer que la puissance du signal légitime reste supérieure à celle du signal de brouillage. D’autres standards de communications tels que le Bluetooth utilisent un mécanisme de channel hopping qui permet de compliquer la tâche d’un brouilleur en changeant régulièrement de canal. La faiblesse du Wi-Fi est d’utiliser une fréquence fixée qu’il est facile d’identifier et de brouiller.

Les appareils dédiés au brouillage sont normalement difficiles d’accès à cause de leur prix et de la règlementation limitant leur distribution. Nous avons pu voir qu’il était possible de mettre en place un brouillage perfectionné avec du matériel grand public et du logiciel librement accessible. De plus, l’aspect sélectif de ce brouilleur va le rendre extrêmement difficile à détecter.

Les scripts utilisés dans cet article sont disponibles en ligne : https://github.com/cunchem/GLM_HS_Secu_Wi-Fi_DoS.

Références

[1] K. GOPINATH et H. CHASKAR, « A Brief Tutorial on IEEE 802.11w », AirTight Networks, 2009 : https://www.slideshare.net/AirTightWIPS/80211w-is-ratified-so-what-does-it-mean-for-your-wlan

[2] IEEE Std 802.11-2012, 2012, p 76, 1232 à 1233.

[3]  G. GOAVEC-MEROU, J.-M. FRIEDT, « La réception radiofréquence définie par logiciel (Software Defined Radio – SDR) », GNU/Linux Magazine n°153, octobre 2012 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-153/La-reception-radiofrequence-definie-par-logiciel-Software-Defined-Radio-SDR

[4] M. VANHOEF et F. PIESSENS, « Advanced Wi-Fi Attacks Using Commodity Hardware », Proceedings of the 30th Annual Computer Security Applications Conference, 2014, p. 256 à 265.

[5] P. FICHEUX, « Les mystères de l'IOCTL() », GNU/Linux Magazine n°216, juin 2018, p. 64 à 71 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-216/Les-mysteres-de-l-ioctl