Wi-Fi Advanced Fuzzing - Ensiwiki

Corentin DELPECH
Lucas FONTAINE
ENSIMAG 2A TELECOM
Mardi 13 Mars 2012
ENSIMAG - 4MMSR Network Security - Seminar
Wi-Fi Advanced Fuzzing
Laurent BUTTI
BlackHat Europe Conference 2007
Sommaire
1. Introduction, connaissances basiques Wi-Fi
a. Historique, les différentes normes, usages
b. Spécificités techniques
i. Modes de mise en réseau Wi-Fi
ii. Les trames WiFi
2. La sécurité des réseaux Wi-Fi
a. Quels enjeux ?
b. Quels moyens de test ?
3. Le ‘fuzzing’
a. Qu’est-ce que le fuzzing ?
b. Implémentation d’un fuzzer
4. Les vulnérabilités découvertes, cas concrets
5. Limitations des fuzzers, limitations des vulnérabilités, contre-mesures
6. Démonstration
7. Résumé, notions abordées, conclusion
8. Pour aller plus loin : présentation de Laurent Butti, anecdote
9. Annexe : références
Timing (17 minutes présentations + 3 minutes questions) :
[1 ; 2] : 4 minutes
[3 ; 6] : 10 minutes
[7 ; 9] : 3 minutes
Légende :
* Ce fond est relié directement au contenu du papier de recherche
* Responsables parties : Corentin / Lucas
=
17 minutes
1.Introduction, connaissances basiques Wi-Fi
a. Historique, les différentes normes, usages
Le terme “Wi-Fi” est apparu en 1999 et désigne un ensemble de protocole de communication
sans-fil régis par les normes du groupe IEEE 802.11.
Historique
Une seule norme était présente à l’origine et proposait un débit de 1 à 2 Mbps. Ce n’est
qu’après que sont apparues les différentes révisions de la norme, amenant à une augmentation
sensible du débit, mais supportant également de nouveaux critères de sécurité, de types de
connexions, et d’interopérabilité.
Les differentes normes
Citons rapidement entre autres les normes de connexion “connues” telles que le 802.11g et
802.11n présents sur les box des FAI actuels.
D’autres normes plus “originales” telles que le 802.11s permettent de créer un réseau maillée
type “mesh” avec des connexions ad-hoc dynamiques entres les usagers (n’importe quelle noeud est
récepteur et émetteur dans le réseau, dynamiquement, à différencier de l’architecture client <-> point
d’accès habituelle utilisée).
Les usages
Aéroports, hotels, dans nos foyers, en entreprise, le Wi-Fi est partout et utilisé par un nombre
de plus en plus conséquent de personnes via leurs laptop, téléphones mobiles, consoles de jeux,
tablettes, TV, appareils photos, frigo, chaines Hi-Fi, etc... ! A très court terme, le Wi-Fi servira de
délestage aux réseaux mobiles, telles que Free l’implémente sur son réseau mobile grace à ses
Freebox et le protocole EAP-SIM.
=> Le but ici n’était donc pas d’être exhaustif mais d’insister sur le fait que le “Wi-Fi” designe un
ensemble de normes riches en spécifications, entraînant une complexité potentiellement néfaste dans
le code des drivers qui supportent ces normes alors que ceux-ci sont de plus en plus présents dans
nos appareils !
b. Spécificités techniques, assumed background
b.1 Modes de mise en réseau Wi-Fi
Une carte WiFi peut passer entre plusieurs modes :
● le mode moniteur : la carte WiFi écoute passivement le trafic réseaux
: la carte WiFi agit comme un point d’acces
● le mode master
: la carte WiFi agit comme une station Adhoc (client connecté les
● le mode AdHoc
un aux autres sans point d’acces )
Il existe deux manière de découvrir un point d'accès pour une carte wifi : Soit elle
fait un scan actif du réseaux. C’est a dire qu’elle envoie des “probe requests” et attends les
réponses “probe responses”. Soit elle écoute passivement les informations que les autres
stations/points d’accès envoient périodiquement sur le réseaux. (les beacons)
Son comportement se décompose en trois états :
■ non authentifié, non associé
■ authentifié, non associé
■ authentifié, associé
Pour comprendre comment la carte wifi passe entre ces trois etats, il faut étudier ses trames.
b.2 Les trames WiFi
figure 1 : Architecture des trames WiFi :
Il existe plusieurs types de trames WiFi :
● les paquets de données
● les paquets de gestion
● les paquets de contrôles a station
Les paquets de gestions servent a gérer la connexion entre deux stations. Des
exemples de ce type de paquet : Authentification , desauthentification, association,
réassociation, ect...
Il existe trois classes de trames WiFi :
● Les trames de classe 1 : Les sondes, les Beacons, les trames d’authentification et de
desauthentification.
● Les trames de classe 2 : Les trames d’association, de désassociation.
● Les trames de classe 3 : Les trames de desauthentification.
Les liens entre les etats de la carte WiFi et se trames sont donc expliqués par cette machine a
états :
Figure 2 :
Machine a états d’un client WiFi
2. La sécurité des réseaux Wi-Fi
a. Quels enjeux ?
Laurent Butti a vu dans le Wi-Fi des enjeux en termes de sécurité tels que :
(coté point d’accès/infrastructure)
● Infrastructure réseau Wi-Fi friables (WEP, WPA mal utilisé/configuré -> cryptage WEP
cassé, WPA compromis)
● Infrastructure réseau avec points d’accès illégitimes ou mal configurés
(coté clients)
● Connexions à des points d’accès illégitimes dans les zones publiques (et si je créais un
faux points d’accès “wifi-campus” avec mon ordinateur hein ?!)
● De faux points d’accès attaquant les clients (automatiquement !)
● L’injection de trafic dans les communications clients, l’exploitation des systèmes clients
Le problème, comme le souligne Laurent Butti, est que tout cela est difficilement détectable car
complètement transparent sans des outils spécifiques (Wireless IDS...).
De plus, les drivers sont potentiellement l’objet de moins d’audit que les kernels, alors que
l’exploitation d’un drivers 802.11 pourrait permettre à n’importe qui dans la couverture réseau
d’une carte Wi-Fi cible de procéder à des exploitations ring0 ! Pretty big !
Il faut donc s’assurer en amont de l’utilisateur que les pilotes en charges des points d’accès
et autres cartes réseaux Wi-Fi “clients” soient sécurisés et se comportent correctement en
cas “d’anomalies” (et/ou en présence d’une attaque).
b. Quels moyens de test ?
- Avec des drivers “closed source”, comme c’est le cas en général, les tests se font en “boite
noire” (pas d’accès au code source du drivers) et par “reverse engineering”. Mais ce dernier
procédé est peu efficace (penible, couteux en temps, résultats mitigés)
- Avec des drivers open source (+ rare), on peut faire des tests en “boite blanche” (et ainsi
suivre quelle portion du code est sollicitée), et de l’audit de code source. Mais même dans ce
cas, il peut être utile de faire des tests en black box pour commencer.
- Un procedé, utilisé par M. Butti, est... (next part !)
3. Le fuzzing
a. Qu’est-ce que le fuzzing ?
Le ‘fuzzing’ est le nom donné à une méthode qui s’appuie sur des logiciels (les fuzzers) afin
d’automatiser la recherche de bugs ou de failles de sécurités dans des applications (Microsoft
en utilise pour tester son naviguateur Web Internet Explorer par exemple) ou encore, et c’est
là qu’on rejoint notre sujet, des protocoles, exemple : le Wi-Fi !
Basiquement, le ‘fuzzing’ consiste à tester toutes les entrées possibles, de toutes les manières
possibles, par l’injection de codes volontairement mal formés (+ ou - complètement aléatoires),
et à forcer certaines opérations en cas de réactions anormales, telle que l'exécution de codes
malveillants, etc...
Implémenter un fuzzer nécessite les bonnes connaissances, comme nous allons tout de suite le
voir, et bénéficie d’un des meilleurs rapports qualité/prix (résultat/temps)
b. Implémentation d’un fuzzer
La première étape pour Laurent Butti a été d’implémenter un fuzzer pour l’état 1. Le mode
moniteur (depuis le PC attaquant) est suffisant pour fuzzer cet état.
Comme expliqué par Corentin précèdemment, on peut trouver à l’état 1 des trames de
management. Un des champs de ces trames est le “Information Element”, de la forme très
simple :
- Type (un ID d’un octet)
- Longueur (longueur totale de la charge utile ‘Valeur’ sur un octet)
- Valeur (la charge utile du Information Element, de 0 à 255 octets).
Or, la norme 802.11 prevoit une longueur fixe ou maximale pour certains types d’Information
Element. On imagine bien alors les erreurs de programmations possibles, et on sent dès lors
tout l’intérêt de fuzzer l’Information Element :
• A la reception d’un IE, le drivers attribue un buffer statique d’une longueur fixe prédéfinie
(en fonction de ce qui est décrit dans la norme ou de façon arbitraire)
• Il lit sur la trame 802.11 le champ « length »
• Puis il copie le contenu de « value » dans le buffer statique
• Si (length > taille statique du buffer), alors on déborde sur la pile ou le tas
L’équipe de Laurent a selectionné une batterie de test
- En fonction de “l’état de l’art” des vulnérabilités découvertes
- En fonction des Information Element les plus importants (IE 0 : SSID (0 - 32 octets), IE 3 :
Channel (fixé 1 octet), etc ...)
- En fonction des bordures à tester {0, 1, MIN-1, MIN, MIN+1, MAX-1, MAX, MAX+1, 254, 255}
C’est bien beau tout cela, mais concrètement, comment s’y prendre pour tester ?! /!\
Laurent B. et son équipe ont employé la recette de cuisine suivante :
- Pré-calculer un ensemble d’Information Element à tester et à renvoyer à un client Wi-Fi cible
- Attendre de recevoir un “probe request” d’un client Wi-Fi avec un SSID “Null” sur le broadcast
(= active scanning du client Wi-Fi à la recherche de points d’accès !)
- Renvoyer un “probe response” approprié avec l’Information Element à tester à la victime
Difficultés !
- Certains Information Element proprietaires (802.11g turbo, apparu avant la ratification de
la 802.11n, etc... ) sont utilisées par les constructeurs et sont peu/mal documentés, difficile à
analyser / tester !
- Comme le client Wi-Fi scan activement le medium avec des probe request, il envoie ses
trames sur l’ensemble des channels Wi-Fi, un par un (= channel hopping). Il faut donc répondre
très rapidement à son “probe request” avant que celui-ci n’ai déjà changé de channel !
-> Très dur avec une implémentation du fuzzer en Python, encore + avec Scapy
- Difficile de savoir si le “probe response” renvoyé a été analysé par le client Wi-Fi fuzzé
-> Comment savoir alors si le drivers n’ai pas sensible à notre attaque ou s’il n’a juste pas lu le
paquet ?
- Comment detecter un bug de comportement sur les différents systèmes d’exploitation ?!
Solutions !
- Pour que le parser soit efficace, envoyer des données aléatoirement ne suffit pas, il faut être
plus intelligent. Exemple, avec un chiffrement WPA, il faut que le début de la trame soit valide
pour être acceptée par le parser WPA (WPA IE + WPA OUI + WPA TYPE + WPA VERSION).
- Flooder le medium radio avec des beacons sur le broadcast et des probe response sur une
victime en particulier, en permanence (ne pas attendre de probe request sinon on a pas le
temps de répondre, on “anticipe” en quelque sorte)
- Detection automatique de bug /!\ :
- Sous Windows BSOD et ne répond plus au ping
(il suffit de pinger sur Ethernet, arreter quand le ping ne répond plus)
- Sous Linux, on surveille les messages kernels {oops|unable to handle|assert|panic}
- La carte Wi-Fi peut devenir non fonctionnelle après un test : si la carte était en “active
scanning”, on détecte un bug quand celle-ci n’envoie plus de “probe request”
- Implémenter des fuzzers spécifiques à certains IE proprietaires, certaines implémentations
(WPA, RSN, WSP)
Un petit plus …
Développement par l’équipe de Laurent B de leur propre fuzzer (fuzzers et framework existants
non adaptés), test de plusieurs IE malformés dans la même trame, test avec des trames
tronquées ou vides.
4. Les vulnérabilités découvertes, cas concrets
●
NetGear MA521 Wireless Driver Long Rates Overflow
○ Utilisation d’une trame avec un IE “Rates” trop long
(longueur maximale de 8 octets normalement)
●
NetGear WG311v1 Wireless Driver Long SSID Overflow
○ Utilisation d’une trame avec un IE “SSID” trop long
(longueur maximale de 32 octets normalement)
●
D-Link DWL-G650+ (A1) Wireless Driver Long TIM Overflow
○ Utilisation d’une trame avec un IE “TIM” trop long
●
Madwifi Driver Remote Buffer Overflow Vulnerability
○ Utilisateur d’une trame avec IE WPA/RSN/VMM/ATH trop long
○ Exploitable uniquement lors d’un appel à SIOCGIWSCAN du client
■ Commande ‘iwlist’ par exemple
Cas concret : la faille MadWifi (= une trame WiFi 802.11 -> execution
de code arbitraire à distance en mode ring0 sous Linux !!!)
●
●
●
●
●
Trame Wi-Fi avec un IE WPA dont les champs OUI, TYPES et VERSION sont bien
formatés (necessité d’un “fuzzer” + intelligent avec connaissance du WPA qu’un simple
fuzzer “basique” totalement random, sinon le parser WPA rejette la trame)
Autres champs fuzzés -> oops du kernel Linux !
On observe : plusieurs registres sont impactés, dont le registre EIP (= offset de la
prochaine instruction a executer !) et EBP (= offset du sommet de la pile)
Le but du jeu avec le registre EIP = faire pointer la prochaine execution vers du code
injecté dans la trame vérolée.
L'exécution de code arbitraire a distance est réalisée
Analyse du bug exploité dans Madwifi (code source disponible)
● Allons voir dans le fichier ‘net80211/ieee80211_scan.c’ du code source,
fonction ‘giwscan_cb()’
● Dans les noyaux recents compilés, le wireless extension est supérieur à 14, on passe
dans le “if” -> un buffer de 64*2+30 = 158 octets est bien alloué
●
Un peu plus loin, on regarde où ce buffer est utilisé. Deux possibilités :
○ IWEVGENIE est utilisé (dans la plupart des noyaux recemment compilé c’est
le cas). On passe dans le “if”. BINGO. Vulnérabilité dans le ‘memcpy’, la taille
maximale de ‘se->se_wpa_ie[1] n’est jamais verifié ici ni ailleurs, nous avons un
debordement de pile !
○ IWEVGENIE n’est pas utilisé, la fonction encode_ie est alors appelé avec des
paramètres de taille du buffer incriminé non vérifié, allons voir ce le code de cette
fonction pour une possible seconde faille.
■ C’est la variable “ielen” et le pointeur “p” qui sont ici maitrisés par
l’attaquant.
■ La fonction ‘sprintf’ permet alors de réaliser un débordement de pile en
convertissant le contenu de l’IE en ASCII dans “buf”.
L’exploitation a proprement parlé (condensat)
L’Information Element verolé se retrouve en pile noyau (avec “buf”). La taille de celui-ci est,
rapellons-le, de 158 octets. Seuls les 6 premiers octets ne sont pas utilisables (car ce sont les
octets des champs OUI, TYPE et VERSION qui doivent être parsés correctement). Il reste donc
152 octets de shellcode : à nous les portes du code exécutable malveillant !
5. Limitations des fuzzers, limitations des
vulnérabilités, contre-mesures
Les limitations dans la recherche de vulnérabilité des fuzzers sont :
● Comprehension du protocole par le développeur (les normes Wi-Fi sont
nombreuses et complexes !)
● Le fuzzer n’est efficace que pour trouver les bugs les plus faciles d’accès
La complexité de la norme 802.11 entraîne des limitations lors de
l’implémentation du fuzzer. Par exemple un fuzzer ne trouvera pas de bugs
complexe due au fait que les test qu’il effectue sont simples et que son
implémentation ne doit pas devenir un casse tête (on perd en efficacité)
● Le fuzzer doit gérer des états, des synchronisations avec les points d'accès
Ce qui peut être dur pour gérer les test a fournir. Le fuzzer doit monter lui même
d’un état à un autre, complexité des ACKs à renvoyer, ...
● Paquets pas forcement analysés
Il n’est pas sur que les paquets envoyé soient analysés par le driver : ceci peut
entraîner des “false negatives” :
● La rapidité du fuzzer doit être à la hauteur client
Les echanges de trames de données doivent se faire assez rapidement pour
qu’elle soient prise en compte par la carte Wi-Fi cliente.
● En cas de découverte d’un bug par le fuzzer, encore faut-il pouvoir
l’identifier
● Cas de bugs n’entrainant pas le crash du systeme ( bug non critique )
exemple ( fuite d’information ) u il est possible de faire lire au driver des zones
memoires contigues au paquet 802.11 stock´e en m´emoire du processus, cependant,
comme ces zones memoires sont lisibles et generalement accessibles, cela n’entraine
pas de dysfonctionnement critique.
Les limitations dans l’exploitation de vulnérabilités sont :
● La gestion du système cible
La carte Wi-Fi cible peut tomber, on peut ne pas maitriser correctement l’injection
de l’exploit suivant le système d’exploitation visé, …
stack overflow -. pour les cibles generiques
en se specifiant a une cible on peut laisser la pile intacte, et ainsi executer du
code
Les contres mesures applicables faces a ces vulnérabilités :
● La faille a déjà été découverte et un package a été réalisé ! (ex : Madwifi )
-> patchez !
parfois effectué de maniere silencieuse d’une version d’un systeme d’exploitation a
un autre.
6. Démonstration
Objectif
Fuzzing du Information Element SSID et BSSID dans des beacons Wi-Fi
Plateforme attaquante :
●
●
●
●
Nettop Packard Bell Imax Mini C2600
OS : Backtrack 5 “Revolution” Rev. 4
Metasploit 3.8 + Lorcon2
Metasploit commands :
○ msfconsole # lancement de la console du framework Metasploit
○ use auxiliary/dos/wifi/fakeap # on indique quel module utilisé
○ set 3000000 # configuration du paramètre du module pour l’envoi de 3 millions
de fausses annonces point accès
○ exploit # lancement de l’exploit
Plateforme cible :
●
●
Tout device muni d’un chipset Wi-Fi pouvant scanner les points d’accès de manière
passive en écoutant les beacons sur le medium
Participation active de l’audience : “allez consulter la liste des points d’accès Wi-Fi que
vous detectez sur votre ordinateur / tablette / smartphone !”
Resultat attendu :
●
Sur MacBook Air 3,2 et Mac OS X 10.6.8, avec logiciel de scan Wi-Fi ‘KisMac’ (v. 0.3.3),
le scan des points d’accès alentours indique une pléthore de points d’accès dont les
champs SSID et BSSID sont totalement aléatoires.
●
Indeterminé sur autres devices
(un quelconque comportement inattendu dans l’audience ?! ;))
7. Résumé, notions abordées, conclusion
les points importants de cette conférence sont :
L’arrivée de la norme 802.11 entraine beaucoup de problématique de sécurité : attaques sur
des infrastructure réseaux friables, attaques de client a partir de faux points d’acces .
Le Fuzzing a une meilleur rentabilité dans la découverte de vulnérabilité par rapport aux autres
methode de test(ex: reverse engineering).
Pour tester la carte reseaux sans fils il s’appuie sur :
● ses etats
● les information portée par les trames wifi
Il permet des découvrir les failles les plus basiques pour les drivers Wi-Fi : il reste quand même
possible de découvrir des bugs plus complexe pour peu que son developeur ait une forte
connaissance du protocole 802.11.
Le fuzzing nous permet de trouver des bugs critiques.
Cependant le “WiFi” n’en est que a ses débuts :
● Il restes des bugs complexe a trouver.
● D’autre extentions de la norme 802.11 vont arriver et leurs fonctionalités ne seront pas
testées.
● D’autre support a connexions sans fils vont arriver : WUSB, bluetooth 3.0 …
● Access Point fuzzing ! (cf references)
8.Pour aller plus loin : présentation de Laurent BUTTI,
anecdote
Ce sujet est le fruit d’une recherche de Laurent Butti :
C’est un chercheur travaillant pour Orange spécialisé dans la sécurité réseaux. Il effectue aussi
des conférences pour présenter ses travaux sur la sécurité WI-FI.
Son travail sur le fuzzing lui a permis de découvrir de nombreuse failles, notamment une sur le
driver madwifi .
Il a prévenu l’équipe Madwifi et attendu sa mise a jours avant de l’annoncer publiquement, vu la
criticité de cette faille. Les developpeurs ont reagis rapidement et un patch etait implémenté le
lendemain pour corriger le bug.
Il faut préciser que malgrés leur annonces, les failles découvertes ne sont pas forcement
corrigé par les developeurs.
C’est une anecdote pour annoncer deux points sur Laurent BUTTI :
● Sa méthode du fuzzing est efficace ;
● C’est quelqu’un de consciencieux car il l’utilise que a bon escient (cela peut
sembler ‘normal’ mais il a attendu la correction de la faille avant de la dévoiler par
exemple)
9. Annexe : réfèrences
Document plus récent de Laurent Butti sur le Wifi Fuzzing + Access Point Wifi Fuzzing
(transmis Fabien D.) https://www.cr0.org/paper/hacklu2007-final.pdf
Article détaillé sur le Wifi Fuzzing de Laurent Butti :
https://www.sstic.org/media/SSTIC2007/SSTIC-actes/
Recherche_de_vulnerabilites_dans_les_drivers_par_t/SSTIC2007-ArticleRecherche_de_vulnerabilites_dans_les_drivers_par_techniques_de_fuzzing-tinnes_butti.pdf
Introduction :
http://fr.wikipedia.org/wiki/Wi-Fi
La sécurité des réseaux Wi-Fi :
(Laurent Butti & Julien Tinnes pour le SSTIC 2007) http://actes.sstic.org/SSTIC07/
WiFi_Fuzzing/SSTIC07-Butti_Tinnes-WiFi_Fuzzing.pdf
Démonstration - Module exploité du framework Metasploit
http://www.metasploit.com/modules/auxiliary/dos/wifi/fakeap
Vocabulaire
WSP
Abbréviation de “Wireless Session Protocol”, une couche “Session” pour
l’architecture WAP
Réponses à d’éventuelles questions
- Commencer forcer une carte Wi-Fi victime à analyser nos frames corrompues avec des IE ?
Il faut forcer la carte à scanner activement à la recherche de points d’accès. Sous
Windows, avec Netstumbler, sous Linux en utilisant la commande “iwlist”, avec mon Mac
j’ai utilisé KisMAC. Pour être sur que la frame malveillante a été analysée par le drivers,
il suffit de voir la liste des points d’accès rafraichie dans Netstumbler, KisMAC ou avec la
commande “iwconfig”.
- Depuis quel materiel est-il possible de mener ces attaques par Wi-Fi fuzzing ?
Le chipset Atheros et son driver Open Source madwifi sous Linux sont reputes pour etre
tres flexibles au niveau de la creation des trames 802.11. En e et, le fuzzing
impose le changement de champs specifiques des trames 802.11 qui peuvent dans
certains cas etre geres directement par le firmware. Si tel etait le cas, alors les tests
seraient fauss´es du fait de la non maiıtrise de certains champs 802.11. Les limitations
possibles `a cause du firmware du chipset sont generalement au niveau de :
– la valeur du numero de sequence des trames,
– la valeur du BSS Timestamp dans les trames beacon et probe response,
– la valeur du duration id des trames,
– la capacite a envoyer des trames fragmentees,
– la capacite a envoyer des trames de controle.
Le chipset Atheros supporte toutes les fonctionnalites precedentes sauf l’usurpation
du numero de sequence des trames qui n’est pas supporte en standard dans le driver
madwifi. Il est possible de patcher le driver pour supporter cette fonctionnalite, mais elle
impose alors d’avoir le champ (( retry )) positionne a 1 pour toutes les trames injectees,
ce qui est genant si l’attaquant veut se cacher de logiciels de d´etection d’intrusion
802.11 evolues.