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

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 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 , 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 and 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 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) . 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:

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

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:

ID Description RVD#1411 In glibc 2.26 and earlier there is confusion in the usage of getcwd() by realpath(), buffer underflow and potential code execution RVD#1412 Integer overflow in the get_data function, zipimport.c in Python 2.7 RVD#1413 User enumeration in Universal Robots Control Box CB3.x RVD#1414 Catastrophic backtracking in pop3lib's apop() method, python before version 2.7.15 RVD#1415 GNU C Library (aka glibc or libc6) before 2.25 creates execution contexts incompatible with ARM EABI, which might cause a denial of service RVD#1416 UnZip 6.0 allows remote attackers to cause a denial of service (infinite loop) via empty bzip2 data in a ZIP archive RVD#1417 Urllib in Python 2.x through 2.7.16 supports the local_file RVD#1418 CPython (aka Python) up to 2.7.13 is vulnerable to an integer overflow RVD#1419 Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause a denial of service (crash) via a crafted bzip2 file RVD#1420 Integer overflow in shadow 4.2.1 allows local users to gain privileges RVD#1421 The path autocompletion feature in Bash 4.4 allows local users to gain privileges via a crafted filename starting with a " (double quote) character and a command substitution metacharacter RVD#1422 rbash in Bash before 4.4-beta2 did not prevent the shell user from modifying BASH_CMDS, thus allowing the user to execute any command with the permissions of the shell RVD#1423 The dump_callback function in SQLite 3.20.0 allows remote attackers to cause a denial of service RVD#1424 Bash before 4.4 allows local users to privilege escalation

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.

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

ID Description RVD#1425 It was discovered the fix for CVE-2018-19758 (libsndfile) was not complete RVD#1426 A truncated packet can cause that SSL/TLS server or client to perform an out-of-bounds read RVD#1427 The malloc function in the GNU C Library 2.2 Could lead to a heap overflow RVD#1428 The FTP wildcard function in curl and libcurl before 7.57.0 allows DoS RVD#1429 Null pointer dereference vulnerability causes TLS/SSL server using NSS to crash RVD#1430 Crafted file can lead to a DoS due to a memory alocation failure in elfutils RVD#1431 libgcrypt before version 1.7.8 is vulnerable to a cache side-channel attack RVD#1432 The GNU C Library (aka glibc or libc6) before 2.27 contains an off-by-one error leading to a heap-based buffer RVD#1433 The http.c skip_short_body() function is called in some circumstances RVD#1434 A remote code execution vulnerability in libxml2 could allow execution of arbritary code RVD#1435 elflint.c in elfutils 0.168 does not validate the number of sections nor segments allowing a DoS Attack RVD#1436 A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 RVD#1437 The allocate_elf function in elfutils before 0.168 allows remote attackers to cause a DoS RVD#1438 The check_symtab_shndx function in elfutils 0.168 allows remote attackers to cause a DoS RVD#1439 The fnmatch function in the GNU C Library (aka glibc or libc6) DoS via a malformed pattern RVD#1440 A buffer overflow was discovered in libxml2 20904-GITv2.9.4-16-g0741801 RVD#1441 Directory traversal vulnerability in the safer_name_suffix function in GNU tar RVD#1442 libXcursor before 1.1.15 has various integer overflows that could lead to heap buffer overflows RVD#1443 UR dashboard server enables unauthenticated remote control of core robot functions RVD#1444 RTDE Interface allows unauthenticated reading of robot data and unauthenticated writing of registers and outputs RVD#1446 A heap buffer overflow in the TFTP receiving code allows for DoS

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

Bugs Day 4 (2nd of April)

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

ID Description RVD#1447 Carry propagating bug in the Broadwell-specific Montgomery multiplication procedure in OpenSSL 1.0.2 and 1.1.0 before 1.1.0cspecific Montgo RVD#1448 The glob function in glob.c in the GNU C Library contains a buffer overflow unescaping names with ~ operator RVD#1449 OoB Write will cause Mozilla Network Security Services to crash on various iterations from 3.21.4 to 3.30.1 RVD#1450 Integer overflow in the GNU C Library before 2.22 allows context-dependent attackers to cause a DoS RVD#1451 There is an overflow bug in the AVX2 Montgomery multiplication procedure RVD#1452 Memory leak in the res_vinit function in the IPv6 name server code in libresolv in glibc before 2.24 causes a DoS RVD#1453 Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free RVD#1454 Double free vulnerability in JasPer 1.900.17 allows remote attackers to cause a DoS RVD#1455 A buffer overflow in glibc 2.5 which can be triggered through the LD_LIBRARY_PATH environment variable RVD#1456 Stack-based buffer overflow in the getaddrinfo function in getaddrinfo.c in glibc allows a DoS attack RVD#1457 An invalid memory address dereference in elfutils through v0.174. that allows attackers to cause a DoS RVD#1458 idn in GNU libidn before 1.33 might allow remote attackers to obtain sensitive memory information RVD#1459 Use-after-free vulnerability in bzip2 1.0.6 allows remote attackers to cause a DoS RVD#1460 Untrusted search path vulnerability in ssh-agent.c in OpenSSH before 7.4 allows remote attackers to execute arbitrary local PKCS#11 modules RVD#1461 Integer overflow in the strxfrm function in the GNU C Library before 2.21 allows to cause a DoS RVD#1462 The shared memory manager in sshd in OpenSSH before 7.4 does not ensure that a bounds check is enforced by all compilers RVD#1463 The OpenSSL RSA Key generation algorithm is vulnerable to a cache timing side channel attack RVD#1464 CRLF injection is possible due to an issue discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3

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

ID Description RVD#1465 getchar.c in Vim before 8.1.1365 and Neovim before 0.3.6 allows remote attackers to execute arbitrary OS commands RVD#1466 glibc allows specially crafted LD_LIBRARY_PATH values to manipulate the heap/stack RVD#1467 Some python versions 2.7/3.7. are vulnerable to DoS via catastrophic backtracking RVD#1468 http.cookiejar.DefaultPolicy.domain_return_ok in Python before 3.7.3 can be tricked into sending existing cookies to the wrong server RVD#1469 The email module in Various Versions of Python 2 and 3 wrongly parses email addresses that contain multiple @ characters RVD#1470 vim before patch 8.0.0056 does not properly validate values for 'filetype', 'syntax' and 'keymap' options RVD#1471 libgcrypt before version 1.7.8 is vulnerable to a cache side-channel attack resulting into a complete break of RSA-1024 RVD#1472 CRLF injection vulnerability in the HTTPConnection.putheader function in urllib2 and urllib in CPython before 2.7.10 and 3.x before 3.4.4 RVD#1473 GNU wget before 1.18 allows remote servers to write to arbitrary files RVD#1474 Python version 2.7 contains a vulnerability in shutil module that can result in DoS and Information gain via injection of arbitrary files on the system or entire drive RVD#1475 Modules/pickle.c in Python before 3.7.1 has an integer overflow might that can cause memory exhaustion RVD#1476 CPython up to 2.7.13 is vulnerable to an integer overflow in the PyString_DecodeEscape function in stringobject.c RVD#1477 The CGIHandler class in Python before 2.7.12 does not protect against the HTTP_PROXY variable RVD#1478 Sqlite3 3.26.0 vulnerability exists in the window function potentially resulting in remote code execution RVD#1479 Python's elementtree C accelerator failed to initialize Expat's hash salt during initialization RVD#1480 An exploitable denial-of-service vulnerability exists in the X509 certificate parser of Python.org Python 2.7.11 / 3.6.6. RVD#1482 The add_probe function in modutils/modprobe.c in BusyBox before 1.23.0 allows local users to bypass intended restrictions on loading kernel modules RVD#1483 The smtplib library in Python 2.7.12, 3.x before 3.4.5, and 3.5.x before 3.5.2 does not return an error when StartTLS fails RVD#1484 Python 2.7.14 is vulnerable to a Heap-Buffer-Overflow as well as a Heap-Use-After-Free RVD#1485 A race condition in util-linux before 2.32.1 in su could be used to kill other processes with root privileges RVD#1487 No integrity checks on UR+ platform artifacts when installed in the robot RVD#1488 The expansion of '\h' in the prompt string in bash 4.3 allows arbitrary code execution. RVD#1489 Unprotected intelectual property in Universal Robots controller CB 3.1 across firmware versions RVD#1490 procps-ng before version 3.3.15 is vulnerable to multiple integer overflows leading to a heap corruption which could result in crashes or arbitrary code execution RVD#1491 Stack-based buffer overflow in the glob implementation in GNU C Library (aka glibc) allows context-dependent attackers to cause a denial of service (crash) via a long name RVD#1492 Improper Handling of Unicode Encoding during NFKC normalization on python 2.7.x through 2.7.16 and 3.x through 3.7.2 RVD#1493 CRLF injection vulnerability in Python before 2.7.10 and 3.x before 3.4.4 allows remote attackers to inject arbitrary HTTP headers RVD#1494 Not sanitizing filenames in the add_match function in libbb/lineedit.c in BusyBox through 1.27.2 when tab autocompleting filenames RVD#1495 Universal Robots URCaps execute with unbounded privileges

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 :).

alurity.yml file to reproduce RVD#1410 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: