Universal Robots does not care about security. Motivated by this attitude, Alias Robotics is launching 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. We are announcing the week of Universal Robots bugs.

During the following days, Alias’ team of robotics and security researchers will dedicate resources to file openly security flaws and receive the users’ input on bugs they have found, to further advice on best security practices with these robots.

Index

Why?

Universal Robots is knowingly ignoring cyber security. We have noticed that this particular manufacturer keeps disregarding security, or at the very least, mistaking it with safety aspects purposely. The company seems to be falling into the number of obscure players lagging behind in the robotics landscape in terms of cyber security.

Back in 2019, Alias Robotics reported to Universal Robots A/S that we had found a significant amount of vulnerabilities in their UR3, UR5 and UR10 robots, across different versions of their firmware which were of relevant severity and required immediate attention. This was not in fact the first of such actions, IOActive filed in the past several vulnerabilities to the vendor without any reaction to date. We responsibly approached the manufacturer via e-mail with non-assertive answers. After no further reaction, we filed for several CVE IDs with selected vulnerabilities so that MITRE and other CNAs could help steer the conversations, with no response whatsoever.

We then, in December 2019, presented publicly in the ROS-Industrial robotics conference our findings. Within the venue and with the aim to raise awareness, we introduced Akerbeltz, the first instance of ransomware in an industrial robot, in this case UR cobots. We exploited some of the vulnerabilities found and demonstrated it publicly, but we did not make available the source code of the malware we created for the PoC, following our responsible disclosure policy. After a face to face discussion with representatives from Universal Robots A/S, present at the event, we received no acknowledgement or reaction. Conversely, members of the company, in an attempt to mitigate the communication impact, discredited our work and indicated they were not aware of any security issues that affected safety (source).

Today, more than 100 days have gone by since we first reported Universal Robots. Almost 4 months without a single security reaction. Motivated by this attitude, we are hereby and coherently launching 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. We are announcing the week of Universal Robots bugs.

Timeline of events

Alias Robotics’ responsible disclosure grace period has finished

As of 31st March 2020 the 90 day period we gave to Universal Robots of responsible disclosure has ended without further response. No security updates whatsoever have been made available for the impacted versions. No intention from the manufacturer or reaction towards the flaws reported by Alias Robotics.

Notwithstanding, it is Universal Robots A/S position that all security matters are and need to be systematically pushed to the end-user. From their perspective, security is a “functionality” or capability that needs to be added by the end-user on top of their “open robots”, not a responsibility of the manufacturer. Imagine buying a new car and getting that answer. How would you react? Robots are characteristic for the fact that they have actuators that interact with the environment. Robots can kill humans. They can incur into safety hazards as we covered in past research. Moreover, as we indicated in a recent research release:

while safety and security are distinct concepts, when it comes to connected software (non-isolated from a networking perspective), not having one implies not having the other

Now the main question that comes to our minds is: is really the end-user aware of this cyber security vulnerabilities? But also, is the community aware of how insecure these industrial robots are? and ultimately, given the “fun facts” of the supply chain of this vendor in robotics, are system integrators and distributors of Universal Robots aware of the security status of the robots they integrate and distribute? How does this connect to the increasing use of UR robots in medical applications, and the context of the current healthcare crisis?. We believe it is our responsibility to shed light on these topics and therefore, we launch the week of Universal Robots bugs.

Introducing the week of Universal Robots bugs

dia_peq-03

Earlier on in January, the manufacturer Universal Robots introduced the National Cobot awareness day in the US. Following a similar approach, we launch today the “week of Universal Robot bugs”, a community oriented effort to foster security awareness in Universal Robots robots.

Our goal is to empower end-users, distributors and system integrators of Universal Robots solutions with security information that they so much require to make use of this technology securely.

During the following days, Alias’ team of robotics and security researchers will dedicate resources to file openly security flaws and receive the users’ input on bugs they have found. We will catalogue security bugs using prior research and publicly exposing the results in the Robot Vulnerability Database (RVD). We encourage all robotics practitioners and security researchers with past experiences using Universal Robots technology to openly file a ticket at the Robot Vulnerability Database (RVD). During the coming week, our group will be triaging and consolidating everything, making it publicly accessible and available.

Our ultimate goal is to advice on best security practices with these robots and care about both, security and safety. Keep posted for our daily updates during the week.


Results

Bugs Day 1 (30th of March)

We just promised daily updates, right? Well the first day is still a day and here’re the results we disclosed or received, and made public to everyone:

ID Description
RVD#1406 UR’s felix shell console access without credentials on port 6666 (default)
RVD#1408 Bash scripts (magic UR files) get launched automatically with root privileges and without validation or sanitizing
RVD#1409 X.Org Server (before 1.19.4), replace shared memory segments of other X clients in the same session
RVD#1410 OpenSSH remote DoS in Universal Robots CB3.x
Featured bugs of day 1
RVD#1406, Apache Felix Shell defaults in Universal Robots, a big issue also in robotics

RVD#1406 shows how a lack of good security configurations leaves robots totally exposed to attackers. In this case we found that the Universal Robots Controllers has Felix Shell console application enabled on port 6666 (default one). Using a simple netcat connection, anyone with access to robot network can perform any of the several actions allowed by Felix Shell console (such as shutdown).

We recorded the exploitation of this bug using alurity:

If you’re interested on easily reproducing this issue and have an alurity license, feel free to use the alurity.yml file below:

alurity.yml file to reproduce RVD#1406
networks:
  - network:
    - driver: overlay
    - name: urnetwork
    - encryption: false

containers:
  - container:
    - name: ur_31
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         - network: urnetwork
   - container:
     - name: ur_311
     - modules:
          - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.11
          - network: urnetwork
   - container:
     - name: ur_312
     - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12
          - network: urnetwork
  - container:
    - name: ur_3121
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         - network: urnetwork
  - container:
    - name: attacker
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_robosploit/expl_robosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/deve_atom:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - network: urnetwork

RVD#1410, Denial of Service exploiting an SSH vulnerability in Universal Robots

RVD#1410 shows a) evidence that Universal Robots cares very little about security and b) the importance of having a security team working with your engineers.

This flaw was found in 2016 and assigned a CVE ID CVE-2016-6210. We confirmed that this vulnerability applies to all the latest releases from Universal Robots over the past 12 months approximately:

  • Universal Robots CB3.1, firmware version 3.12.1 (latest at the time of writing)
  • Universal Robots CB3.1, firmware version 3.12
  • Universal Robots CB3.1, firmware version 3.11
  • Universal Robots CB3.1, firmware version 3.10

Having tested this far, we’re somewhat certain that likely, if you own a UR3, UR5 or UR10, chances are your robot ships an openssh version that’s vulnerable to Denial of Service by external aunthenticated users. Particularly, we found that the Universal Robots Controllers’ file system (based in Debian) allows attackers with networking connection to the robot to cause a Denial of Service via the auth_password function in auth-passwd.c. sshd in OpenSSH, before 7.3 does not limit password lengths for password authentication, which allows remote attackers to cause a denial of service (crypt CPU consumption) via a long string.

We demonstrate it below:

asciicast

alurity.yml file to reproduce RVD#1410
##################
# alurity.yml example file
##################
networks:
  - network:
    - driver: overlay
    - name: urnetwork
    - encryption: false

containers:
  - container:
    - name: ur_310
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.10
         - network: urnetwork
  # - container:
  #   - name: ur_311
  #   - modules:
  #        - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.11
  #        - network: urnetwork
  # - container:
  #   - name: ur_312
  #   - modules:
  #        - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12
  #        - network: urnetwork
  - container:
    - name: ur_3121
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         - network: urnetwork
  - container:
    - name: attacker
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_robosploit/expl_robosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/deve_atom:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - network: urnetwork

##################
# flow for testing and development
##################

flow:
  - container:
    - name: attacker
    - window:
        - name: attacker
        - commands:
          - command: "sleep 3"
          - command: "nmap -sV -T5 ur_3121"
  - container:
    - name: ur_3121
    - window:
        - name: ur_3121
        - commands:
          - command: "mkdir /var/run/sshd"
          - command: "/usr/sbin/sshd"
          - split: horizontal
          - command: "htop"
          # - command: "glances"
    # - select: ur_3121
  - attach: attacker

Using alurity we seamlessly simulate the control box of Universal Robots. We can reproduce UR3’s, UR5’s or UR10’s control computer across different firmware versions and releases. We do so and assign a specific amount of cores and memory (dimensioning characteristics similar to the real hardware) and launch the exploit we coded with robosploit, one of alurity‘s modules. As the short clip above shows, after a few seconds, all the cores are totally overloaded with a load average above 1.0, affecting most of the robot subsystems.



Source link