With its growing use in industry, ROS is rapidly becoming a standard in robotics. The commonly held assumption that robots are to be deployed in closed and isolated networks does not hold any further and while developments in ROS 2 show promise, the slow adoption cycles in industry will push widespread ROS 2 industrial adoption years from now. ROS will prevail in the meantime so we wonder, can ROS be used securely for industrial use cases even though its origins didn't consider it? The present study analyzes this question experimentally by performing a targeted offensive security exercise in a synthetic industrial use case involving ROS-Industrial and ROS packages.
We select one of the most common industrial robots with ROS-Industrial support (Universal Robots UR CB3.1 series) and configure an industrial environment applying security measures and recommendations. In particular, the scenario presents a network segmented in 5 levels with segregation implemented following recommendations in NIST SP 800-82 and IEC 62443 family of standards. There’re 6 identical robots from Universal Robots presenting a variety of networking setups and security measures, each connected to their controller, which then may or may not get connected to a control station running the corresponding ROS-I driver. The ROS computational graph is mastered by a central control station.
Our exercise results into 4 groups of attacks which all manage to compromise the ROS computational graph and all except one take control of most robotic endpoints at desire. Given our assumptions, results do not favour the secure use of ROS in industry today however, we managed to validate the security of certain robotic endpoints and remain optimistic about securing the ROS computational graph providing a number of future directions to consider.
The use case will involve several robots with their corresponding de facto controllers. Most of them presented as provided by the manufacturer and some others hardened. For robot (endpoint) hardening we will use a commercial Robot Endpoint Protection Platform (REPP) solution, the Robot Immune System (RIS), an integrated suite of endpoint protection technologies for robots that detects, prevents, stops and informs on a variety of threats that affect the robotic system.
Alias Robotics engineers
ATTACK 1
In this attack we adopt the position of an attacker with access and privileges in a development machine D1 in the IT side of the scenario, Level 4.
STEP 1: Intrusion in IT
Reaching such machine is beyond the scope of this particular study but generally consists of an attacker using either a Wide Area Network (WAN) (such as the Internet) or a physical entry-point to exploit an existing vulnerability in the development machine D1 and obtain a certain amount of privileges.
STEP 2: Take control of dev.station
A privilege escalation will be performed by the exploitation of additionally vulnerable services, which allows the attacker to eventually gain privileges into D1 and command it as desired.
STEP 3: Exploit vulnerability
From D1, an attacker would pivot into Level 3 by exploiting a vulnerability in the ROS core and/or ROS-Industrial packages.
STEP 4: Reverse shell
Having gained control of the Central Control Station S7 the attacker could decide to establish a reverse channel of communications directly –avoiding the developer station– .
STEP 5: Control as desired
Or the attacker could proceed to control Operational Technology (OT, Level 2 and below) by sending commands via the ROS computational graph.
ATTACK 2
As pointed out previously, ROS-Industrial software builds on top of ROS packages which also build on top of traditional networking protocols at OSI layers 3 and 4. It’s not uncommon to find ROS deployments using IP/TCP in the Network and Transport levels of the communication stack. For the purpose of further testing the limits of testing these underlying layers and its impact in ROS, we developed a complete ROSTCP networking package dissector and used it as a tool for attacks. The attack consists of a malicious attacker with privileged access to an internal ROS-enabled control station (e.g. S1) disrupting the ROS-Industrial communications and interactions of others participants of the network. The attack leverages the lack of authentication in the ROS computational graph previously reported in other vulnerabilities of ROS such as RVD#87 or RVD#88.
Without necessarily having to take control of the ROS computational graph via attacks as the one demonstrated in A1, by simply spoofing another participant’s credentials (at the Network level) and either disturbing or flooding communications within infrastructure’s Level 2 (Process Network), we’re able to heavily impact the ROS and ROS-Industrial operation14.
Our team considered two types of attacks:
SYN-ACK ATTACK:
The first one performs a SYN-ACK DoS flooding attack which is successfully blocked by the hardening step we considered in the setup.
FIN-ACK:
The second uses a FIN-ACK attack which aims to disrupt network activity by saturating bandwidth and resources on stateful interactions (i.e. TCPROS sockets).
ATTACK 3
A Person-in-the-Middle (PitM) attack targeting a control station (e.g. Sˆ 2) consists of an adversary gaining access to the network flow of information and siting in the middle, interfering with communications between the original publisher and subscriber as desired.
The attack diagram depicts how PitM demands to conflict not just with the resolution and addressing mechanisms but also to hijack the control protocol being manipulated (ROSTCP).
STEP 1: Intrusion
The attack gets initiated by a malicious actor gaining access and control of a machine in the network, refer to A1 above for an example.
STEP 2: ARP poisioning
Using the compromised computer on the control network, the attacker poisons the ARP tables on the target host (Sˆ 7) and informs its target that it must route all its traffic through a specific IP and hardware address (i.e., the attackers’s owned machine).
STEP 3: Information for controllers
By manipulating the ARP tables, the attacker can insert themselves between Sˆ 7 and Sˆ 2 17. When a successful PitM attack is performed, the hosts on each side of the attack are unaware that their network data is taking a different route through the adversary’s computer.
Once an adversary has successfully inserted their machine into the information stream, they then have full control over the data communications and could carry out several types of attacks.
STEP 4: Information for controller
One possible attack method which is the replay attack. In its simplest form, captured data from Sˆ 7 is replayed or modified and replayed. During this replay attack the adversary could continue to send commands to the controller and/or field devices to cause an undesirable event while the operator is unaware of the true state of the system.
ATTACK 4
Attacks don’t only necessarily come from the outside (IT Level or the Cloud). Increasingly, more and more reports are informing about the relevance of insider threats from group sources like S1. This attack depicts one of such scenarios where we attempted first to compromise Cˆ 6 (failed) and then C3 using previously reported and known (yet unresolved) zero day vulnerabilities in the Universal Robots CB3.1 controller.
Examples of such zero days include RVD#1413 (CVE-2016-6210), RVD#1410 (CVE-2016- 6515), RVD#673 (CVE-2018-10635) or RVD#1408 (CVE-2019-19626) among others.
Due to the lack of concerns for security from manufacturers like Universal Robots, these end-points can easily become rogue and serve as an entry point for malicious actors. After failing to take over the hardened control station, our team successfully prototyped a simplified attack using RVD#1495 (CVE-2020-10290) and taking control over C3. From that point on, we could access the ROS network completely and pivot (A1), disrupt (A2) or PitM (A3) as desired.
We demonstrated 4 attack groups that exploited both new and known vulnerabilities achieving the goals we set. We managed to: 1) Execute code remotely (A1) in a ROS end-point, 2) disrupt the ROS computational graph (A2), 3) Impersonate a ROS control station through PitM (A3) and 4) show how an unprotected robot endpoint could be used to pivot into the ROS network (A4).
Through our experiments we showed how control stations running Ubuntu 18.04 do not protect ROS or ROS-Industrial deployments. Moreover, the guidelines offered by Canonical for securing ROS are of little use against targeted attacks, as demonstrated. Moreover, we argue that while hardening efforts are benefitial, they won't be enought to protect robotic systems against targeted attacks that may exploit zero days.
At the time of writing, among the vulnerabilities we exploited most remain active. An exception is RVD#2401 (CVE-2020-10289) which got resolved by Open Robotics within 30 hours (including the corresponding work for producing a new release) from the moment we submitted a mitigation Pull Request. We also filed PRs for similar issues in other ROS and ROS 2 packages with similar responses.
Our original research question posed whether ROS could be used securely on industrial use cases. Based on the experimental results and given the constrains set in our use case, we argue that with the current status of ROS and ROS-Industrial, it’s hard to guarantee security. Not without a dedicated solution that mitigates known flaws.
Contrary to what some believe in the community, we remain optimistic about being able to secure ROS deployments in industry. We have thereby extended and built a preliminary version of the Robot Immune System (RIS) targeting ROS Melodic Morenia with support also for ROS Kinetic Kame. This version which is currently being tested and available on demand, supports heterogeneous ROS workspaces and builds on top of prior work simplifying its integration. From our side, future iterations will further construct on this and help secure ROS-Industrial and ROS deployments in industry.