Cisco Wi-Fi, rescue me : mitiger et détecter les attaques WPA / WPA2
Nous avons précédemment publié un article expliquant les vulnérabilités découvertes pour les protocoles Wi-Fi WPA, WPA2 et 802.11r.
La seule vulnérabilité pour les bornes Wi-Fi étant déjà fixée en désactivant le 802.11r ou en mettant à jour le code de l’infrastructure Wi-Fi, dans cet article nous allons nous concentrer sur les options pour mitiger les vulnérabilités affectant les clients Wi-Fi également.
Avant de démarrer, nous vous invitons à (re)lire l’article susmentionné pour tout détail sur la nature de ces vulnérabilités. Il y a 10 vulnérabilités au total : 9 affectant les terminaux Wi-Fi et une seule vulnérabilité affectant les bornes Wi-Fi (ou Access Points, APs).
La seule vulnérabilité affectant les APs exploite le standard 802.11r : en désactivant le support du 802.11r pour les réseaux Wi-Fi concernés ou en appliquant une des versions intégrant le correctif, cette vulnérabilité peut être neutralisée.
Certaines des autres 9 vulnérabilités affectant les terminaux Wi-Fi se basent sur la retransmission au moins une fois des messages EAPoL pour la dérivation des clés de chiffrement PTK (Pairwise Transient Key) et GTK (Group Temporal Key), ou la rotation de ces clés. En empêchant la retransmission des messages EAPoL on neutralise la possibilité de lancer des attaques exploitant certaines vulnérabilités (plus précisément, les 5 vulnérabilités avec les références de CVE-2017-13077 à CVE-2017-13081).
Le contrôleur Wi-Fi Cisco (WLC, Wireless LAN Controller) supporte des options pour refuser la retransmission des messages EAPoL, en bloquant de cette manière certaines attaques KRACK (Key Reinstallation Attack) qui exploitent ces vulnérabilités WPA / WPA2 sur les terminaux Wi-Fi.
Refuser les retransmissions des messages EAPoL pourrait d’un autre côté affecter des terminaux moins évolués, ou parfois des téléphones Wi-Fi aussi, qui ne répondraient par exemple pas assez rapidement au tout premier message EAPoL M1 après une authentification 802.1X en déclenchant ainsi sa retransmission (désactivée, et qui causerait donc la déconnexion du terminal). Dans ce cas, une mesure parallèle serait d’augmenter le timeout d’attente de la réponse des terminaux de la part du WLC, en évitant de déclarer trop tôt un terminal comme non répondant aux messages EAPoL, mais tout en gardant les retransmissions de ces messages désactivées.
Avant la version AireOS 7.6 du WLC la désactivation des retransmissions des messages EAPoL et l’augmentation du timeout étaient des réglages globaux pour tous les réseaux Wi-Fi :
config advanced eap eapol-key-retries 0
config advanced eap eapol-key-timeout 1000
(un timeout de 1000 millisecondes est souvent considéré déjà suffisant, mais cette valeur pourrait varier selon les besoins spécifiques à chaque déploiement)
A partir de la version AireOS 7.6 du WLC la désactivation des retransmissions des messages EAPoL et l’augmentation du timeout sont supportées SSID par SSID :
config wlan security eap-params enable <WLAN id>
config wlan security eap-params eapol-key-retries 0 <WLAN id>
config wlan security eap-params eapol-key-timeout 1000 <WLAN id>
(une désactivation du WLAN est requise avant, avec la commande config wlan disable <WLAN id>, puis une réactivation du WLAN sera nécessaire à la fin avec config wlan enable <WLAN id>)
Il faut bien évidemment être conscient des conséquences potentielles évoquées ci-dessus pour certains terminaux Wi-Fi, mais ces commandes pourraient déjà bloquer certaines attaques.
Une autre option, pas forcément pour bloquer les attaques, mais au moins pour les découvrir, est de configurer des politiques de détection des APs pirates dans le WLC :
- Vérifiez que les APs supportent l’option pour la détection des APs pirates (option activée par défaut, mais qui aurait pu être désactivée pour certains déploiements).
- Configurez au moins une règle pour classifier en tant que “Malicious” tout AP pirate qui essaierait de desservir un des réseaux Wi-Fi déjà gérés par le WLC.
- Vérifiez que la détection des APs pirates, à la fois pour la bande des 2.4 GHz et des 5 GHz, soit appliquée à tous les canaux Wi-Fi.
En plus que la classification d’un AP pirate par interface graphique, le WLC pourra également générer une trap SNMP (vers Cisco Prime Infrastructure ou tout autre outil de monitorage) avec un message similaire au suivant :
Impersonation of AP with Base Radio MAC de:ad:be:ef:de:ad using source address of de:ad:be:ef:de:ad has been detected…
Ce message n’est pas spécifique à une attaque KRACK uniquement, mais pourrait être déjà un premier indicateur à regarder de plus près.
Plus de détails sur la configuration des politiques de détection des APs pirates sont disponibles dans nos guides officiels :
- Cisco Wireless LAN Controller Configuration Best Practices
- Rogue Management in a Unified Wireless Network using v7.4
Tags:
