33c3 – Predicting and Abusing WPA2/802.11 Group Keys (Mathy Vanhoef)

Cet article est aussi disponible sur le CERT-Devoteam à l’adresse: CERT-Devoteam

Les attaques sur les communications WiFi ne sont pas nouvelles. Depuis des années, il existe des exploitations de vulnérabilités permettant d’obtenir les mots de passe des réseaux, d’injecter des paquets ou de déchiffrer les communications des utilisateurs d’un réseau WiFi. On peut notamment se rappeler les attaques contre le PRNG alimentant le chiffrement par flot du WEP, les attaques par bruteforce contre les handshakes, les attaques par faux point d’accès ou même l’attaque Tornado.

Toutes ses attaques se sont axées sur la divulgation du PSK ou la rupture de la confidentialité des échanges unicast. Le conférencier a choisi d’axer sa conférence sur les GroupKeys.

Les GroupKeys permettent d’échanger des messages en multicast. Il s’agit pour la plupart, de messages envoyés par le routeur à des fins d’informations. Cependant, il est possible également pour les clients d’envoyer des messages multicast. Pour cela, le point d’accès génère des clefs de groupes permettant d’échanger de manière chiffré.

Une GroupKey se sépare en un vecteur d’initialisation itératif (GNONCE) et un master secret (GMK) produit par le routeur au démarrage ou fixé en usine. À partir de ces éléments, le serveur génère une clef de session (GTK) en utilisant la fonction SHA(GNONCE+GMK). Cette clef de session est regénérée chaque heure (théoriquement) en incrémentant le vecteur d’initialisation. De ce fait, le secret de la clef de session repose sur le secret de du GMK et du GNONCE.

La génération de la GroupKey est spécifiée par le standard 802.11 au sein de l’annexe M5. Une implémentation PRNG est proposée à seul titre d’exemple. Cette implémentation pose de nombreux problèmes et soulève des interrogations. Par exemple, la définition de l’entropie est basée sur le trafic réseau ou si celui-ci est insuffisant, sur « assez d’aléa ». De plus, la seed initiale est basée sur une dérivation (PRF-256) de l’adresse MAC (possible à obtenir), le temps (pouvant fuir dans l’implémentation réseau et fixé à 0 en cas d’impossibilité d’obtenir le temps) et la seed aléatoire définie plutôt. Le pool d’entropie n’est pas utilisé plus tard pour régénérer l’état interne du PRNG.

Cette implémentation n’aurait pas dû être utilisée à des fins de productions et pourtant, le conférencier a comptabilisé plusieurs exemples d’implémentation directe de la norme. Cette implémentation se retrouve notamment dans les points d’accès Broadcom et Mediatek qui représente 22% du marché.

  • L’implémentation de Mediatek utilise les jiffies c’est-à-dire l’uptime de l’AP précis à la milliseconde comme source temporelle. Cette source temporelle est facile à obtenir au sein des beacons. Le GMK est produit au boot, c’est-à-dire pour un firmware donné, à un uptime prédictible, de même le GNONCE dépend de l’uptime au moment de génération de la GTK, celui-ci est accessible à travers les beacons. Le conférencier a implémenté une attaque basée sur l’obtention des beacons sur un AP dont le firmware est connu. L’attaque a été réalisée en live à la conférence et s’est exécutée sur un ordinateur standard en 3 minutes malgré l’environnement bruyant.
  • L’implémentation de Broadcom varie en fonction du système d’exploitation utilisé. Sur Linux par exemple, /dev/urandom est utilisé pour fournir le PRNG. S’il existe quelques vulnérabilités sur celui-ci, elles sont corrigées dans les versions les plus récentes du kernel. Cependant dans les systèmes VxWorks et eCos utilisés par les drones, les rovers et même les satellites, le PRNG génère sa sortie à partir du temps en microsecondes. Le GNONCE est également divulgué dans le processus de handshake. Seul le GMK doit être deviné. Basé sur un firmware WRT54Gv5, l’estimation du conférencier est de 4 minutes.
  • L’implémentation de OpenFirmware est particulière car celle-ci présente une faiblesse inexploitable. En effet, OpenFirmware est une implémentation de Bios Open Source. Celle-ci contient une implémentation WiFi cependant ne fonctionne pas en AP. La faiblesse repose dans l’utilisation de l’uptime depuis boot pour générer l’aléa.
  • L’implémentation de Hostapd est intéréssante car étant la plus sécurisé de toute. En effet, l’entropie du PRNG est effectivement mesurée et une entropie trop faible conduit automatiquement au refus des connexions entrantes. De plus chaque régénération de GroupKey apporte à nouveau de l’aléa.

Le conférencier a ensuite montré comment exploiter cette vulnérabilité pour émettre des messages unicast. En effet, les messages multicast peuvent empaqueter des messages unicast. Le routeur recevant un message multicast cherchera à réaliser le routage demandé vers le client suivant. De plus cette méthode permet également de contourner la méthode du Hole 196 qui nécessite d’être connecté à un point d’accès pour réaliser de l’ARP poisonning.

Le conférencier émet quelques recommandations d’implémentation pour éviter ce type d’attaque:

  • Vérifier le niveau d’entropie du PRNG
  • L’AP devrait refuser les messages de broadcast et à plus forte raison ne pas les forwarder
  • Balayer le bruit ambiant pour générer une source d’aléa

Le conférencier a également illustré une autre attaque basée sur la faiblesse de l’échange cryptographique.

  1. Le client reçoit les suites cryptographiques depuis l’AP.
  2. Le client choisit une suite cryptographique et l’envoie
  3. Le serveur envoie un nonce
  4. Le client répond avec un nonce et génère la session key
  5. Le serveur génère la session key et envoie le GTK et les suites cryptographiques disponibles (comme envoyé en 1)
  6. Le client vérifie les suites cryptographiques comparés au 1 et envoie un ACK

Si un attaquant modifie les suites cryptographiques en 1. La connexion ne sera réinitialisée qu’après transmission du GTK. Si la suite cryptographique choisie est suffisamment faible, il sera possible de déchiffrer la communication. C’est le cas de la suite cryptographique RC4. La faiblesse de cette suite est reconnue aujourd’hui car le PRNG utilisé pour le chiffrement par flot souffre d’un biais statistique.

Le conférencier émet quelques recommandations d’implémentation pour éviter ce type d’attaque:

  • désactiver RC4 et WPA-TKIP
  • envoyer le GTK après la validation du handshake
Facebooktwitterlinkedin
Pierre d'Huy
Pierre d'Huy est un ingénieur spécialisé dans la sécurité des Systèmes d'Information. Il donne occasionnellement des conférences en école (ESE, ESGI Secure Day...) ou devant des publics non-techniques (Les matinées du droits Lamy, l'AFCDP). Amateur de cryptographie et de cartographie, il propose des articles sur de nombreux sujets qui le passionnent.

Leave a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *