Quick Check: Und noch eine Kinder-Smart-Watch – Xplora X5 Play

Wie in jedem September aufs Neue, begann auch in diesem Jahr wieder der Ernst des Lebens für die nächste Generation Schulkinder. Und auch für die, die ihre Einschulung schon vor ein paar Jahren hinter sich gelassen haben, beginnt das neue Schuljahr. Klassisch ist dies auch die Zeit, in der viele Eltern nicht nur mit Stolz auf das neu gewonnene Stück Unabhängigkeit ihrer Kinder blicken, sondern auch die Sorge um den Nachwuchs ansteigt. Wer sich hier ein kleines Stückchen Kontrolle zurückwünscht und dem Nachwuchs nicht direkt sein erstes Handy in den Ranzen stecken möchte, greift gern zu den immer angesagteren Kinder-Smart-Watches. Wir nehmen das Ganze als Anlass, ein momentan sehr gefragtes Gerät aus diese Kategorie unserer Sicherheitsanalyse zu unterziehen – Die X5 Play von Xplora. Denn wenn vergangene Tests in diesem Bereich eins gezeigt haben, dann, dass solche Geräte nicht nur Vorteile mit sich bringen.

Merkmale

Bei der Ausstattung erwartet den gewillten Käufer erst einmal keine gr0ße Überraschung: Die  X5 Play vom norwegischen Hersteller Xplora Technologies bietet prinzipiell alles, was man hier auch erwarten würde. Für die mobile Erreichbarkeit ist die smarte Uhr mit einer SIM-Karte im Nano-Format zu bestücken oder auch als eSIM-Variante erhältlich. Im Heimnetz kann sie außerdem auch über das integrierte WLAN-Modul ins Internet gelangen. Über GPS lässt sich die Uhr auf Wunsch (relativ genau) orten und über integrierte Bewegungssensoren sogar die tägliche Schrittzahl des Kindes erfassen. Die Kommunikation kann klassisch über eine Anruffunktion durchgeführt werden oder man benutzt den integrierten Chat-Messenger für Text-, Emoji- und Sprachnachrichten. Als Betriebssystem selbst läuft auf der Uhr ein angepasstes Android in Version 7.1.2 (im Test in Build-Nummer W927_1.0.2208160_dev_user).

Mobile Applikationen

Natürlich werden zur X5 Play dazugehörige mobile Applikationen zur Verfügung gestellt, über die die Kommunikation zur Uhr ermöglicht wird, die Accountverwaltung durchgeführt werden kann und sämtliche remote Funktionen, wie Ortung oder Abschaltung, realisiert werden. Wie immer, wurden diese Applikationen für Android und iOS (com.xplora.xplorao2o; v1.2.73 bzw. v1.3.7) zunächst einer statischen Analyse unterzogen.

Das erste was dabei auffällt, ist die schiere Menge an Berechtigungen (auf Android sind es 38), die sich die Applikation zusichern kann. Viele davon lassen sich auf die zur Verfügung gestellte Funktionalität der Applikation zurückführen, bei einigen lässt sich hier allerdings nur schwerlich mit Notwendigkeit argumentieren. So kann die Applikation auf einem Android-Gerät die Hintergrundprozesse anderer Applikationen schließen, den Telefonzustand ohne Benachrichtigung ändern (d.h. Netzwerke wechseln, WLAN an- und ausschalten, usw.) oder die Systemkonfiguration ändern. Der Zugriff auf die Google AD-ID zu Retargeting Zwecken, die Accounts im Account Service sowie auf eine Liste der laufenden Prozesse lässt sich ebenfalls schwer mit der zur Verfügung gestellten Funktionalität erklären.

Die statische Analyse konnte außerdem 3 Tracker-Module mit Eintrag in der Exodus Privacy Datenbank und noch etliche weitere Third-Party Non-Free Bibliotheken identifizieren. Bei den Trackern handelt es sich dabei um zwei klassische Google Tracker, namentlich Crashlytics und Firebase Analytics, sowie das MapBox SDK, das hier hauptsächlich für die Ortungsfunktion verwendet wird, aber naturgemäß durchaus umfangreiches Tracking-Potential bietet.

Sicherheitstechnisch gibt es nach der statischen Analyse allerdings erst einmal keine wirklich kritischen Punkte zu berichten: Im App Manifest der Android-App lassen sich, wie aber typischerweise immer, einige Activities, Services und Broadcaster finden, die nicht ausreichend durch entsprechende Berechtigungen geschützt werden und so theoretisch die Möglichkeit offen lassen würde, dass Daten zu anderen Applikationen auf dem Telefon abfließen. Aber die Bedrohung ist hierbei eher theoretischer Natur. Außerdem fällt auf, dass die Applikation standardmäßig so konfiguriert ist, dass unverschlüsselte HTTP-Kommunikation grundsätzlich erlaubt ist (über android:usesCleartextTraffic=true) – was aber nicht heißt, dass dies praktisch auch geschieht. Dazu mehr im folgenden Abschnitt.

Online Kommunikation

In vergangenen Tests ähnlicher Produkte zeigten sich besonders in diesem kritischen Bereich oft eklatante Schwachstellen, die schnell Privatsphäre und Accounts der Nutzer bedrohen konnten. Was die grundsätzliche Kommunikation der Applikation und der Uhr über WLAN angeht, können wir hierbei insofern Entwarnung geben, dass wir zwar keine vollständig verschlüsselte Kommunikation beobachten konnten, aber zumindest eine verschlüsselte Kommunikation der kritischen Informationsübertragung. Auch die von uns standardmäßig durchgeführten Angriffe, wie Man-in-the-Middle, wurden von der App erkannt und korrekt behandelt. Soweit so gut.

Natürlich wollten wir es hier noch etwas genauer wissen und gerade weil wir in vergangenen Tests von ähnlichen Lösungen vor allem Einfallstore in der Server API identifizieren konnten, mussten wir auch die Gegenseite betrachten. Im ersten Schritt muss man dafür erst einmal nachvollziehen können, wie die Applikation überhaupt mit dem Server kommuniziert. Da man aufgrund der verschlüsselten Kommunikation hier nicht einfach mitlesen kann, hat man im Prinzip zwei Möglichkeiten den gewünschten Einblick zu erhalten. Entweder geht man den klassischen (und mitunter sehr verwundenen) Weg eines guten, alten händischen Reverse Engineerings des Quellcodes oder aber verändert den Applikationscode einfach so weit, dass die Verschlüsselung abgeschaltet oder zumindest so abgeschwächt wird, dass man die Kommunikation aufbrechen und mitlesen kann. Wenn man dann beobachten kann, wie die Applikation kritische Prozesse, wie Authentifizierung, Ortung oder Nachrichtenversand zur Uhr durchführt, kann gezielt nach Schwachstellen gesucht werden. Und an dieser Stelle offenbart die Xplora Lösung dann doch teilweise schwerwiegende, aber nicht unlösbare Probleme.

Also zunächst zur Authentifizierung. Diese geschieht über eine Kombination aus Accountname, in diesem Fall die Mobilfunknummer des Guardians, also des Elternteils, und dem dazugehörigen Passwort als MD5 Hashwert. Dass der MD5 Algorithmus heutzutage nicht mehr verwendet werden sollte, ist eigentlich gemeinhin bekannt. Da das Ganze aber über eine sicher verschlüsselte Verbindung übertragen wird, wollen wir hier fast noch darüber hinwegsehen. Bedenken sollte man aber, dass im Falle eines Datenlecks die Passwörter nur marginal besser geschützt sind als würden sie im Klartext vorliegen.

Außerdem zur Authentifizierung übertragen wird eine Kombination aus apiKey und apiSecret, zwei hardcoded Secrets. Überprüft werden diese beiden Werte auf Serverseite offensichtlich nicht, weil sie lediglich die richtige Länge haben müssen, um akzeptiert zu werden, fehlen sie aber, schlägt die Authentifizierung fehl. Übergibt man nun diese Werte (Mobilfunknummer, Passwort-Hash, apiKey und apiSecret) an den Server bekommt man ein Access Token zurück, mithilfe dessen man sich für weitere Zugriffe auf Daten und/oder Funktionen identifiziert und authentifiziert. Auch soweit so gut und so üblich.

Das Problem ist hier aber das Serverfeedback. Gibt man nämlich als Mobilfunknummer eine Nummer an, die bisher nicht am Server registriert ist, bekommt man die Fehlermeldung „Invalid request“ zurück. Ist die Nummer aber registriert und das Passwort ist inkorrekt, erhält man „Incorrect Password“… Ein Angreifer hat hier also nicht nur die Möglichkeit zu einer bekannten Nummer zu überprüfen, ob es dazu einen Account gibt, er kann sogar stumpf den gesamten möglichen Suchraum (in diesem Fall also schlicht alle möglichen Mobilfunknummern) durchforsten und alle registrierten Accounts identifizieren. Zu jedem so gefundenen Account hat er dann natürlich auch die Möglichkeit das Passwort anzugreifen.

Jetzt wird natürlich jeder einigermaßen im Thema stehende Leser sofort sagen „Aber…Rate Limiting“. Ja stimmt. Gibt es hier aber nicht. Wir haben testweise nur die ersten 100000 Nummern einiger deutscher 017x-Vorwahlen durchlaufen lassen (etwa 600000 Anfragen; reiner Rechenaufwand von ein paar Stunden) und haben auf Anhieb über 1500 registrierte Accounts identifiziert.

Nimmt man sich dann nur die Top 10 der „Hall of Shame“ der häufigsten Passwörter 2021 her und feuert diese auf die identifizierten Accounts, stehen die Chancen schon rein statistisch nicht schlecht, dass man ziemlich bald Erfolg hat (nicht, dass WIR sowas machen würden…). Jetzt könnte man immer noch sagen „Ja, aber wenn bei der Accounterstellung ein sicheres Passwort erzwungen wird, ist das Erraten aber trotzdem noch ungeheuer schwierig!“. Ja, auch das ist korrekt. Aber wird auch nicht gemacht. Der Spitzenreiter der erwähnten Top 10 Passwortliste, das „Passwort“ 123456, ist bei der Accounterstellung absolut zulässig – ähnlich schlechte oder noch schlechtere Passwörter übrigens auch. Und selbst bei einem sicheren Passwort hat der Angreifer mithilfe des Wissens über die gültige Telefonnummer des Opfer auch noch eine ganze Liste weiterer Möglichkeiten, dieses gezielt ins Visier zu nehmen.

Hat der Angreifer dann tatsächlich das Passwort ermittelt, hat er Vollzugriff zu allen Funktionen, wie Ortung und Messagedienst – nicht nur für Eltern gruselig. Hier sollte der Hersteller also unbedingt und umgehend nachbessern.

Datenschutz und Privatsphäre

Die Probleme, die im vorherigen Abschnitt angesprochen wurden, haben natürlich auch direkt Einfluss auf den Datenschutzbereich. Wenn gültige Telefonnummern und die dazugehörigen Accounts so einfach über das Produkt ermittelbar sind, ist die Privatsphäre und der Datenschutz der Nutzer logischerweise direkt betroffen.

Abgesehen davon ist das Produkt aber datenschutztechnisch eher unauffällig. Natürlich hat ein Produkt der Kategorie weitreichende Einblicke in die Privatsphäre des Nutzers und die werden auch bei der Xplora X5 Play ausgiebig zur Datensammlung verwendet. Was anderes ist hierbei aber auch von vornherein nicht zu erwarten. Die Datenschutzerklärung (Stand: Oktober 2019) ist zwar kein Paradebeispiel von Transparenz und Detail, enthält aber prinzipiell die wichtigsten Punkte zu Datensammlung, -haltung und -weitergabe. Uns fehlen hier aber dennoch explizite Benennungen der enthaltenen Trackermodule und ihrer genutzten Funktionalität. Genauso würde es bei 38 angeforderten Berechtigungen durchaus Sinn ergeben, die Notwendigkeit der einen oder anderen näher zu erläutern. Zudem wird in der Datenschutzerklärung zwar erwähnt, dass beispielsweise gesammelte Daten zum Kind selbst zur Erfüllung bestimmter unbenannter Serviceleistungen an Drittanbieter weitergegeben werden, welche Dienstleistungen und vor allem welche Dienstleister damit aber explizit gemeint sind, wird nicht näher erläutert. Wir unterstellen hier natürlich niemals eine absichtliche fehlende Transparenz, könnten uns aber denken, dass der eine oder andere Nutzer größeres Vertrauen in das Produkt hätte, würden solche Informationen weniger allgemein gehalten dargelegt werden.

Fazit

Im Prinzip ist die Xplora X5 Play ein durchaus gelungenes Produkt: Die Applikationen sind augenscheinlich technisch sauber implementiert und auch formal ist das wichtige Thema Datenschutz und Privatsphäre zumindest ausreichend gut abgedeckt. Die teils eklatanten und heutzutage auch völlig unnötigen Probleme die Server API betreffend, lassen aber natürlich keine gute Bewertung zu. Und das obwohl wir im Rahmen des Quick Checks noch nicht einmal bis in die tiefsten Tiefen der Xplora-Lösung vorgedrungen sind. Wir empfehlen dem Hersteller hier schnell und effektiv nachzubessern – unlösbar sind die Probleme nämlich in keinster Weise.

Im Anschluss an unseren Test und vor Veröffentlichung dieses Posts, haben wir den Hersteller über die gefundenen Schwachstellen informiert. Xplora reagierte nach der zweiten Anfrage und versprach eine schnellstmögliche Beseitigung. Wir räumten dem Hersteller aufgrund des relativ geringen Aufwands zur Behebung eine Frist von 30 Tagen ein. Eine offizielle Bestätigung durch Xplora, dass die identifizierten Schwachstellen erfolgreich behoben wurden, steht bisher noch aus.