Je vais passer au Wi-Fi filaire, ça sera plus simple !

Les points d’accès Wi-Fi proposent souvent la possibilité de créer plusieurs réseaux pour séparer les utilisateurs et gérer les accès. Problème, des chercheurs montrent que cette isolation peut facilement voler en éclats, via trois méthodes. Ils ont testé 11 routeurs, 11 étaient vulnérables. Certains auraient corrigé le tir, d’autres ne le pourraient pas.

Lors du Network and Distributed System Security (NDSS) Symposium qui se tient du 23 au 27 février à San Diego, des chercheurs de l’université de Californie à Riverside et de la Katholieke Universiteit de Louvain (Belgique) ont présenté leurs travaux baptisés « AirSnitch : démystifier et briser l’isolement des clients dans les réseaux Wi-Fi ». Un papier technique a aussi été mis en ligne (.pdf).

Attention, on parle bien ici de l’isolation des utilisateurs sur un même point d’accès, pas de casser le chiffrement du Wi-Fi. Si le WEP est depuis longtemps obsolète, WPA2 AES (pas en version TKIP, cassé avec KRACK) et WPA3 tiennent encore. Rien ne change avec AirSnitch, les chercheurs ne s’attaquent absolument pas au chiffrement des données, qui reste intact.

• Chiffrement et sécurité dans tous leurs états, du WEP à la distribution quantique de clés

Wi-Fi invité : faites comme chez vous… heu wait !!

Pour être mises en œuvre, les attaques décrites dans leur papier nécessitent que l’utilisateur puisse se connecter à la borne Wi-Fi, que ce soit sur le même SSID ou un autre, du moment que le point d’accès est le même. Mais c’est aussi plus large, suivant les configurations.

Les chercheurs ajoutent en effet que des attaques sont également possibles entre plusieurs points d’accès, « mais aussi réalisables dans les réseaux d’entreprise et de campus où plusieurs points d’accès sont connectés sur un même réseau filaire ». Une solution pour limiter les dégâts est de mettre en place des VLAN, à condition de bien le faire évidemment.

Pour le grand public et certaines petites entreprises, les risques peuvent donc être importants si vous avez, par exemple, un réseau « invité » largement accessible.

Des protections sont en théorie en place depuis longtemps : « Pour empêcher les clients Wi-Fi malveillants d’attaquer d’autres clients sur le même réseau, les fournisseurs ont introduit l’isolation des clients, une combinaison de mécanismes bloquant la communication directe entre les clients. Cependant, l’isolation des clients n’est pas une fonctionnalité standardisée, ce qui rend ses garanties de sécurité incertaines », expliquent les chercheurs en guise d’introduction.

AirSnitch : trois vecteurs d’attaques

Ils ont identifié trois principaux vecteurs permettant de casser l’isolation. La première vient « des clés Wi-Fi protégeant les trames de diffusion qui sont mal gérées et peuvent être détournées ». Il s’agit des clés GTK (Group Temporal Key) qui sont les mêmes pour tous les clients sur un même réseau.

Autre faiblesse : « l’isolation est souvent appliquée uniquement au niveau MAC ou IP, mais rarement aux deux ». Enfin, la dernière est la conséquence d’une « faible synchronisation de l’identité d’un client à travers toute la pile réseau », permettant d’usurper son identité sur la partie la plus faible du réseau pour ensuite la garder et capter le trafic.

Les chercheurs détaillent les risques qu’ils ont identifiés. Un attaquant pourrait accéder aux paquets IP, ce qui pourrait faciliter certaines attaques car « aujourd’hui encore, 6 % et 20 % des pages chargées sous Windows et Linux, respectivement, n’utilisent pas HTTPS […] Nos attaques permettent également l’interception de sites web ou de services intranet locaux, plus susceptibles d’utiliser des connexions en clair ». Et même si HTTPS est utilisé (les données ne sont pas déchiffrées via les attaques), « les adresses IP utilisées sont toujours révélées, ce qui est souvent suffisant pour savoir quel site web est visité ».

Comme un « attaquant peut intercepter et exploiter tout trafic en clair de la victime […], il peut intercepter le trafic DNS et empoisonner le cache DNS du système d’exploitation de la victime. Il peut également modifier l’enregistrement DHCP et changer l’adresse de la passerelle et le serveur DNS utilisés par la victime. Ces attaques peuvent avoir un impact durable sur la victime, même après que l’attaquant a cessé d’être un intermédiaire ».

Netgear, D-Link, TP-Link, Ubiquiti… plus d’une dizaine de routeurs vulnérables

Onze routeurs ont été testés et tous ont été vulnérables à au moins une des attaques : Netgear Nighthawk X6 R8000, Tenda RX2 Pro, D-Link DIR-3040, TP-Link Archer AXE75, ASUS RT-AX57, DD-WRT v3.0-r44715, OpenWrt 24.10, Ubiquiti AmpliFi Alien Router, Ubiquiti AmpliFi Router HD, LANCOM LX-6500 et Cisco Catalyst 9130. Pour ceux qui voudraient tenter eux-mêmes l’expérience (et qui ont du matériel compatible), du code est disponible dans ce dépôt GitHub.

Les chercheurs détaillent une attaque de bout en bout sur un routeur Netgear R8000. Il est configuré avec quatre SSID, deux invités et deux de « confiance », chacun sur les 2,4 et 5 GHz. Le routeur est connecté à Internet via un câble réseau.

L’attaquant est sur le réseau invité et veut lancer une attaque de type « homme du milieu » (MitM), afin d’intercepter tout le trafic montant et descendant d’une victime sur le réseau de « confiance ». « L’attaquant commence donc par se connecter au SSID invité avec l’adresse MAC de la victime, mais sur une fréquence différente afin d’éviter toute déconnexion ». On vous épargne la partie technique (page 10 de ce document .pdf) pour arriver à la conclusion.

Les techniques mises en place « amènent le point d’accès à rediriger le trafic descendant de la victime vers le SSID invité. L’attaquant renvoie ensuite le trafic intercepté à la victime grâce à la technique de rebond de passerelle. De même, il intercepte le trafic montant en usurpant l’adresse MAC du point d’accès (c’est-à-dire le routeur passerelle) et le renvoie au serveur de la victime. L’attaque complète dure environ deux secondes. Pendant toute la durée de l’attaque, la victime regarde une vidéo YouTube en streaming sans subir de latence significative ».

Ars Technica s’est entretenu avec le premier chercheur de la publication, Xin’an Zhou. Nos confrères ont glané quelques informations sur les réactions des constructeurs de bornes et points d’accès : « Zhou a indiqué que certains fabricants de routeurs avaient déjà publié des mises à jour atténuant certaines attaques, et que d’autres étaient attendues. Il a toutefois précisé que certains fabricants lui avaient confié que certaines failles systémiques ne pouvaient être corrigées qu’en modifiant les puces sous-jacentes qu’ils achètent auprès des fabricants de semi-conducteurs ». Nos confrères n’entrent pas davantage dans les détails.

À la fin de leur publication, les chercheurs affirment avoir « signalé les vulnérabilités aux fournisseurs concernés, ainsi qu’à la Wi-Fi Alliance. La Wi-Fi Alliance a pris acte de leurs conclusions et ils attendent sa décision ».

Prudence sur les Wi-Fi publics et invités… comme toujours

Côté utilisateur, pas grand-chose à faire si ce n’est faire preuve de prudence. Il faut déjà se méfier des points d’accès publics, mais donc aussi de ceux plus confidentiels. Éviter aussi de donner accès à un Wi-Fi invité à n’importe qui (on espère que vous n‘avez pas attendu cette actualité…).

Une autre solution, les VPN : « Une partie de la menace peut être atténuée en utilisant des VPN, mais cette solution présente tous les inconvénients habituels. D’une part, les VPN sont réputés pour la fuite de métadonnées, des requêtes DNS et d’autres trafics utiles aux attaquants, ce qui limite la protection. Et d’autre part, trouver un fournisseur VPN réputé et digne de confiance s’est avéré historiquement difficile, même si la situation s’est améliorée récemment. En fin de compte, un VPN ne devrait pas être considéré comme plus qu’un simple pansement », explique Ars Technica.

Il n’est pas forcément nécessaire de passer par un tiers, si vous avez une Freebox avec Freebox OS, elle peut faire office de serveur VPN Wireguard, vous permettant ainsi d’utiliser votre connexion Internet en déplacement, de manière sécurisée. Vous pouvez également utiliser un VPS pour y installer un serveur VPN, nous aurons prochainement l’occasion d’en reparler. Surtout, soyez prudent face aux petits et gros mensonges des vendeurs de VPN.

• [Édito] Au pays des VPN menteurs…
• Le protocole VPN Wireguard disponible sur Freebox : comment ça marche ?

Comme le rapporte Videocardz, suite à la mise en ligne des pilotes 595.59 WHQL par NVIDIA, plusieurs utilisateurs remontent des soucis au niveau de la gestion des ventilateurs, principalement sur les cartes GeForce RTX 50 : « Les utilisateurs affirment que certains ventilateurs cessent de répondre, que les courbes personnalisées des ventilateurs sont ignorées, ou qu’un seul capteur apparaît dans des outils comme HWiNFO, GPU-Z et les utilitaires des fabricants », expliquent nos confrères.

Ce n’est pas tout. D’autres utilisateurs pointent du doigt « une baisse du boost après la mise à jour. Les utilisateurs rapportent des fréquences de pointe plus faibles et suggèrent que le pilote limite la tension GPU à environ 0,95 V », avec pour conséquence de limiter la fréquence sur certaines cartes. Les retours sont nombreux sur les forums de NVIDIA.

Dans la foulée de la mise en ligne, NVIDIA a retiré les pilotes et demande à ses utilisateurs qui rencontrent des soucis d’effectuer un retour en arrière sur la précédente version, comme indiqué dans une mise à jour des notes de version : « Nous avons découvert un bug dans les pilotes WHQL Game Ready et Studio 595.59 et avons temporairement supprimé les téléchargements pendant que notre équipe enquête. Pour les utilisateurs qui ont déjà installé ce pilote et rencontrent des problèmes de contrôle des ventilateurs, veuillez revenir à 591,86 WHQL ».

Les notes de version des 595.59 renvoient désormais vers une page vide.

Deux semaines après la mise en ligne de la première version bêta d’Android 17, Google remet le couvert. Plusieurs nouveautés sont mises en avant. Pour la partie interface et expérience utilisateurs, les « bulles » arrivent. Cette fonctionnalité, distincte de l’API des bulles de messagerie (arrivée avec Android 11), permet de passer une application en mode fenêtre.

« Les utilisateurs peuvent créer une bulle d’application sur leur téléphone, leur appareil pliable ou leur tablette en maintenant longuement enfoncée une icône d’application dans le lanceur ». Un exemple ci-dessous avec l’Agenda.

Le billet de blog associé propose plusieurs animations présentant le fonctionnement des nouvelles fonctionnalités. Pour les développeurs d’applications, de la documentation est disponible ici.

Passons ensuite à EyeDropper. C’est une API au niveau du système qui « permet à votre application de demander la couleur de n’importe quel pixel de l’écran sans nécessiter d’autorisations sensibles pour capturer l’écran ».

Plusieurs autres petits changements sont apportés sous le capot, notamment pour le sélecteur de contacts qui permet d’accorder des autorisations temporaires (au niveau de la session) en lecture aux seuls champs de données demandés par l’utilisateur, une meilleure prise en charge des pavés tactiles, etc.

Pour la connectivité inter-appareils, Google annonce « une nouvelle API Handoff permettant de spécifier l’état de l’application à reprendre sur un autre appareil, comme une tablette Android ». Sur la partie Ultra Wide Band, « UWB DL-TDOA qui permet aux applications d’utiliser UWB pour la navigation intérieure ».

Côté Wi-Fi, la fonctionnalité Proximity Detection de la Wi-Fi Alliance est prise en charge. « Cette technologie offre une fiabilité et une précision accrues par rapport aux spécifications de portée existantes basées sur le Wi-Fi Aware », qui permet aux appareils compatibles de communiquer directement entre eux.

Google continue de viser un rythme annuel pour la sortie majeure de son SDK (chaque deuxième trimestre), accompagné d’une mise à jour au quatrième trimestre. L’entreprise est confiante dans le calendrier : « Nous allons rapidement passer de cette bêta à notre jalon Platform Stability prévu pour mars », c’est le moment où les API seront figées pour permettre aux développeurs de s’adapter.

La compatibilité des smartphones est la même que précédemment : les Pixel de Google à partir des versions 6. Tous les détails se trouvent sur ce site dédié à Android 17.