Universal Robots cobots are not secure

Universal Robots, a division of Teradyne since 2015, is knowingly ignoring cyber security across their tenths of thousands of robots sold. In 2017, IOActive, a world-leader firm in cybersecurity services opened a report ^[1] where among others, described several flaws found in Universal Robots collaborative robots. These included:

• RVD#6: UR3, UR5, UR10 Stack-based buffer overflow
• RVD#15: Insecure transport in Universal Robots's robot-to-robot communications
• RVD#34: Universal Robots Controller supports wireless mouse/keyboards on their USB interface
• RVD#672: CB3.1 3.4.5-100 hard-coded public credentials for controller
• RVD#673: CB3.1 3.4.5-100 listen and execution of arbitrary URScript code

Last year, during a robotics conference, together with some colleagues and in an attempt to raise awareness and illustrate the insecurity by design in robotics we have demonstrated Akerbeltz^[2], the first known instance of industrial robot ransomware.

After months of interaction attempts, more recently and in attempt to correct this tendency of ignoring cybersecurity in robotics, Alias Robotics (disclaimer:, I currently work for this company), after several months trying to cooperate with the manufacturer launched a Week of Bugs for Universal Robots^[3]. An initiative to empower end-users, distributors and system integrators of Universal Robots with the information they so much require to make use of this technology securely.

During the 5 days of the sprint, Alias Robotics together with other contributors released dozens of bugs resulting in a total of 86 public security bugs on Universal Robots robots (source^[3:1]).

To this date, still no reaction from Universal Robots. Tenths of thousands of users are using insecure robots that might easily lead to safety hazards. This article argues about why and how we reached this situation and proposes some thoughts and advice on the matter.

Analyzing Universal Robots commercial success

Several articles cover and discuss the commercial success of Universal Robots. Often compared with Rethink Robotics, Universal Robots (UR) is generally acknowledged for reading the market better and focusing on solving the problem in a more pragmatic manner, focusing on delivering just about the needed safety capabitilies, and no more. Carol Lawrence^[4] indicates the following:

Universal succeeded because its robots were accurate and repeatable, yet safe enough to work next to people.

Anyone that has operated these robots will probably agree that it sounds about true. Instead of investing additional resources on risk assessment perspective (which from these articles I conclude Rethink Robotics did, at least better?), consider safety standards (using pre-existing norms for safety machinery and security) and focusing on human collaboration (as they were promising), Universal Robots focused on lobbying for market success. It was all about the market, and marketing.

If one pays close attention, she'll notice Universal Robots is actually behind the steering of ISO 10218-1 and ISO 10218-2. Reviewing these norms will make a roboticist scream in several senses. These norms are in many ways too tailored to a vendor. Tailored for lobbying. And likely this is the reason why ISO 10218-1/2 is not spreading as much as one would expect. Several countries have even disregarded ISO 10218-1, and their industries are not forced to comply with it.

More importantly, robots are connected devices. If one compares a robot to an IoT device she will quickly notice that such comparison makes no sense and it'd be more accurate to relate robots with IoT networks (leaving aside the actuation, rarely present in IoT). Robots may operate in an isolated manner, true, but frankly, for most applications that require additional sensing (most that demand adaptability), robots receive external control and coordination instructions from control stations. Here's a typical setup:

The collaborative behavior that Universal Robots delivers is not only flawed from a safety design perspective but also from a robotics-functionality one. These systems will end up being connected. One should care about this.

Yet, it seems it still does for clients. Specially because Universal Robots are open. Not in software, but in their architecture^[4:1]:

Universal’s business model differed from Rethink’s. Rather than provide an integrated system, it sold only robotic arms and embraced an open architecture that made it easy to add third-party sensors, cameras, grippers, and other accessories. This enabled users and integrators to customize robots for specific tasks.

Openness is great as model for innovation. I spent years working as an open source contributor first in software and hardware, then in robotics. I funded part of my early studies (as many surely did as well) enjoying summers of code funded by Google while working in different organizations. Also, while growing as a roboticist, I interned in several "open" places. Openness is also great (yet challenging) for business, I created and sold a business that contributed to the open source projects in the robotics space. Great learning experience.

Openness is great, but openness in industry needs to be a) funded and b) backed with a responsible attitude in terms of security. Without care for these matters, you're simply exposing your creations to third party attacks. When those creations can influence thousands of businesses, you should start growing concerned.

An open architecture that doesn't care about security

Delivering an open architecture doesn't mean that you can disregard security. Security by obscurity is not security, true. But neither you should open it up and just disregard it if your systems will be used in industry, by people. That pitch doesn't work when robots get out of the lab and jump into real use cases. Universal Robots is well known from claims like:

Security is up to the user.

A security-first approach must be adopted. One that goes from the design-phase, down to the post-production one. If you're interested in secure development and secure architectures, refer to some work on DevSecOps ^[5] in robotics I co-authored and released not so long ago.

The ultimate proof however comes from the facts. So let's provide some evidence. Much of it was provided within ^[3:2] but let's dig once again. Using alurity toolbox, I construct a simple environment with one of the latest Universal Robots firmware images for the robot controllers and run some simple security auditing tool:

networks:
  - network:
    - driver: overlay
    - name: urnetwork
    - encryption: false

# UR CB 3.1 firmware 3.12.1
  - container:
    - name: ur_3121
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         - network: urnetwork
    - cpus: 4
    - memory: 4096

...
[+] Initializing program
------------------------------------
  - Detecting OS...                                           [ DONE ]
  - Checking profiles...                                      [ DONE ]

  ---------------------------------------------------
  Program version:           3.0.0
  Operating system:          Linux
  Operating system name:     Debian
  Operating system version:  7.8
  End-of-life:               YES
...

Universal Robots controllers run Debian "wheezy" which was released in May 2013 and entered End-of-life (EoL) in May 2018 according to the Debian Long Term Support (LTS) page:

Some of you might be thinking that ELTS. There's Extended Long Term Support. One could think that Universal Robots is actively supporting openness (and open source) by financially supporting Debian and receiving extended support:

While plausible in terms of date, unfortunately, it doesn't seem to be the case. The results at https://news.aliasrobotics.com/week-of-universal-robots-bugs-exposing-insecurity/^[1:1][3:3] show evidence that either Universal Robots does not care about security updates, or they are struggling to produce appropriate firmware updates.

While it may sound harsh, one wonders: regardless of the investments made in marketing and communication, how much is the "openness" pitch of Universal Robots worth it?

Some final thoughts and advice

Request security mitigations

These's evidence that Universal Robots produces insecure technology as per their latest "fixes". In case you're using Universal Robots technology, here's a start for you: turn to your System Integrator and demand security updates. Turn to your distributor and request advice on good security practices. Ultimately, turn to Universal Robots and demand mitigations for (at least) all the known flaws.

Search for security solutions for robots

Beyond vendor security patches, you should care about reducing the attack surface of your robotic applications. You should care about security for robots. One of such solutions is described within ^[3:4]:

Alias Robotics advises Universal Robots users is to take action immediately and seek for existing security solutions for these robots and urge Universal Robots to take security seriously and conduct further assessments to mitigate their insecurity and offer their customer safe robots.