This study sums up the penetration testing exercise conducted during the Week of Universal Robots’ bugs. The aim of
this risk case study was to provide a practical assessment of the UR3, UR5 and UR10 robot insecurities, including vulnerabilities and bugs that affect them. Before the exercise, there were 5 reported vulnerabilities for these
collaborative robots. After the penetration testing assessment, more than 80 were available, many with PoC exploits demonstrated with recordings.
In an attempt to raise awareness and invite the manufacturer to react, this robot test case study demonstrated the insecurity landscape of Universal Robots' UR series of collaborative robots across firmware versions, which require immediate attention. Relevant attacks were demonstrated showing how these collaborative robots are vulnerable to a variety of attacks including simple dictionary attacks on exposed networking services, Person-In-The-Middle (PITM) attacks between the controller and the robot, physical attacks over unprotected exposed ports with privileged access and more. To the extension of our resources, we confirmed the lack of encryption, authentication or authorization enabled capabilities across the UR10, UR5 and UR3 collaborative robots in firmware versions 1.10.0, 1.11.0, 1.12.0, 1.12.1 and 1.13.0.
Collaborative robots like these need to consider cyber security seriously. The so called "air gaps" in industry are not presented anymore with Industry 4.0. Universal Robots provides no mechanisms or countermeasures to protect their robots against cyber-threats. Without security measures, collaborative robots present a real threat to humans cooperating with them. Our penetration testing exercise concluded urging system manufacturers, integrators, distributors and end-users to perform security assessments like these periodically to detect security flaws and prevent these robots from being easily targeted.
This penetration testing case study was carried out in the time frame of a working week (5 days), in which Alias Robotics’ team of robotics and security researchers openly filed security flaws, processed bugs and exploited
vulnerabilities live. See the original blog post for a walkthrough and progresses over each day.
We gathered our results and made them openly available in the Robot Vulnerability Database (RVD), where the triaged security flaws found by our team were cataloged. This way and through RVD, we allow the whole community to openly review our work, submit improvements and contribute filing tickets with new bugs. Our pentesting methodology for robots consists of 9 steps as depicted below:
By the end of the week, a total of 86 security flaws were found reported in RVD for Universal Robots. Attack PoCs were demonstrated for some of the vulnerabilities proving how attackers may profit them for several purposes. In addition,
several of the vulnerabilities found received new CVE IDs. Watch some of the robot insecurity demonstrations in the playlist we prepared or read about selected vulnerabilities below.
We found that the Universal Robots CB 3.1 controllers' file system, based in Debian, are subject to CVE-2016-6210 which allows attackers with networking connection to the robot to cause a Denial of Service (DoS).
The auth_password function in auth-passwd.c within sshd of OpenSSH before 7.3 does not limit password lengths for password authentication. This allows remote unathenticated attackers to cause a denial of service (crypt CPU consumption) via a long string. Robot controllers with firmware versions 3.13.0, 3.12.1, 3.12.0, 3.11.0 and 3.10.0 have been confirmed to be vulnerable.
OpenSSH version prior to 7.3 does not limit the password length for authentication. Hence, to exploit this vulnerability we reuse previous similar approches and send crafted packages with 90000 characters in length to the 'password' field while attempting to log in from a remote machine via ssh, with username as 'root'. From our triaging, it appears earlier firmware versions might also be subject to this flaw.
The video demonstrates how after shipping the exploit, in a short period of time, the subject attacked gets all its cores saturated. When tested in hardware we obtained identical results with unpredictable and erratic behavior in the robot's motion.
The Universal Robots CB 3.1 controllers with firmware versions 3.13.0, 3.12.1, 3.12.0, 3.11.0 and 3.10.0 (as far as tested) present a default OpenSSH version that allows for unathenticated and unathorized external and remote user enumeration using time-based attacks. From our research, before 7.3, OpenSSH uses SHA256 or SHA512 cryptographic hash algorithms for user password hashing. The daemon uses BLOWFISH hashing on a static password when the username does not exist, which allows remote attackers to enumerate users by leveraging the timing difference between responses when a large password is provided.
We demonstrate this vulnerability in the exploit PoC below.
OpenSSH SSH daemon allows user enumeration through timing differences when trying to authenticate users. When sshd tries to authenticate a non-existing user, it will pick up a fixed fake password structure with a hash based on the BLOWFISH algorithm. If real users passwords are hashed using SHA256/SHA512, then a remote attacker can take advantage of this flaw by sending large passwords, receiving shorter response times from the server for non-existing users.
The video demonstrates how robosploit is used to manually define a few users and launch the exploit against the remote Universal Robots CB 3.1 controller with firmware version 3.12.1.
This is one of the most concerning bugs found.
Universal Robots control box CB 3.1 across firmware versions (tested on 3.13.0, 3.12.1, 3.12.0, 3.11.0 and 3.10.0) 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 remote access to the robot (while in combination with other flaws) to retrieve and easily exfiltrate all installed intellectual property.
Since URCaps aren't secured, its extraction requires attackers to access the file system (remotely or locally) and extract it from '/root/.urcaps/' folder. Resulting files are plain zip files. The video shows how a simple dictionary attack chained with a simple exploit allows an attacker to exfiltrate all intellectual property within the robot. Variations of this are possible and may imply encrypting the IP, removing or tampering with it.
A total of 81 security bugs were made public and triaged, but many more still remain private and require further triaging efforts. According to our archive, over 400 bugs have been discovered in for Universal Robots collaborative robotic
arms. This is yet an additional indication of the risk that these robots can pose, but also, at the same time, the added value of penetration testing services which can in a short period amount of time generate actionable security items.
The final results depict the relevance and severity of the insecurities found in UR robots. From the total 86 vulnerabilities released, the 76% have an RVSS (and CVSS) severity score of high (7.0) or higher, this is, a critical or high severity.
Inspired by the human immune system and developed according to latest research in robotics, data science, biology and cybersecurity, the Robot Immune System (RIS) is a modular Robot Endpoint Protection Platform (REPP). RIS is an integrated suite of endpoint protection technologies for robots including a next-gen antivirus, hardening for known robot flaws, data encryption, intrusion prevention mechanisms, data loss prevention, and more that detects, prevents, stops and informs on a variety of threats that affect the robotic system. RIS has 5 modules available, offering different Security Levels (SL) matching your security needs: