A security minded guy forced to buy a Wifi enabled cleaning robot

August 1, 2017

First I want to tell you all that I wanted a vacuum cleaning robot without Internet connection, but I couldn’t find one which fulfilled the requirements. At first I thought the DEEBOT M81 from ECOVACS would be such a device (vacuum and mop combo and possible to carry between rooms as it works randomly), but don’t buy it if you’ve stairs. On the first day alone at home it went 2 floors down, somehow it did look okay and still worked after the kamikaze. We just needed to search for it through the whole house. After that I did some tests, I found out that it stops 6 times at the stairs and falls down the 7 or 8 time. Searching through the Internet showed me that I’m not the only one. The second problem was that configuring the timer differently for some days (like not cleaning on weekends) was not possible. After loosing my last chance for a non Internet connected device I went for the DEEBOT M81 Pro which needs an Android or IPhone app and WiFi, if you want to configure the timer for not cleaning on weekends. This is my story about that – I guess – a typical IoT device.

The App – ECOVACS
After unpacking and charging of the robot, I went and installed the App on my test mobile. Why not on my real mobile? Take a look at the required permissions:

I though that is just an App to control my vacuum robot …. guess not. Anyway I installed it on my test system and created a dummy user. Of course I took a look at the traffic. First it connects to ecosphere-app.ecovacs-japan.com,

where it does an HTTPS connect. Hm, maybe thats better than I thought, but the TLS config of the server is bad, but at least it encrypted – so there is still hope.

Looking at the other traffic I saw a XMPP / jabber connection (lbat.ecouser.net / 47.91.78.247), which was encrypted, but sadly with a self signed certificate. I’ll thought I’ll take a look at the traffic via MitM later, lets get it to work before.

Getting it to work
It looks like the robot is creating a SSID for the App on the mobile to connect to, after you pressed the WiFi button >3 sec. So the exchange of the WiFi password seems to secure enough. But it took me almost 1h to get the robot to connect to my IoT network and I didn’t find any information or tips online. I changed following on my side to get it to work, maybe that helps somebody else:

I enabled the location stuff (which I’ve disabled by default) on the mobile as I remembered the WiFi Analyser App always tells me to enabled that to sees WiFi networks.
I needed to change my IoT network to support legacy WiFi modes. My normal setup is:

I needed to change it to following in order for the robot to be able to connect:

Robot traffic

The first request from the robot after getting an IP address is to request a HTTP connection to lbo.ecouser.net (47.91.78.247) on Port 8007

Hey we know the IP address and port – that’s the Jabber server the App also connects to. But before the robot connects to the Jabber server he does a second HTTP request, this time to an IP address (47.88.193.19:8005) and not a DNS name. Thats interesting:

That looks like a check for newer firmware …. firmware updates unencrypted .. what can possible go wrong here. As the request currently returns no new firmware I can’t look at that more closely – something for the future. Checking Shodan Info on that IP address is interesting. It runs a portmapper and ntp server reachable from the internet … someone already using that as DDOS amplifier? I’m not talking about the not configured nginx which also leaks IP addresses in the certificate: IP Address:120.26.244.107, IP Address:121.41.41.198, IP Address:47.88.193.19

Let’s go back to the Jabber server the robot connect to. The App uses a self signed certificate “protected” channel but the robot does connect completely in the clear – thats nice so I don’t need to do a MitM attack. The wireshark trace is so full on information that I’m really not sure what I can show you without making it too easy for you to control my robot.

Following is shown in the screenshot (which shows only a a part of the communication):

The logon to the server via PLAIN authentication, which is comprised of
- username: Is the serial number of the device, which is also printed onto the box the device is sold in.
- password: Looks like a MD5 hash of something, as its 32 hex chars – something to investigate
It shares its online (presence status in jabber terms) with the app
It gets asked for a version, I guess the firmware version which it returns as 0.16.46 – hope a thats already stable

Looking at later traffic following requests issued by the app:

GetDeviceInfo
SetTime
GetChargeState
GetBatteryInfo
GetWKVer
GetError
GetOnOff
GetSched
GetLifeSpan

I didn’t control the device via the App otherwise there should be much more commands.

Questions and thoughts

I don’t really see a peering which makes sure that only the right App can control a robot, so it is maybe possible to control other robots. As the user ID used on the Jabber server is just the serial number with @141.ecorobot.net/atom added, it should be ease to guess additional user IDs. There is no need to know the password of the robot. On the other side it should be possible to create your own Jabber server and redirect traffic to it. Also writing a DIY App without all that App permissions should be possible and not to hard. The robot I bought is not so interesting for an attacker as it cannot provide room layouts as the more expensive ones provide. The screenshots of the App show what is possible:

I guess I wait for the next versions of the robots that provide a microphone and/or a camera – than it gets really interesting.

As I was able to configure the schedules via the App and set the time, I’ll try if that still works if the robot is not able to connect to the Internet. If so I’ll got that route and enable the Internet connection only if I need to change the schedules.

Ps: you should really have a separate IoT network.

In IT Security | 6 Comments

6 Comments »

RSS feed for comments on this post. TrackBack URI

I have the M-88 and it does the same basic functions but the servers all appear to be in California as opposed to Singapore. I’m in the US. I’m going to run it through Burp Suite when I get the time. I assume its intelligence lies in the server and it will send back the mapping of your home.

Comment by Gregg — September 15, 2017 #
Great work!

I’ve implemented a lightweight XMPP server for Ecovacs robots. DNS spoofing is required to make it work, but that’s it.
https://github.com/torbjornaxelsson/bumper

It works with the official app but I’m mainly using it with open source client Sucks.

There is so much wrong with Ecovacs implementation.. but I think I found my favourite. If you send a command to the robot from a nonexisiting user, you get this reply:

iq to=’[email protected]’ type=’set’ id=’247′>

The admin parameter contains THE REAL ADMIN USER! Thanks, robot 🙂

Comment by Torbjörn Axelsson — December 18, 2017 #
Sorry the xml tag in my comment didn’t display correctly.. the reply from the robot contains parameter admin=’[email protected]’

Comment by Torbjörn Axelsson — December 18, 2017 #
Noticed the same shenanigans after activating my new OZMO 930 which is my second Ecovacs device. The robot only communicates through port 8111 which caught my attention. It’s now pinging daily lbo.ecouser.net which is part of this mess. Unfortunately, if I block those domains the robot cannot find its map and spend an hour remapping my place then run out of battery and the cycle continues..

Comment by Nicolas Estrem — April 1, 2019 #
So the robot would not work if your Internet is down. I wonder if they have that requirement listed on the package. 🙂

Comment by robert — April 1, 2019 #
You are correct, the only control without internet is on / off; can’t even go back to charge unless it detects a low charge.

Comment by Nicolas Estrem — May 29, 2019 #

A security minded guy forced to buy a Wifi enabled cleaning robot

6 Comments »

Leave a comment