The week of Universal Robots' bugs

Universal Robots does not care about security. Motivated by this attitude, Alias Robotics is launching an initiative to empower Universal Robots' end-users, distributors and system integrators 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 openly file security flaws and receive users' input on the bugs they've found, to further advize on best security practices with these robots.

Index

• Rationale
• Intro
• Results
  • Bugs Day 1 (30th of March)
  • Bugs Day 2 (31st of March)
  • Bugs Day 3 (1st of April)
  • Bugs Day 4 (2nd of April)
  • Bugs Day 5 (3rd of April)

Why?

Universal Robots is knowingly ignoring cyber security. We've noticed that this particular manufacturer keeps disregarding security, or at the very least, purposely mistaking it with safety aspects. 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, in the past IOActive filed several vulnerabilities^[1] 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, still no response.

We then, in December 2019, publicly presented our findings in the ROS-Industrial robotics conference. Within the venue and with the aim to raise awareness, we introduced Akerbeltz^[2], the first instance of ransomware in an industrial robot, in this case UR cobots. We exploited some of the vulnerabilities we found and demonstrated them publicly, but we did not make the source code of the malware we created for the PoC available, 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 that they were not aware of any security issues that affected safety (source).

Today, more than 100 days have gone by since we first reported to Universal Robots, which is 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 have been made available, whatsoever, 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^[3]and as we indicated in a recent research release^[4]:

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^[4:1]

Now the main questions that come to our minds are: Is the end-user really aware of these cyber security vulnerabilities?, 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

Earlier on in January, the manufacturer, Universal Robots, introduced the National Cobot awareness day in the US. Following a similar approach, today we launch 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 the security information they so much require to securely make use of this technology.

During the following days, Alias' team of robotics and security researchers will dedicate resources to openly file security flaws and receive the users' input on bugs they've found. We will catalogue security bugs using prior research and will publicly expose the results in the Robot Vulnerability Database (RVD)^[5]. 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 advize on best security practices with these robots regarding, both, security and safety. Keep posted for our daily updates during the week.

Results

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.

The final results not only show us the significant amount of flaws Alias Robotics' team was able to triage and openly publish during a week, but also the importance and severity of these insecurities.76% of the bugs found in Universal Robots have a CVSS severity score of high (7.0) or higher.

At the time of writing, more than 80 security bugs have been found exploitable (confirmed vulnerabilities). We demonstrated attacker PoCs and several of the bugs received new CVE IDs. In addition, in an attempt to raise awareness and empower end-users, integrators, distributors and other players in the supply chain with relevant security information, we've produced exploits and videos to demonstrate the insecurity. Some of the videos produced are available in the week of Universal Robots bugs playlist.

Our advise to users is to take action immediately and seek for existing security solutions for these robots. Still, to ensure no bad actors can directly benefit from our work, the exploits produced during the week will not be open sourced. Instead, the exploits for robots will be available for research purposes via alurity, our robot cybersecurity toolbox. Requiring a license and meant for academic or industrial research purposes, alurity is a modular and composable toolbox for robot security. Featuring dozens of different robot cyber security tools, it simplifies and speeds up the cyber security research in robotics. Particularly, exploits of this week of Universal Robots bugs have been embed into robosploit, our robot exploitation framework (available as part of alurity).

Beyond this sprint, led by Alias Robotics, the total count of potential bugs identified in Universal Robots products does not decrease. Quite the opposite, it continues to grow. As of now, our team accounts for more than 400 security bugs affecting several of the robots of Universal Robots including the UR3, UR5 and UR10. We urge Universal Robots to take security seriously and conduct further assessments to mitigate their insecurity and offer their customer safe robots (note that there is no safety without security).

Bugs Day 1 (30th of March)

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

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)^[6].

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:

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, 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:

##################
# 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.

Bugs Day 2 (31st of March)

Day 2 wasn't dissapointing :)! We processed and released a total of 14 bugs, many of them highlighting how much Universal Robots needs to invest in security to properly serve its users (regardless of what their current communication strategy is). The following video shows one of such flaws:

Our team developed a simple exploit that renders the robot's User Interface (the so called teach pendant) useless, due to non configured limits on the Operating System.

We leave it to the the reader's imagination to figure out the potential impact of this in an industrial environment.

Below, find a summary of all our releases from today:

As many have repeatedly said in the past, security is not a product but a process; it is constantly evolving. New security flaws are found everyday and it's up to the whole robotics supply chain to react appropriately (manufacturers, distributors, integrators and end-users).

Featured bugs of day 2

RVD#1416, UnZip 6.0 allows remote attackers to cause a denial of service (infinite loop) via empty bzip2 data in a ZIP archive

This is a fun one, so we decided to make a exploit, add it to robotsploit and record it. UR3, UR5 and UR10, powered by CB3.1 (with all the firmware versions we tested), are vulnerable to this security bug. A lack of security maintenance of UnZip allows one to perform Denial of Service. The video below shows how we can prevent the system from operating in normal conditions by simply unzipping a specially-crafted zip file.

RVD#1411, an old glibc version allows buffer underflow and arbitrary code execution

This bug captures and demonstrates one of the main issues existing in Universal Robots' robots. glibc, one of the core packages on a Linux-based Operating System, is not well maintained, nor updated. Due to this, a buffer underflow bug allows for privilege escalation and arbitrary code execution.

Note that superuser (root) privileges can offer full access to an intruder providing full control of the robot file system and coherently, its behavior. These kind of attacks are really hard to detect without an Endpoint Protection Platform (EPP) solution.

RVD#1412, un-updated Cpython can be use for remote attackers to have unspecified impact via a negative data size value, which triggers a heap-based buffer overflow.

Cpython is one of the libraries shipped within UR's file system and as many other software blocks, it is also not well maintained. In this case, the lack of security reviews empowers an attacker to trigger head-based buffer overlows that can cause unspecified impact. With robots, this can lead to unexpected behaviors affecting safety and/or real-time (determinism, not real-fast^[7]) routines.

A similar vulnerability is described at RVD#1418.

Bugs Day 3 (1st of April)

Day three was a success! We recorded and triaged 20 security bugs! Most excitingly, we filed for several CVE IDs among these bugs and got contributions from two researchers: Bernhard Dieber and Benjamin Breiling, each of them got a CVE ID :). Below you can find a summary of all today's releases:

Featured bugs of day 3

RVD#1443 UR dashboard server enables unauthenticated remote control of core robot functions

Credit to Bernhard Dieber for submitting this ticket!

Universal Robots' Robot Controllers Version CB2.x SW Version 1.4 upwards, CB3.x SW Version 3.0 and upwards, e-Series SW Version 5.0 and upwards expose a service called DashBoard server at port 29999 that allows for control over core robot functions like starting/stopping programs, shutdown, reset safety and more. The DashBoard server is not protected and lacks any kind of authentication or authorization.

The following videos illustrates its exploitation:

RVD#1413: User enumeration in Universal Robots Control Box CB3.x

We found that the Universal Robots' Controllers' file system based in Debian is subject to CVE-2016-6210 which allows attackers to perform unauthenticated user enumeration. The flaw affects OpenSSH which is exposed by default in port 22.

The reason why OpenSSH is vulnerable is because before version 7.3, when SHA256 or SHA512 are used for user password hashing, it uses BLOWFISH hashing on a static password when the username does not exist. This allows remote attackers to enumerate users by leveraging the time difference between responses when a large password is provided, figuring out which users are valid and which ones aren't.

If you wish to reproduce this, give it a try with alurity and the following alurity configuration file:

##################
# 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

Bugs Day 4 (2nd of April)

Find below a summary of all our releases today, 18 bugs:

Featured bugs of day 4

RVD#1412: Integer overflow in the get_data function, zipimport.c in Python 2.7

In this bug we explored an integer overflow in the get_data function in zipimport.c in CPython (aka Python) before 2.7.12, 3.x before 3.4.5, and 3.5.x before 3.5.2 allows remote attackers to have unspecified impact via a negative data size value, which triggers a heap-based buffer overflow.

The video below demonstrates how this flaw affects firmware versions CB3.1 1.12.1, 1.12, 1.11 and 1.10. Beyond our triaging is testing earlier version but we can only guess that it'll follow along. Further exploitation of the heap-based overflow is beyond the scope of this simple exercise but a sufficiently motivated attacker won't certainly stop here ;).

Take a look below at the alurity.yml file, a configuration file for alurity that allows to launch this exact same scenario to seamlessly reproduce our results :).

##################
# 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_312
    - window:
        - name: ur_312
        - commands:
          - command: "ifconfig"

  - container:
    - name: ur_311
    - window:
        - name: ur_311
        - commands:
          - command: "ifconfig"

  - container:
    - name: ur_310
    - window:
        - name: ur_310
        - commands:
          - command: "ifconfig"

  - 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

Bugs Day 5 (3rd of April)

Find below a summary of all our releases the fifth day of the sprint:

Featured bugs of day 5

Last day! Since that's the case, we decided to feature some additional bugs and give you a better sense of intuition of the current insecurity that UR3, UR5 and UR10 robots present.

Note: from external contributions, we confirmed that many of these security bugs also apply to e-Series Universal Robots robots

RVD#1487: No integrity checks on UR+ platform artifacts when installed in the robot

The process of installing a URCap have no integrity checks, that can result on installing a malicious application for the industrial robot:

RVD#1489: Unprotected intelectual property in Universal Robots controller CB 3.1 across firmware versions

This is one of the most concerning bugs found. Connected to RVD#1487, the lack of protected Intellectual Property (IP) from third parties allows an attacker to exfiltrate all intellectual property living into the robot and acquired from UR+ platform or other means.

More specifically and as described in our report:

Universal Robots control box CB 3.1 across firmware versions (tested on 1.12.1, 1.12, 1.11 and 1.10) does not encrypt or protect in any way the intellectual property artifacts installed from the UR+ platform of hardware and software components (URCaps). These files (.urcaps) are stored under '/root/.urcaps' as plain zip files containing all the logic to add functionality to the UR3, UR5 and UR10 robots. This flaw allows attackers with access to the robot or the robot network (while in combination with other flaws) to retrieve and easily exfiltrate all installed intellectual property.

The following video demontrates this process chaining the attack with other vulnerabilities.

To take a closer look at this exploit, check out the alurity.yml file, a configuration file for alurity that allows to launch this exact same scenario to seamlessly reproduce our results :).

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

containers:
  - 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

  - 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"
          - type: "nmap -sV -T5 ur_3121"

  - container:
    - name: ur_3121
    - window:
        - name: gui
        - commands:
          - type: "source /root/run_gui.sh && $RUN_GUI"
          # - command: "source /root/run_gui.sh && $RUN_GUI"
    - window:
        - name: urcap
        - commands:
          # Launch ssh daemon
          - command: "mkdir /var/run/sshd"
          - command: "/usr/sbin/sshd"
          # # Fetch ROS Industrial driver's UR cap
          - command: "cd /root/.urcaps && wget https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/raw/master/ur_robot_driver/resources/externalcontrol-1.0.1.urcap"
          # Fetch a commercial dashboard solution for evaluation
          - command: "cd /programs && wget https://github.com/KimNyholm/web-dashboard-urcap/archive/v2.1.0.zip && unzip v2.1.0.zip"
          # Force install it
          - command: "cp /programs/web-dashboard-urcap-2.1.0/webdashboard-2.1.0.urcap /root/.urcaps"
          - split: horizontal
          - command: "htop"
  - attach: ur_3121

RVD#1444: RTDE Interface allows unauthenticated reading of robot data and unauthenticated writing of registers and outputs

This vulnerability found by Bernhard Dieber, Benjamin Breiling (and many others), shows the capacity to read and write internal robot configuration using an unauthenticated port. The video below shows the process:

More specifically, Universal Robots controller CB3 SW Version 3.3 and upwards, e-series SW Version 5.0 and upwards allow authenticated access to the RTDE (Real-Time Data Exchange) interface on port 30004 which allows setting registers, the speed slider fraction as well as digital and analog Outputs. Additionally unauthenticated reading of robot data is also possible.

RVD#1495: Universal Robots URCaps execute with unbounded privileges

Another issue that found related to the URCaps, is that there is no resource limitation on the OS that could end on an useless teach pendant:

RVD#1424: Bash before 4.4 allows local users to privilege escalation

Three days, ago our team released a vulnerability on privilege escalation due to a vulnerability on bash. Even if the system have a non root user, due to a non update bash package you can execute commands as root: