Des routeurs Linksys Velop envoient les mots de passe Wi‑Fi en clair vers des serveurs américains
(stackdiary.com)- L’association belge de consommateurs Testaankoop indique que les routeurs maillés Linksys Velop Pro 6E et Velop Pro 7 transmettent les identifiants Wi‑Fi en clair à des serveurs AWS aux États-Unis
- Lors d’un contrôle d’installation, les paquets transmis contenaient le SSID et le mot de passe configurés, un jeton d’identification du réseau et un jeton d’accès pour la session utilisateur
- Les tests ont été réalisés avec le dernier firmware disponible à ce moment-là ; Linksys a publié une mise à jour du firmware après un avertissement en novembre 2023, mais le problème n’a pas été résolu
- Les utilisateurs concernés peuvent empêcher l’envoi de texte lisible en modifiant le nom et le mot de passe du réseau Wi‑Fi via l’interface web plutôt que l’application
- Testaankoop déconseille fortement l’achat de ces modèles ; comme la gamme Velop est aussi recommandée pour de petits bureaux, cela suscite des inquiétudes à la fois pour les environnements personnels et professionnels
Modèles Velop pour lesquels l’envoi en clair a été confirmé
- Testaankoop, l’association belge de consommateurs, a confirmé que deux routeurs Linksys transmettent les identifiants Wi‑Fi en clair à des serveurs AWS d’Amazon
- Les modèles concernés sont les routeurs maillés Linksys Velop Pro 6E et Velop Pro 7
- Lors d’un contrôle d’installation de routine, plusieurs paquets de données envoyés vers des serveurs AWS aux États-Unis ont été détectés
- Les paquets contenaient en clair le nom du SSID configuré et le mot de passe
- Ils incluaient également un jeton permettant d’identifier le réseau au sein d’une base de données plus large
- Un jeton d’accès pour la session utilisateur était aussi transmis
- Ce mode de transmission peut accroître le risque d’attaque de type homme du milieu (MITM)
- Si un attaquant intercepte les communications entre le routeur Linksys et le serveur Amazon, il peut capturer le SSID et le mot de passe envoyés en clair
- Il existe alors un risque de lire ou modifier le nom du réseau et le mot de passe, et d’obtenir un accès non autorisé au réseau
État du firmware et mesures recommandées aux utilisateurs
- Testaankoop a effectué ses tests avec le dernier firmware disponible au moment de l’évaluation
- Le Velop 6E a été testé à plusieurs reprises, le dernier test ayant été mené avec le firmware
V 1.0.8 MX6200_1.0.8.215731 - Le nouveau Velop Pro 7 a été testé avec le firmware
1.0.10.215314
- Le Velop 6E a été testé à plusieurs reprises, le dernier test ayant été mené avec le firmware
- Linksys a publié une mise à jour du firmware après le premier avertissement de novembre 2023, mais les préoccupations soulevées par Testaankoop n’ont pas été résolues
- Le problème de sécurité pourrait provenir d’un logiciel tiers utilisé dans le firmware Linksys, mais Testaankoop estime que cela ne justifie pas la vulnérabilité
- Il est recommandé aux utilisateurs qui possèdent déjà ces routeurs de modifier le nom et le mot de passe du réseau Wi‑Fi via l’interface web plutôt que par l’application
- Cette mesure est une précaution visant à empêcher l’envoi du nom du SSID et du mot de passe sous forme de texte lisible
Réponse de Linksys et recommandation d’achat
- Testaankoop a de nouveau contacté Linksys quelques jours avant la publication afin de lui donner une brève possibilité de répondre, mais n’a reçu ni confirmation ni solution de la part du fabricant
- Stack Diary a également demandé à Linksys, le 9 juillet, quelles mesures étaient prévues, et n’avait reçu aucune réponse au 14 juillet
- Après de longs tests, Testaankoop conclut qu’il déconseille fortement l’achat des Linksys Velop Pro WiFi 6E et Pro 7, estimant que les risques d’intrusion réseau et de perte de données sont sérieux
- Les routeurs maillés comme la série Velop sont conçus pour améliorer la distribution du Wi‑Fi dans les grandes habitations ou les maisons à plusieurs étages grâce à plusieurs nœuds connectés, mais le mode de transmission des données des Velop Pro WiFi 6E et Pro 7 affaiblit les avantages de sécurité qu’ils devraient offrir
2 commentaires
Une excuse avancée serait que cela permettrait au support d’aider les utilisateurs ayant oublié leur mot de passe
Avis sur Hacker News
En lisant ces commentaires, tout le monde considère donc que l’envoi du mot de passe au serveur est acceptable, et que seul le fait qu’il ne soit pas chiffré pose problème ?
Je ne m’attends pas du tout à ce que le mot de passe soit envoyé à un serveur au départ.
Un routeur qui fait cela n’est pas adapté à son usage, et pour être honnête je ne considérais déjà plus les routeurs Linksys comme des produits globalement corrects depuis plusieurs années.
Du texte en clair se remarque facilement et les gens peuvent s’en apercevoir, ce qui crée un impact médiatique, tandis qu’un mot de passe chiffré est pratiquement impossible à tracer.
Via le mécanisme TR-69, les routeurs Verizon FiOS envoient le mot de passe WiFi local à un système de gestion centralisé.
L’excuse que j’ai entendue était : « permettre au support d’aider les utilisateurs qui ont oublié leur mot de passe » :-/
Au passage, si l’application du fournisseur permet de changer le mot de passe de l’équipement fourni, il y a de fortes chances que ce mot de passe circule en clair, au moins à l’intérieur de paquets TCP/TLS.
Je suis content d’avoir pris depuis longtemps l’habitude de ne pas utiliser les routeurs fournis par les opérateurs.
Il suffisait ensuite de se connecter au routeur et de définir un nouveau mot de passe.
Si j’étais fournisseur d’accès à Internet et que je recevais trop de demandes de support liées aux mots de passe WiFi, j’envisagerais plutôt de pousser davantage l’usage de WPS.
Je déteste vraiment la façon dont l’industrie des routeurs est passée d’équipements réseau locaux fiables à des appareils intelligents.
On y voit les mêmes pratiques d’exploitation des clients que dans d’autres secteurs. Par exemple, TP Link utilise des dark patterns dans ses routeurs comme des entreprises telles que Roku, et après avoir mis à jour ses conditions d’utilisation, force l’utilisateur à les accepter dans une fenêtre pop-up pour pouvoir utiliser l’application.
L’application est le seul moyen d’accéder à la plupart des fonctions de configuration du routeur, contrairement à l’ancienne méthode qui consistait à ouvrir une page web protégée par mot de passe. Si vous n’acceptez pas les nouvelles conditions, vous ne pouvez plus contrôler un routeur que vous contrôliez jusque-là.
En plus, dans l’application, ils poussent constamment des essais de services inutiles et non désirés avec des incitations comme des badges rouges ronds à côté d’éléments de menu ou d’interface utilisateur.
Je ne serais pas surpris que, comme chez Linksys, les conditions leur permettent d’abuser de mes données personnelles et de ma sécurité.
Mais vers qui se tourner ? Toutes les entreprises font ça. Peut-être qu’elles ne peuvent même pas survivre sans cela. C’est pourquoi une régulation semble nécessaire, notamment sur la responsabilité en cas de faille de sécurité et les limites aux abus des conditions d’utilisation.
Est-ce réellement du texte en clair, ou du texte en clair à l’intérieur de HTTPS ? L’article et les sources originales ne le disent pas.
Qu’un mot de passe soit « en clair » dans une requête HTTPS est assez courant. Presque toutes les connexions à des applications web fonctionnent ainsi.
Si ce n’est pas du HTTPS, alors il y a tout un tas d’autres problèmes en plus de mettre un mot de passe en clair dans la requête.
Si c’est du HTTPS, le vrai problème est que le mot de passe ne reste pas en local et est envoyé quelque part. Cette pratique est beaucoup plus discutable, mais malheureusement beaucoup de routeurs le font couramment pour prendre en charge des fonctions de gestion cloud/appli.
Les seules raisons qui me viennent à l’esprit sont de configurer de façon plus « automatique » un second appareil pour un réseau mesh, ou de conserver le même mot de passe après une réinitialisation d’usine. Dans les deux cas, il existe de meilleures solutions.
S’il s’agit de définir un nouveau mot de passe, je ne vois pas pourquoi l’ancien serait nécessaire ; et si le mot de passe WiFi sert d’identifiant d’accès à l’administration distante, c’est mauvais, car l’accès à mon réseau ne devrait pas équivaloir à des droits d’administration.
Si c’est réellement nécessaire, on pourrait faire bien mieux, par exemple en envoyant uniquement un mot de passe correctement salé et haché.
S’ils avaient eu accès à la clé privée du certificat du serveur Linksys, cela aurait été une nouvelle bien plus importante.
Je suis impressionné qu’un organisme de tests consommateurs ait eu suffisamment d’expertise technique pour découvrir ça.
C’était un problème impossible à découvrir en utilisant le produit comme le ferait un consommateur ; il fallait chercher activement des bugs de sécurité pour s’en apercevoir.
Ce serait vraiment bien que les fabricants de routeurs WiFi utilisent OpenWRT
S’ils le souhaitent, ils peuvent l’habiller avec un skin comme gli.net, et au minimum s’appuyer sur OpenWRT comme base. C’est ouvert et ça fonctionne bien
Ils peuvent continuer à différencier leurs produits en ajoutant davantage d’antennes et en additionnant tous les chiffres de débit pour les faire paraître vraiment rapides
https://www.gl-inet.com/support/firmware-versions/
https://github.com/gl-inet/openwrt
Et il est aussi simple d’installer un OpenWRT vanilla via la méthode sysupgrade d’OpenWRT
https://openwrt.org/toh/gl.inet/gl-mt6000#installation
C’était facile à configurer, les performances étaient bonnes, il y avait aussi quelques fonctions avancées, et il a reçu des mises à jour de sécurité pendant des années
Il y a environ deux ans, quand la Fritz!Box d’un collègue de bureau et la mienne sont tombées en panne, on a ressorti un vieil AirPort Extreme : non seulement il fonctionnait encore très bien, mais il restait aussi assez compétitif comme routeur 802.11ac
Je suis assez geek pour avoir fabriqué moi-même un routeur sous OpnSense il y a quelques années, et ça marchait vraiment très bien
La seule raison pour laquelle j’ai arrêté, c’est qu’il y avait un problème impossible à contourner entre BSD et une carte Broadcom 10Gbe précise ; au final, j’ai bricolé temporairement quelque chose avec ClearOS, puis je suis ensuite passé à NixOS
Il n’y a pas vraiment de raison que ce soit impossible
Donc acheter du GLI.NET ne garantit pas d’obtenir du matériel faisant tourner un « vrai OpenWrt »
Il faut toujours vérifier la liste de compatibilité matérielle ou, mieux et de façon plus actuelle, consulter la liste des fichiers DTS dans le git master actuel d’OpenWrt
Ce problème ne se limite pas à la gamme Velop
Pendant que je remplaçais le firmware d’un EA7500 par openWRT, j’ai vu exactement les mêmes informations être transmises alors qu’il me forçait à me connecter au portail web mylinksys et tentait d’établir une connexion avec le serveur maison
« Malgré un avertissement envoyé à Linksys en novembre, aucune mesure efficace n’a été prise »
Novembre ? Novembre, vraiment ? Certes, il y a pas mal de jours fériés à cette période
Mais si le fournisseur ne travaille pas activement dessus ou ne communique pas, à mon avis ce genre de chose aurait dû être rendu public au plus tard fin janvier
C’est honteux. Ne pas répondre pendant des mois relève d’un comportement activement malveillant, et c’est toute l’entreprise qui devrait être sanctionnée en conséquence, pas un simple développeur jetable sur qui rejeter la faute
J’aimerais qu’Apple revienne dans le secteur des routeurs WiFi
En matière de confidentialité et de sécurité, je fais davantage confiance à Apple qu’à la plupart des autres marques
Malheureusement, Apple vend des routeurs Linksys comme remplaçants de ses anciens produits
Les gens veulent posséder leur propre matériel
Le bootloader et le code source de tous les périphériques embarqués doivent être ouverts
Le code source du firmware doit être fourni pour tous les NPU, moteurs d’offloading et autres composants présents sur le chemin de données Ethernet
Le noyau Linux mainline doit permettre un démarrage entièrement sans blob, à l’exception du WiFi/RF
Il doit être possible d’activer l’accès TrustZone via un jumper, et l’utilisateur final doit disposer d’une gestion complète des clés
Ce serait bien qu’un header de port série UART soit monté à l’intérieur
Mais je doute qu’Apple soit assez favorable aux utilisateurs pour fabriquer un appareil sur lequel on puisse installer facilement OpenWrt cinq minutes après l’avoir sorti de sa boîte. En plus, ils le vendraient probablement très cher