Wie man einen Nello One nicht von der Cloud befreit

Published: December 4, 2018

Beim Nello One handelt es sich um ein Ding, welches es ermöglichen soll die Haustür in einem Mehrfamilienhaus "smart" zu machen.
Mittels einer Handyapp gibt es Informationen darüber wann geklingelt wird, sowie die Möglichkeit die Tür remote zu öffnen.

Dazu bietet Nello noch einige Kooperationen mit Lieferdiensten und Paketdienstleistern um Lieferungen zu ermöglichen, obwohl niemand zuhause ist.

Nette Sache. Wo ist der Haken?
Die Cloud. ☁
Das Ganze gibt es natürlich nur mit einem Account beim Hersteller. Eine Offlinenutzung ist nicht vorgesehen.

Disclaimer:
Dieser Artikel liegt schon etwas länger hier rum. Es kann also sein, dass die Informationen nicht mehr korrekt sind.

Okay, es handelt sich um ein kleines Start-up. Die Zielgruppe des Produkts ist ohnehin beschränkt. Da jetzt auch noch die Möglichkeit der Offline-Nutzung einzubauen würde Resourcen benötigen die schlicht und ergreifend nicht vorhanden sind.
Dazu sind die Nutzerdaten dieser Zielgruppe natürlich noch verdammt geil denn Zeug auf dem "Smart" steht verkauft sich wie geschnitten Brot. Da kann man gar nicht genug Datensätze zu haben.

Die Analyse

Gut, dacht ich mir, bevor du das Ding orderst schaust du mal wie weit du kommst. Zunächst ein Blick in die AGB. Reverse Engineering wird dort nicht ausgeschlossen. 👍

Charles Proxy gestartet, die App des Herstellers auf einem Android Handy mit Android 5 installiert und dann einfach mal mit der Konfiguration angefangen und das ganze mitgesnifft.

Warum Android 5? Seit Android 6 oder 7 muss man die APK von Hand bearbeiten (oder dieses Skript nutzen) wenn man möchte, dass sie ein falsches CA Zertifikat akzeptiert.

Aus dem mitgesnifften Traffic dann eben mit Node/Express einen Mock Server mit HTTPS erstellt, fake CA Cert auf dem Handy installiert und schon war die echte App nutzbar um dem Nello One auch ohne Anlage eines Cloud-Accounts die W-Lan Zugangsdaten mitzuteilen.

An diesem Punkt habe ich dann, in Erwartung, dass es so leicht bleiben würde, eines dieser Geräte geordert.

Was habe ich bisher herausgefunden?

Das Backend hört auf api.nello.io und live-mqtt.nello.io. Dazu gibts noch eine mqtt Testumgebung unter mqtt.nello.io
Die Api ist ein REST irgendwas auf Basis von Python/Flask hinter einem NGINX auf Ubuntu VMs bei AWS EC2. AWS hat eigentlich auch selbst Loadbalancer. Warum der NGINX?
Die Kommunikation des Nello One mit dem Server des Herstellers erfolgt mittels MQTT ohne SSL auf dem default port 1883

Das Backend

Generell geben die Endpunkte von api.nello.io anscheinend immer JSON zurück. Ich habe nur HTTP Statuscode 200 beobachten können.

Innerhalb dieses JSON gibt es dann ein result object mit einer property namens "status". Diese enthält bunt gemischt numerische HTTP Statuscodes wie z.B. 404 als String oder auch mal ganz andere Strings wie "OK".

Für den Login gibt es den Endpunkt /login. Gibt man dort inkorrekte Daten ein antwortet der Server wie folgt:

{ "authentication": false, "result": { "message": "Username/Password problem.", "status": "OK" } }

Passt. Verrät einem Angreifer nicht was falsch war. So soll es sein...

Sicherheitsbedenken

... wäre da nicht der /check-email Endpunkt.

Dieser existiert, um bei der Neuanlage eines Accounts zu prüfen, ob die Email bereits in der Datenbank existiert.
Hier ein POST ohne Authentifizierung o.ä. aber dafür mit einer Email-Adresse an /check-email:

{ "has_password": true, "password_reset": false, "result": { "message": "User already exists", "status": "200" }, "user_exists": true, "user_id": "64750b31-9f15-4f6f-b712-5ce4598abe01" }

Oh ein Datenleck. Sogar noch mit user_id frei Haus dazu.

Weitere Erkenntnisse

Grundsätzlich existiert keine Validierung der Emailadresse innerhalb der App und wohl auch nicht Serverseitig.
Die Anlage eines Accounts mit der Emailadresse "foobar" führte zu einem Fehler bei der Anlage und gleichzeitig zu einem halb angelegten Account für den ein Login möglich war.

Emailadressen, die auf @example.com enden lassen einen immerhin im Dialog in der App weiter vorankommen.
Dazu scheint es generell derzeit an einigen Stellen in der App kein Handling von Timeouts zu geben. Die stürzt dann gerne mal ab.

Soweit zu der ersten Analyse ohne Gerät.

Das Gerät

Irgendwann kam der Nello One dann auch mit der Post. Ausgepackt, eingebaut, konfiguriert.
Hier die Erkenntnisse in Kurzfassung:

Jedes Nello One scheint eine eindeutige ID zu haben. Diese steht nicht auf der Verpackung und dient als infix der zugehörigen mqtt topics.
Bei der ersten Verbindung zum W-Lan subscribed das Gerät zu allerhand Topics: /nello_one/FFFFFF/{test,BE_ACK,tw,geo,door,BEn}/
Danach publisht es eine Nachricht mit irgendwelchem Base64 und QoS 1 auf das Topic /nello_one/FFFFFF/map.
Daraufhin publisht das nello Backend eine Nachricht mit irgendwelchem anderen Base64, trailing newline und QoS 1 auf das Topic /nello_one/FFFFFF/test
Wenn dies korrekt war beginnt die LED des Nello One zu blinken.

Nun folgt der weitere Einrichtungsdialog, welchen ich jedoch nicht ohne Cloud replizieren konnte, da für das gleiche Kommando bei jeder Wiederholung eine andere Kontrollnachricht auf das topic /nello_one/FFFFFF/BEn gepublished wurde.

Ich nehme an, dass bei der ersten Registrierung irgendetwas ausgetauscht wird um Replay-Angriffe zu verhindern. Der mqtt Server ist schließlich öffentlich und anscheinend kann dort jeder ohne Authentifizierung Nachrichten publishen.

Die Kapitulation

An dieser Stelle verlor ich dann aber auch das Interesse. Der Aufwand stand für mich leider in keinem Verhältnis zum Nutzen 🙁

Vielleicht hat ja jemand anderes Lust sich das näher anzusehen.

Weitere Gedanken

Während meiner Recherche habe ich noch diesen Blogartikel gefunden in dem ein ehemaliger Mitarbeiter des Unternehmens irgendwelche Details aus der Entwicklung festgehalten hat. Der Artikel lässt vermuten, dass es sich bei der Hardware um einen Nordic nrf52 MCU mit einem Atmel winc1500 W-Lan uC handelt.