Moin! Ich habe seit gestern eine neue Küche und das erste Mal zwei „smarte“ Geräte: einen neuen Miele Kühlschrank und einen neuen Miele Backofen. Zwecks Updates und Garantie habe ich sie per WLAN in ein separates VLAN gehängt und über Nacht mal die Packete per tcpdump auf meiner Firewall (OPNsense 25.1.3) geloggt.
2.227 ist der Backofen, 2.228 der Kühlschrank, 100.10 ist mein PiHole DNS, 2.1 die FW/das GW, 224.x ist mDNS Verkehr.
52.136.217.168 + 52.136.223.17 gehört zu Microsoft Corporation (MSFT) – wahrscheinlich irgendwelcher Azure-Kram wo Daten geloggt werden. 62.159.244.195 gehört zu Miele & Cie. KG. Der Azure-Traffic ist TLS verschlüsselt. Ich habe u.a. in den Android-App-Analysen gesehen, dass ich per MITM und Zertifikatswechsel in den TLS-Verkehr schauen kann, wenn kein Certificate Pinning verwendet wird. Wo kann ich hierfür eine gescheite, kurze Docu finden, um das ggf. auf meiner FW oder auf dem PiHole zu installieren. Alternativ hätte ich auch noch einen weiteren Raspi, wo ich das installieren könnte. Parallel dazu werde ich bei Miele nach den Daten fragen und den Datenschutzbeauftragen einschalten, da ich alle Optionen bei der Konfiguration deaktiviert habe! Keine Nutzungsdaten, kein Tracking, kein „zur Verbesserung unseres Services, bla, bla, bla“ und trotzdem schieben beide Geräte 2 MB Daten über 10 Stunden ins Netz. Das ist wohl mehr als nur ein Ping!
Ich bin für alle Hinweise und Hilfen dankbar. Danke + Gruß, Andreas
Update:
websocket-eu.mcs2.miele.com: type A, class IN, addr 52.136.217.168
ntp.mcs2.miele.com: type A, class IN, addr 52.136.223.17
Du müsstest eine CA die du kontrollierst auf die IoT-Geräte bringen und diese der CA vertrauen lassen, um TLS-verschlüsselte Kommunikation zu entschlüsseln. Ich bezweifle stark, dass die das zulassen.
Wer die Vorteile eines smarten Kühlschranks nutzen will, muss sich darüber im Klaren sein, dass irgendwo Daten verarbeitet werden. Wenn zum Beispiel ein Barcode-Scanner eingebaut ist, braucht der Kühlschrank eine Datenbank mit den Barcodes. Irgendwo müssen die Informationen ja herkommen. Wenn der Kühlschrank jetzt jeden Barcode, der gescannt wird, mit einer externen Datenbank abgleicht (was wahrscheinlich ist), dann weiß der Datenbankbetreiber, was du im Kühlschrank hast. So einfach ist das. Wer das nicht will, der braucht so einen Kühlschrank nicht. Das ist meine Meinung.
Was mich bei diesem Konzept mehr beunruhigt, sind Sicherheitslücken im System, die unter Umständen das gesamte Netzwerk gefährden können. Das könnte vor allem dann problematisch werden, wenn durch ein infiziertes System andere, sensiblere Systeme wie Heimcomputer, NAS, Heizung etc. im Haus angegriffen werden. Das hast du ja schon mit dem VLAN getrennt.
Dann sind imho vor allem Systeme gefährlich, die mit optischen oder akustischen Sensoren ausgestattet sind, wie zum Beispiel Staubsaugerroboter. Oder es gab mal einen Fall mit einer Spielzeugpuppe, mit der man sprechen konnte. Die Antworten wurden in einer Cloud generiert und an das System zurückgeschickt. Das muss man einfach wissen. Bei einem Kühlschrank oder einem Herd könnte die Nutzung an sich ein Problem darstellen. Wenn zum Beispiel der Kühlschrank mehrere Tage nicht geöffnet oder der Herd nicht benutzt wurde, könnte das darauf hindeuten, dass niemand im Haus ist usw. Oder bei der sprechenden Puppe hat man quasi eine Wanze im Haus, die mithört.
Ich bezweifle auch, dass man an den verschlüsselten Datenverkehr herankommt. Die Hersteller wissen natürlich auch, dass es ein eklatantes Sicherheitsrisiko wäre, wenn sie andere Zertifikate als ihre eigenen akzeptieren würden. Das ist ja zum Schutz des Verbrauchers gedacht. Es wird sicher aufwendige Methoden geben, das zu umgehen. Das hängt sehr stark davon ab, wie viel Aufwand man zu investieren bereit und in der Lage ist.
Sorry, war offline – Restarbeiten in der Küche . Danke für die Hinweise. Ich werde es erstmal mit einer ausführlichen DSGVO-Anfrage/Auskunft versuchen und parallel mal schauen, was nmap so sagt .
Wenn das alles wirklich auf Port 80 läuft, hast du vielleicht Glück. Zumindest, was das Sniffing des Traffics betrifft. Es könnte aber auch ein permanenter Redirect auf Port 443 sein. Das wäre nicht ungewöhnlich. Ansonsten wäre es ziemlich unsicher.
Da wir uns auch einen WLAN fähigen Geschirrspüler gekauft haben, stand auch ich vor der Frage, wie man mit dem Thema smarte Elektrogeräte umgehen soll (Link zu meinem Post). Dass man aber Zwecks Erfüllung der Garantiebedingungen den Zugang zum Internet einrichten muss konnte ich weder bei Miele noch bei Siemens finden.
Wir brauchen so ein Gerät nicht, nur mittlerweile gibt es gute Geräte nicht mehr ohne „smart“. Wichtig ist es meiner Meinung nach vorab zu klären, ob das Gerät auch ohne Internet seinen Funktionen erbringt oder nicht. Leider ist die BSH Group, zu der auch Siemens gehört, dem Trend verfallen, bei einigen Geräten einen Teil der Funkionen nur zur Verfügung zu stellen, wenn man sein Gerät in die Cloud bringt und die App hat.
Naja, das mit Update und Garantie ist so ein Nudging-Ding. Man muss nicht. Updates bekomme ich halt nur über das Internet. In meinem Fall war das die Firmware für das WLAN-Modul von Backofen und Kühlschrank. Die Sache mit der Garantie kam eher über die App, da dort das Kaufdatum hinterlegt wird und damit der 2-Jahres-Zeitraum für die Garantie. So kommt eins zum anderen. Miele bietet eine gute API-Dokumentation (hier).
Was mich hier am meinsten ärgert ist das offensichtliche ignorieren meiner Vorgaben. Ich habe nirgens dem Erfassen von Gerätedaten zugestimmt und trotzdem sehe ich den Traffic. Die Datenschutzerklärung ist eigentlich an dieser Stelle gut formuliert:
Sie können der Erfassung, Pseudonymisierung und Auswertung Ihrer Gerätedaten und der Fabrikationsnummer zustimmen oder widersprechen bzw. Ihre Einwilligung widerrufen, indem Sie die Funktion während des Registrierungsvorgangs oder in den Profileinstellungen/dem Consent Manager der Miele Apps aktivieren oder deaktivieren.
Um mit dem Miele Ofen/Kühlschrank rein offline zu kommunizieren, ist es generell nicht notwendig, die TLS-Verschlüsselung zu knacken/umgehen; die Geräte akzeptiert einen lokal generierten, symmetrischen Schlüssel und beantwortet dann entsprechend verschlüsselte und kryptographisch signierte Anfragen auf Port 80. ich bin der Autor vom MieleRESTServer, der genau das rein lokal implementiert – siehe hierzu meinen Code auf https://github.com/akappner/MieleRESTServer .
Wenn das Ziel ist, das Gerät einfach nur zu nutzen, dann wäre es wohl am einfachsten, alle Online-Kommunikation in der Firewall zu blockieren und nur lokal zu kommunizieren.
Es wäre natürlich trotzdem interessant, zu verstehen, was in den TLS-Paketen drin ist – vielleicht gibt es ja auch mehr Funktionalität, die über das lokale HTTP-Interface gar nicht verfügbar ist. Habe ich nicht versucht.
@Cyberduck
Das „eklatante Sicherheitsrisiko“ besteht wohl eher in der Verwendung eines vom Herstellers fest einprogrammierten Zertifikats, von welchem der Benutzer weder den privaten Teil kennt noch er es ändern kann. 1) hat der Benutzer jetzt irgendeinen verschlüsselten, unauditierbaren Traffic im Netzwerk. 2) ist davon auszugehen, dass, wer dieses Zertifikat kompromittiert, alle Geräte, die mit diesem Zertifikat signierte Updates annehmen, knacken kann.
„The programs themselves do not run on current versions of Java.“ (https://github.com/akappner/MieleRESTServer) klingt auch nicht gut. Gilt vermutlich nicht nur für die Testsuite sondern auch für die Geräte?
Damit meinte ich nur, dass die im Symcon-Forum beschriebenen Java-Programme auf aktuellen Versionen von Java nicht lauffähig sind. Das sind ja von Enthusiasten geschriebene Tools; die Software auf dem Gerät selbst hat damit nichts zu tun. Diese Tools sind auch m.E. hauptsächlich als Referenz interessant; der Server kann mittlerweile mehr und läuft auf aktuellen Plattformen. Habe sie hauptsächlich verlinkt, um die gute Arbeit ihrer Autoren anzuerkennen.
Ich habe auch keinen Grund, zu glauben, auf dem Miele-Gerät läuft Java… das Kommunikationsmodul auf (meinen) Miele-Geräten ist ein ESP32 (https://fcc.report/FCC-ID/2AC7Z-EK057 – nicht unbedingt ein Traum-Target für einen Java-Entwickler
Ich habe die Diskussion so verstanden, dass nicht der Datenverkehr zwischen Gerät und Benutzer das Interesse des OP geweckt hat, sondern der Datenverkehr vom Gerät zum Hersteller. Zumindest bezog sich mein Beitrag darauf, und die externen Adressen im Trace des OP sind ja auch eindeutig… Der REST-Server stellt zwar eine API im Gerät des Nutzers zur Verfügung, mit der man wohl auch nur lokal kommunizieren kann. Das verhindert aber nicht per se die Möglichkeit, dass das Gerät von sich aus eine Verbindung zu Diensten des Herstellers aufbaut. Dies an der Firewall zu unterbinden ist aber sicherlich eine praktikable Lösung.
Was ich eigentlich mit dem Sicherheitsrisiko meinte, bezieht sich auf diese Verbindungen zu externen Diensten. Falsch abgebogen bin ich dahingehend, dass ich davon ausgegangen bin, dass der Clouddienst die Verbindung zum Gerät aufbaut, was Zertifikate auf dem Gerät erfordert hätte, denen der Clouddienst vertraut. Das ist natürlich Unsinn. Bei diesem Verbindungsaufbau wäre der Router des Kunden im Weg. Umgekehrt ist es aber nicht anders. Wenn das Gerät eine Verbindung zum Cloud-Dienst aufbaut, muss das Gerät den Zertifikaten des Cloud-Servers vertrauen. Und bei TSL-verschlüsseltem Verkehr wird es für den OP schwierig sein, den Verkehr zu analysieren. Eben weil er nicht im Besitz des geheimen Schlüssels ist.
. Danke für die Hinweise. Ich werde es erstmal mit einer ausführlichen DSGVO-Anfrage/Auskunft versuchen und parallel mal schauen, was nmap so sagt 
.
