{"id":12991,"date":"2025-10-04T14:55:46","date_gmt":"2025-10-04T12:55:46","guid":{"rendered":"https:\/\/www.wespeakiot.com\/?p=12991"},"modified":"2025-10-04T14:55:46","modified_gmt":"2025-10-04T12:55:46","slug":"kritische-schwachstellen-im-yolink-smart-hub-gefahr-fuer-smart-home-nutzer","status":"publish","type":"post","link":"https:\/\/www.wespeakiot.com\/de\/kritische-schwachstellen-im-yolink-smart-hub-gefahr-fuer-smart-home-nutzer\/","title":{"rendered":"Kritische Schwachstellen im YoLink-Smart-Hub: Gefahr f\u00fcr Smart-Home-Nutzer"},"content":{"rendered":"
YoLink Smart Hub mit sicherheitsrelevanten Schw\u00e4chen. Foto: YoLink<\/span><\/div>\n

Das Sicherheitsunternehmen Bishop Fox hat im YoLink Smart Hub (Firmware v0382) mehrere sicherheitsrelevante Schw\u00e4chen gefunden. In einem Blogpost zeigt Sicherheitsexperte Nick Cerne, der das Ger\u00e4t zerlegte, interne Logs auslas, MQTT-Zugangsdaten und API-Informationen gewann, wie Angreifer so fremde Smart-Home-Ger\u00e4te fernsteuern k\u00f6nnten.<\/h2>\n

YoLink ist eine Smart-Home-Marke<\/a> des US-Unternehmens YoSmart Inc. mit Sitz in Irvine, Kalifornien, die auf LoRa-basierte IoT-Produkte wie Sensoren, T\u00fcrschl\u00f6sser, Steckdosen, \u00dcberwachungssysteme und Steuerhubs spezialisiert ist und ihre Ger\u00e4te haupts\u00e4chlich, aber nicht ausschlie\u00dflich, \u00fcber den US-Markt (Amazon, eigene Online-Shops) vertreibt.<\/p>\n

Nick Cerne, Senior Security Consultant bei Bishop Fox begann mit einer physischen Zerlegung des YoLink Smart Hub. Auf der Leiterplatte fand er einen ESP32-WROOM-32 System-on-Chip. \u00dcber die offenliegenden Debug-Pins konnte er per UART eine serielle Verbindung zum Ger\u00e4t herstellen. Die \u00fcber UART sichtbaren Boot- und Anwendungs-Logs zeigten unter anderem die WLAN-MAC, einen API-Endpunkt sowie MQTT-Verbindungsinformationen. Aus den Logs lie\u00df sich die Adresse des YoSmart-MQTT-Brokers und mehrere Identifikationswerte des Hubs ablesen. Diese Informationen lieferten die Grundlage f\u00fcr weitere Analysen. Parallel f\u00fchrte Cerne eine Paketmitschnittanalyse des mobilen Clients durch. Mit Wireshark konnte er Login-Anfragen, die Familien-\/Account-IDs und tempor\u00e4re Session-Tokens der mobilen App einsehen. Aus diesen Aufzeichnungen ging hervor, wie die App sich am MQTT-Broker authentifizierte und welche Topics f\u00fcr Ger\u00e4tekommunikation verwendet wurden.<\/p>\n

Reverse-Engineering: API-Secret und Ger\u00e4te-IDs<\/h3>\n

Durch Auswertung und Decompilierung von Firmware-\/Bin\u00e4rcode identifizierte Cerne eine Funktion, die aus einem festen Schl\u00fcsselteil und der Ger\u00e4te-ID einen MD5-Hash ableitete. Dieser Hash wurde vom Ger\u00e4t als Teil eines API-Endpunkts verwendet. Zudem stellte sich heraus, dass Ger\u00e4te-IDs nicht ausreichend zuf\u00e4llig sind und sich sequenziell ableiten lassen. Um zu pr\u00fcfen, ob Autorisierungspr\u00fcfungen existierten, kaufte der Sicherheitsexperte ein zweites Hub und legte zwei Accounts an. Mit den \u00fcber UART und Paketmitschnitt gewonnenen MQTT-Zugangsdaten des zweiten Accounts ver\u00f6ffentlichte er gezielt Nachrichten auf dem MQTT-Topic des ersten Accounts. Die Ausgabe des Brokers zeigte erfolgreiche CONNECT\/CONNACK und PUBLISH-Sequenzen. Physisch beobachtete Cerne, dass sich das fremde Schloss tats\u00e4chlich entriegelte.<\/p>\n

Damit war nachgewiesen, dass der API-Broker keine ausreichenden Autorisierungspr\u00fcfungen durchf\u00fchrte und g\u00fcltige MQTT-Anmeldedaten zum Steuern fremder Ger\u00e4te reichten.<\/p>\n

Reaktion des Herstellers und Empfehlung<\/h3>\n

Bishop Fox meldete die Schwachstellen verantwortungsvoll an YoSmart. Laut Ver\u00f6ffentlichung gab es bis zum Datum des Blogposts kein Reaktions-Statement oder verf\u00fcgbares Sicherheitsupdate. Die Forscher empfehlen, den Hub als nicht vertrauensw\u00fcrdig zu behandeln: vom kritischen Netzwerk trennen, nicht f\u00fcr Zugangskontrollen verwenden und auf Anbieter mit nachweisbarer Sicherheits-Praxis wechseln. Der Bericht zeigt exemplarisch klassische IoT-Probleme: offene Debug-Schnittstellen, fehlende Verschl\u00fcsselung und mangelhafte Autorisierung f\u00fchren schnell zu praktischen, physisch relevanten Angriffen. Gateways sind Single Points of Failure. Wird die Zentrale kompromittiert, sind alle angeschlossenen Ger\u00e4te gef\u00e4hrdet.<\/p>\n

Zusammenfassung (tl;dr)<\/h3>\n