Des vulnérabilités ont été découvertes dans les paquets ouverts IWD (Intel inet Wireless Daemon) et wpa_supplicant, utilisés pour connecter des systèmes Linux clients à un réseau sans fil, permettant de contourner les mécanismes d'authentification :
- Dans IWD, la vulnérabilité (CVE-2023-52161) se manifeste uniquement lorsque le fonctionnement est activé en mode point d'accès, ce qui est atypique pour IWD, qui est généralement utilisé pour la connexion à des réseaux sans fil. La vulnérabilité permet de se connecter au point d'accès créé sans connaître le mot de passe, par exemple lorsque l'utilisateur donne explicitement la possibilité d'accéder au réseau via son appareil (Hotspot). Le problème a été résolu dans la version IWD 2.14.
La vulnérabilité est due à un manque de vérification appropriée de l'ordre des étapes lors du processus d'accord en 4 étapes, utilisé lors de la première connexion à un réseau sans fil protégé. Étant donné qu'IWD accepte des messages à toutes les étapes de l'accord de connexion sans vérifier si l'étape précédente a été franchie, un attaquant peut, en contournant l'envoi du message de la deuxième étape, envoyer directement le message de la quatrième étape et accéder au réseau, sautant l'étape où la vérification de l'authentification est effectuée.
En attendant, IWD essaie de vérifier le code MIC (Message Integrity Code) pour le message de la quatrième étape reçu. Comme le message de la deuxième étape avec les paramètres d'authentification n'a pas été reçu, lors du traitement du message de la quatrième étape, la clé PTK (Pairwise Transient Key) est définie à une valeur nulle. Par conséquent, l'attaquant peut calculer le MIC en utilisant un PTK nul, et ce code de vérification sera accepté par IWD comme valide. Après avoir terminé un tel accord de connexion incomplet, l'attaquant obtiendra un accès complet au réseau sans fil, car le point d'accès acceptera les trames envoyées par celui-ci, chiffrées avec une clé PTK nulle.
- Le problème identifié dans wpa_supplicant (CVE-2023-52160) permet à un attaquant d'induire en erreur un utilisateur pour qu'il se connecte à un réseau sans fil fictif, agissant comme un clone du réseau auquel l'utilisateur souhaite se connecter. En cas de connexion de l'utilisateur au réseau piégé, l'attaquant peut intercepter le trafic transit non chiffré de l'utilisateur (par exemple, les visites de sites sans HTTPS).
En raison d'un défaut dans la mise en œuvre du protocole PEAP (Protected Extensible Authentication Protocol), un attaquant peut contourner la deuxième phase de l'authentification lors de la connexion d'un appareil utilisateur mal configuré. Le contournement de la deuxième phase de l'authentification permet à l'attaquant de créer un clone trompeur d'un réseau Wi-Fi de confiance et de connecter l'utilisateur à un réseau fictif sans vérification de mot de passe.
Pour qu'une attaque réussisse, la vérification côté utilisateur dans wpa_supplicant doit être désactivée. certificat TLS Le serveur, et l'attaquant doit connaître l'identifiant du réseau sans fil (SSID, Service Set Identifier). De plus, l'attaquant doit se trouver à portée de l'adaptateur sans fil de la victime, mais en dehors de la portée du point d'accès du réseau sans fil cloné. L'attaque est possible sur des réseaux WPA2-Enterprise ou WPA3-Enterprise utilisant le protocole PEAP.
Les développeurs de wpa_supplicant ont déclaré qu'ils ne considéraient pas le problème comme une vulnérabilité, car il ne se manifeste que dans des réseaux sans fil mal configurés où l'authentification EAP est utilisée avec le protocole PEAP (EAP-TTLS) sans vérification du certificat TLS. de serveursLes configurations sans vérification de certificat n'offrent pas de protection contre des attaques actives. Ceux ayant découvert la vulnérabilité affirment que de telles configurations incorrectes sont typiques et largement répandues, ce qui met en danger de nombreux appareils grand public basés sur Linux, Android et Chrome OS utilisant wpa_supplicant.
Pour résoudre le problème dans wpa_supplicant, un correctif a été publié, ajoutant un mode obligatoire pour passer par la deuxième phase d'authentification, en plus de la vérification du certificat TLS. Selon les développeurs, la modification proposée n'est qu'un contournement, rendant plus difficile la réalisation d'attaques lors de l'utilisation d'une authentification manuelle et sans utilité lors de l'utilisation d'options telles que EAP-GTC. Pour résoudre véritablement le problème, les administrateurs réseau doivent ajuster la configuration de manière appropriée, c'est-à-dire établir une chaîne de confiance pour vérifier le certificat du serveur à l'aide du paramètre ca_cert.
Source : opennet.ru
