En plus de ce canal d'échange point à point sécurisé, WPA crée un canal de diffusion générale utilisé pour les paquets envoyés à une adresse broadcast ou multicast. Attention, ce canal est unidirectionnel : AP vers STA. Les STA qui doivent envoyer un message broadcast doivent donc l'envoyer à l'AP en unicast, par le canal bidirectionnel.
Ce canal est intrinsèquement moins protégé que les canaux bidirectionnels privés parce que le jeu de clefs (maîtresse, chiffrement, intégrité) est (nécessairement!) partagé par tout le WLAN, donc n'importe quel acteur pourrait utiliser cette connaissance pour communiquer directement avec un autre.
(suite au prochain épisode...)
tout a fait cela a d'ailleurs été démontré (attaque Hole196) lors d'une defcon
on peut, en tant qu'utilisateurs authentifié d'un réseau WPA, récupérer la clé de groupe (GTK), et s'en servir pour créer des requêtes multicast malveillante en se faisant passer pour l'AP, de façon totalement intraçable (minus quelques IDS sophistiqué capable de deviner l'origine physique probable par triangularisation, mais il suffit de se déplacer pour les rendre inoffensif), puisque dans l'air
à partir de là, on peut exécuter toutes la batterie d'attaque habituelle sur le multicast, en premier lieu, un arp poisoning pour exécuter un MITM (bien entendu, on ne redirige pas la victime sur le pc utilisé pour attaquer(sinon on serait repérable, puis-qu’authentifié), mais sur un serveur externe)
Cela reste très sophistiqué, personne ne semble l'avoir vu utilisé dans une attaque (d'un autre coté... c'est intraçable), mais possible
en plus, quand on voit le niveau de la NSA point de vue administration, on se dit que personne ne prendra les précaution nécessaire pour s'en prévenir
à noter que la GTK change de façon régulière (sans plus de précision de la part de la norme, et on peut constater que tout les vendeurs n'ont pas la même notion de régularité), ainsi qu'à chaque fois qu'un client rejoins ou quitte le réseau de l'AP (cela serait intéressant de voir le traffic que cela génère dans un grand réseau)
cela veut dire qu'on ne peut bien sur pas récupérer la GTK, puis quitter le réseau et la réutiliser après, l'attaque doit se faire rapidement avant que la clé ne se renouvelle pour les diverses raison cités
pour l'exploiter, le plus dur c'est de récupérer la fameuse GTK
pour cela, il faut potasser
http://wireless.kernel.org/en/developers/Documentation/mac80211 afin d'écrire une librairie c capable de communiquer avec la carte réseau (pourvu qu'elle le supporte) et de retrouver les informations de l'AP avec lequel on est connecté, qu'on pourra appeler depuis un script python
petit point à noter, la plupart des carte réseau peuvent fonctionner en mode chiffrement software ou hardware (calculs déportés sur la carte réseau)
c'est pour le mode hardware qu'on a besoin de la librairie qui communique avec la carte
en théorie, en mode software, la GTK est stockée quelque part pour que l'OS la retrouve, mais je n'ai jamais retrouvé comment (si quelqu'un y arrive, qu'il me fasse signe)
une fois la GTK retrouvée, elle peut servir a chiffré n'importe quoi, dans notre cas des paquet 802.11, qu'on peut crafter à l'aide de scapy (automatiser les requêtes ARP qui vont bien est ensuite un jeu d'enfant)
Protocoles réseaux sécurisés (https)