Later this past month, our lab welcomed a very important individual: Robi the robot (it has a camera and speakers!). We also received the honors to assemble it and make it dance. And so the journey to the fields of the unknown started. While playing with the command and control software, I could not help but wonder how secure this really is.

First of all, from the start I expected some kind of bluetooth link (blueborne *cough cough*) but I was actually greeted with it’s very own WiFi network board . It has the capability to join an existing network but by default it also comes with an open AP with a suggestive SSID. From the start, I also encountered a defense mechanism which is defined by allowing only a single C&C connection to be established with another machine.

By further inspecting the C&C mobile software, I saw the IP address which confirmed to be the gateway/WiFi manager interface. After a quick scan, the identified number of open ports:

1. 23 for the incoming C&C communication;
2. 24 is used for live camera streaming;
3. 80 for the web interface;
4. 8080 for the CLI.

So the main scope was to get access to the underlying structure (or the OS level) to see the inside core of it. Fortunately, I did not accomplish this goal, yet.

I first analyzed the WiFi Access Point that is embedded in the robot’s motherboard. It comes with an open network which is not protected by a WPA/WPA2 PSK password by default. Also, no authentication mechanism is present when connecting to port 80 which is the web management interface.

These characteristics are improving the user experience but greatly reduce the protection of the robot. On further inspection, it does not present any configurable settings regarding the web application authentication mechanism on access.

List of vulnerabilities identified on course of the research project:

1. Persistent XSS in management web interface;
2. CLI accessible without authentication (or making robot move from console);
3. Functional logic bypass;
4. Reflected XSS (working on IE with compatibility mode 🙂 );
5. Open redirect;
6. CSRF for DoS situation.

I continued into making an in-depth analysis over the web application. First parameter I came across was the System name. As expected, the name can be fully personalized so why not go for an XSS payload.

And indeed, the value of the System name does not seem to be sanitized and it’s further stored and reflected in the browser. In my opinion, this particular vulnerability can endanger the security of the user/owner because it can give an attacker the opportunity to mount spear phishing attacks effectively.

Furthermore, only by accessing the web page, the victim will become partially/totally aware of the attack because the SSID can also be vulnerable but there’s a catch. Unlike the System name, the injected payload will also appear in the AP list of the network scanning which will trigger alarms.

Sticking with the web interface, I also noticed that the parameter variable is reflected in the web page but no luck here as the Content-Type returns text/plain. However, it does imply some threat on the IE users with compatibility mode on 🙂 . Yeah, moving on.

At some point, the application redirects the user to one of the websites’ pages via the value of a GET parameter named 01. We can abuse this parameter and redirect the user to arbitrary chosen addresses. Again, this can be used to redirect the target to a phishing site.

A very interesting feature of the robot is the port 8080 which, when connected to it, reveals a nice CLI with a long list of functionalities. The bad part is that the service does not present any form of authentication/authorization.  Among the functionalities we can note actions such as memshow, memdump, memset and flash memory map (which are great for trying to get access to the juicy OS level, but this one is still in progress and needs more attention).

One of the functionalities defined as servo allows us to actually move one of the 72 servo motors of the robot with a given speed. This action actually bypasses the functional logic of the overall system. Why? Because the user needs to create an account and login before downloading the desktop/extended mobile application in order to interact with the robot.

Also, in order to use the servo command, 2 input parameters must be given. First one is the servo motor port. When assembling the robot and connecting the rotors, 3 bus circuits are presented on the main motherboard, each one containing a different number of ports. These ports are named Dxy where xy are numbers from 0 to 23. The other one is the rotation power or the angle of rotation for the arbitrary chosen rotor.

After the successful interaction with the robot’s motors, I turned my attention to the embedded camera placed on the robot’s head. I had some unsuccessful tries to properly interpret the streamed input coming from the port 24 until I came across the SDK made available by developers. The SDK archive contains examples that are interpreting the video streaming. The attack scenario can be an unauthorized attacker being able to capture camera streaming and successfully use or move the robot with the help of public SDK, CLI or self implemented programs.

From my perspective, there are a couple of attack vectors from which the attacker is able to interact with the robot:

1. The robot is running with the embedded open WiFi which is implemented by default;
2. The robot is connected to a common network that the attacker has access to;
3. The attacker manages to capture and crack robot’s embedded WiFi password supposing that the WiFi is configured to be password protected.

So, if somebody (our friendly neighbor 🙂) has a robot prone to the mentioned attack vectors, this can lead to unwanted privacy breaches. We can all imagine what could go wrong with this.

Getting back to the web part of the analysed system, I wanted to know more about the network functionality of the robot. So apparently, from the desktop and mobile interface, the user can scan for Access Points and find a common one with the robot. Apart from user joining the robot’s own AP, the user can opt to make the robot join an existing network (open or password based, no certificate login support).

The problem rises when the user mistakenly sets up bad configuration for network login. So, from the web management application, if the user enters a bad SSID or password, the robot will fail to login and speak a suggestive message. Now, the problem is that the user cannot actually connect back to the robot to correct the mistake because:

1. The user connects to the robot’s free WiFi so he can access the robot’s web application to setup network login;
2. If the network login is configured, the robot will cut down the free WiFi and try to use another specified network;
3. At every startup he will try to join the network, will fail and enter stand-by mode.

So the user is now stuck with the robot being unable to join a network. A hard reset must be applied by the user in order to get the fresh robot back in place (spoiler alert, can be frustrating). This flaw can also be abused by an attacker who has network access to the robot or he can make use of a Cross-Site Request Forgery attack in order to cause a Denial of Service situation over the robot’s availability.

Given the fact that the robot is operating on WiFi level, plausible attack scenario can look something like this:

1. Deauthenticate client/owner from WiFi to disrupt C&C connection;
2. Connect on the WiFi if open / search robot if it’s inside common network;
3. Access the web application & make use of stored XSS;
4. Control robot using CLI;
5. Casually spy the surroundings using camera;
6. Cause a Denial of Service situation (force owner’s hard reset over robot).

Over all it was truly a fun experience and the whole interaction with the robot was really great. On the first use it needs some re-calibrations but the robot and the software presents a background  that can be fully customized depending on needs.

Just like every other new technology area, it needs improvements along the way, especially on a relatively new field like Robotics and given the early stages of it’s development. I am glad I can take part in this process and offer help. I contacted the providers and they agreed to make a research blog post about this.

Thank you and cheers !