- Die belgische Verbraucherschutzorganisation Testaankoop erklärte, dass die Mesh-Router Linksys Velop Pro 6E und Velop Pro 7 Wi‑Fi-Anmeldedaten im Klartext an AWS-Server in den USA übertragen
- In den bei einer Installationsprüfung übertragenen Paketen waren die konfigurierte SSID und das Passwort, ein Token zur Netzwerkidentifikation sowie ein Access Token für Benutzersitzungen enthalten
- Der Test wurde mit der damals aktuellen Firmware durchgeführt, und obwohl Linksys nach einer Warnung im November 2023 ein Firmware-Update veröffentlichte, wurde das Problem nicht behoben
- Betroffene Nutzer können die Übertragung als lesbaren Text verhindern, indem sie den Wi‑Fi-Netzwerknamen und das Passwort statt über die App über die Weboberfläche ändern
- Testaankoop riet deutlich vom Kauf der betreffenden Modelle ab; da die Velop-Reihe auch für kleine Büros empfohlen wird, bestehen Bedenken sowohl für private als auch geschäftliche Umgebungen
Velop-Modelle mit bestätigter Klartext-Übertragung
- Testaankoop, die belgische Verbraucherschutzorganisation, bestätigte, dass zwei Linksys-Routertypen Wi‑Fi-Anmeldedaten im Klartext an Amazon-AWS-Server übertragen
- Betroffen sind die Mesh-Router Linksys Velop Pro 6E und Velop Pro 7
- Bei routinemäßigen Installationsprüfungen wurde festgestellt, dass mehrere Datenpakete an AWS-Server in den USA gesendet wurden
- Die Pakete enthielten den konfigurierten SSID-Namen und das Passwort im Klartext
- Ebenfalls enthalten war ein Token zur Identifikation des Netzwerks innerhalb einer größeren Datenbank
- Auch ein Access Token für Benutzersitzungen wurde mitgesendet
- Diese Art der Übertragung kann die Möglichkeit von Man-in-the-Middle-Angriffen (MITM) erhöhen
- Wenn ein Angreifer die Kommunikation zwischen einem Linksys-Router und den Amazon-Servern abfängt, kann er die im Klartext übertragenen SSIDs und Passwörter erfassen
- Dadurch entsteht das Risiko, Netzwerknamen und Passwörter auszulesen oder zu ändern und sich unbefugt Zugang zum Netzwerk zu verschaffen
Firmware-Status und Reaktion der Nutzer
- Testaankoop führte die Prüfung mit der zum Testzeitpunkt verfügbaren aktuellen Firmware durch
- Der Velop 6E wurde mehrfach getestet; der letzte Test erfolgte mit der Firmware
V 1.0.8 MX6200_1.0.8.215731 - Der neue Velop Pro 7 wurde mit der Firmware
1.0.10.215314getestet
- Der Velop 6E wurde mehrfach getestet; der letzte Test erfolgte mit der Firmware
- Linksys veröffentlichte nach der ersten Warnung im November 2023 zwar ein Firmware-Update, die von Testaankoop geäußerten Bedenken wurden jedoch nicht ausgeräumt
- Das Sicherheitsproblem könnte aus in der Linksys-Firmware verwendeter Drittanbieter-Software stammen, doch Testaankoop sieht darin keine Rechtfertigung für die Schwachstelle
- Nutzern, die diese Router bereits besitzen, wird empfohlen, den Wi‑Fi-Netzwerknamen und das Passwort über die Weboberfläche statt über die App zu ändern
- Diese Maßnahme dient als Vorsichtsmaßnahme, um zu verhindern, dass SSID-Name und Passwort als lesbarer Text übertragen werden
Reaktion von Linksys und Kaufempfehlung
- Testaankoop kontaktierte Linksys einige Tage vor der Veröffentlichung erneut und gab dem Unternehmen kurz Gelegenheit zur Stellungnahme, erhielt vom Hersteller jedoch weder eine Bestätigung noch eine Lösung
- Auch Stack Diary fragte Linksys am 9. Juli nach einem Reaktionsplan und hatte bis zum 14. Juli keine Antwort erhalten
- Nach umfangreichen Tests riet Testaankoop deutlich vom Kauf des Linksys Velop Pro WiFi 6E und Pro 7 ab und kam zu dem Schluss, dass das Risiko von Netzwerkeinbrüchen und Datenverlust erheblich sei
- Mesh-Router wie die Velop-Serie sind dafür konzipiert, die Wi‑Fi-Abdeckung in großen oder mehrstöckigen Häusern mit mehreren Verbindungsknoten zu verbessern, doch die Datenübertragungsmethode von Velop Pro WiFi 6E und Pro 7 untergräbt die eigentlich gebotenen Sicherheitsvorteile
2 Kommentare
Die Ausrede, dass Supportmitarbeiter Nutzern helfen können, die ihr Passwort vergessen haben
Meinungen auf Hacker News
Wenn man diese Kommentare liest: Finden alle es in Ordnung, das Passwort an einen Server zu senden, und sehen nur die fehlende Verschlüsselung als Problem?
Ich würde von vornherein nicht erwarten, dass das Passwort an einen Server übertragen wird.
Ein Router, der so etwas tut, ist für seinen Zweck ungeeignet; ehrlich gesagt halte ich Linksys-Router schon seit einigen Jahren generell nicht mehr für brauchbare Produkte.
Klartext lässt sich leicht beobachten und von Leuten entdecken, sodass es einen PR-Schaden verursachen kann; ein verschlüsseltes Passwort wäre dagegen praktisch schwer nachzuverfolgen.
Über den TR-69-Mechanismus senden Verizon-FiOS-Router das lokale WiFi-Passwort an ein zentrales Verwaltungssystem.
Die Ausrede, die ich gehört habe, war: „Damit der Support Nutzern helfen kann, die ihr Passwort vergessen haben“ :-/
Nebenbei: Wenn man in der App des Providers das Passwort der bereitgestellten Hardware ändern kann, wird dieses Passwort mit hoher Wahrscheinlichkeit zumindest innerhalb von TCP/TLS-Paketen im Klartext übertragen.
Ich bin froh, dass ich mir schon lange angewöhnt habe, keine vom Provider bereitgestellten Router zu verwenden.
Danach meldet man sich am Router an und legt ein neues Passwort fest.
Wenn ich ein Internet Service Provider wäre und zu viele Supportanfragen zu WiFi-Passwörtern bekäme, würde ich wohl darüber nachdenken, stärker auf WPS zu setzen.
Ich hasse es wirklich, dass sich die Router-Branche von stabiler lokaler Netzwerkausrüstung zu Smart Devices entwickelt hat.
Dieselbe Ausbeutung von Kunden, die man aus anderen Branchen kennt, passiert hier genauso. TP-Link zum Beispiel verwendet in Routern Dark Patterns wie Firmen à la Roku und zwingt Nutzer nach einer Aktualisierung der Nutzungsbedingungen per Pop-up zur Zustimmung, wenn sie die App weiter nutzen wollen.
Die App ist der einzige Weg, auf die meisten Router-Einstellungen zuzugreifen – anders als früher, als man eine passwortgeschützte Webseite aufrief und dort konfigurierte. Wenn man die neuen Bedingungen nicht akzeptiert, kann man den Router, den man bisher kontrolliert hat, nicht mehr steuern.
Außerdem drängt die App mit Anreizen wie roten runden Badges neben Menüpunkten oder UI-Elementen ständig nutzlose und unerwünschte Testversionen von Diensten auf.
Es würde mich nicht überraschen, wenn dort Klauseln enthalten sind, die wie bei Linksys den Missbrauch meiner Privatsphäre und Sicherheit ermöglichen.
Aber wohin soll man gehen? Alle Firmen machen das. Vielleicht können sie ohne das nicht überleben. Deshalb scheint Regulierung nötig zu sein, etwa Haftung für Sicherheitsverletzungen und Beschränkungen beim Missbrauch von Nutzungsbedingungen.
Ist das tatsächlich Klartext, oder Klartext innerhalb von HTTPS? Der Artikel und das Ausgangsmaterial sagen das nicht.
Dass ein Passwort in einer HTTPS-Anfrage im „Klartext“ steht, ist ziemlich normal. Fast alle Web-App-Logins funktionieren so.
Wenn es nicht HTTPS ist, gibt es neben dem Klartextpasswort in der Anfrage noch jede Menge andere Probleme.
Wenn es HTTPS ist, besteht das eigentliche Problem darin, dass das Passwort nicht lokal bleibt, sondern irgendwohin übertragen wird. Diese Praxis ist deutlich umstrittener, aber leider auch etwas, das viele Router häufig tun, um Cloud-/App-Verwaltungsfunktionen zu unterstützen.
Die einzigen Gründe, die mir gerade einfallen, sind, ein zweites Gerät für eine Mesh-Konfiguration „automatischer“ einzurichten oder nach einem Werksreset weiterhin dasselbe Passwort zu verwenden. Für beides gibt es bessere Lösungen.
Wenn es darum geht, ein neues Passwort zu setzen, verstehe ich nicht, warum das bestehende Passwort nötig ist; und wenn das WiFi-Passwort als Zugangsdaten für die Fernverwaltung genutzt wird, ist das schlecht, weil Zugriff auf mein Netzwerk nicht zugleich Administrationsrechte bedeuten sollte.
Falls es wirklich nötig ist, ließe sich das deutlich besser lösen, indem nur ein ausreichend gesalzenes und gehashtes Passwort gesendet wird.
Hätte jemand Zugriff auf den privaten Schlüssel des Linksys-Serverzertifikats gehabt, wäre das eine viel größere Nachricht gewesen.
Beeindruckend, dass eine Verbrauchertest-Organisation genug technische Expertise hat, um so etwas zu finden.
Das war ein Problem, das man nicht entdeckt, wenn man das Gerät einfach wie ein Verbraucher benutzt; man musste gezielt nach Sicherheitsbugs suchen, um es zu bemerken.
Es wäre wirklich schön, wenn Hersteller von WiFi-Routern OpenWRT nutzen würden.
Wenn sie möchten, können sie wie gli.net ein Skin darüberlegen; zumindest die Basis könnte OpenWRT sein. Es ist offen und funktioniert gut.
Produktdifferenzierung kann man weiterhin betreiben, indem man mehr Antennen anbaut, alle Geschwindigkeitszahlen addiert und das Ganze wirklich schnell aussehen lässt.
https://www.gl-inet.com/support/firmware-versions/
https://github.com/gl-inet/openwrt
Außerdem ist es einfach, per sysupgrade-Methode von OpenWRT ein unverändertes OpenWRT zu installieren.
https://openwrt.org/toh/gl.inet/gl-mt6000#installation
Die Einrichtung war einfach, die Performance gut, es gab auch einige erweiterte Funktionen, und es erhielt jahrelang Sicherheitsupdates.
Als bei einem Kollegen im Büro und mir vor etwa zwei Jahren eine Fritz!Box ausfiel, holten wir eine alte AirPort Extreme hervor; sie funktionierte nicht nur immer noch sehr gut, sondern war als 802.11ac-Router auch noch ziemlich konkurrenzfähig.
Ich bin nerdig genug, dass ich mir vor ein paar Jahren selbst einen Router mit OpnSense gebaut habe, und er lief wirklich hervorragend.
Der einzige Grund, warum ich damit aufgehört habe, war ein nicht umgehbares Problem zwischen BSD und einer bestimmten Broadcom-10Gbe-Karte; am Ende habe ich erst provisorisch etwas mit ClearOS gebaut und später dann NixOS verwendet.
Es gibt keinen wirklichen Grund, warum das nicht gehen sollte.
Ein GLI.NET-Gerät zu kaufen bedeutet daher nicht automatisch, Hardware zu bekommen, auf der „richtiges OpenWrt“ läuft.
Man muss weiterhin die Hardware-Kompatibilitätsliste prüfen oder, noch besser und aktueller, die Liste der DTS-Dateien im aktuellen OpenWrt-git-master ansehen.
Dieses Problem ist nicht auf die Velop-Produktfamilie beschränkt.
Als ich einen EA7500 auf openWRT umstellte, sah ich, dass exakt dieselben Informationen übertragen wurden, während er mich zwang, mich beim mylinksys-Webportal anzumelden, und eine Verbindung zum Heimserver herstellen wollte.
„Obwohl Linksys im November gewarnt wurde, wurden keine wirksamen Maßnahmen ergriffen.“
November? November? Klar, um diese Zeit gibt es viele Feiertage.
Trotzdem: Wenn der Anbieter nicht aktiv daran arbeitet oder kommuniziert, hätte so etwas spätestens Ende Januar öffentlich offengelegt werden müssen, finde ich.
Beschämend. Monate lang nicht zu reagieren ist aktiv böswilliges Verhalten, und nicht irgendein Wegwerf-Entwickler, dem man die Schuld zuschiebt, sondern das gesamte Unternehmen sollte entsprechend bestraft werden.
Ich wünschte, Apple würde wieder ins WiFi-Router-Geschäft einsteigen.
Bei Datenschutz und Sicherheit vertraue ich Apple mehr als den meisten anderen Marken.
Leider verkauft Apple Linksys-Router als Ersatz für seine früheren Produkte.
Die Leute wollen ihre eigene Hardware besitzen.
Die Quellen des Bootloaders und aller Onboard-Geräte müssen offen sein.
Für alle NPUs, Offloading-Engines und sonstigen Geräte im Ethernet-Datenpfad muss der Firmware-Quellcode bereitgestellt werden.
Der Mainline-Linux-Kernel muss einen vollständig blobfreien Boot unterstützen, mit Ausnahme von WiFi/RF.
Der TrustZone-Zugriff muss per Jumper aktivierbar sein, und Endnutzer müssen vollständiges Key-Management haben.
Es wäre gut, wenn intern ein serieller UART-Port-Header bestückt wäre.
Aber ich glaube nicht, dass Apple ein so nutzerfreundliches Gerät bauen würde, auf dem man fünf Minuten nach dem Auspacken problemlos OpenWrt installieren kann. Außerdem würden sie dafür vermutlich ordentlich Geld verlangen.