Abstract. With its growing use in industry, ROS is rapidly becoming a standard in robotics. 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 which raises the question: 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. Our exercise results in four groups of attacks which manage to compromise the ROS computational graph, and all except one take control of most robotic endpoints at desire. To the best of our knowledge and given our setup, results do not favour the secure use of ROS in industry today, however, we managed to confirm that the security of certain robotic endpoints hold and remain optimistic about securing ROS industrial deployments.
Full text transcribed from the original publication source.
1 Introduction
The Robot Operating System (ROS)
ROS was not designed with security in mind, but as it started being adopted and deployed into products or used in government programs, more attention was placed on it. Some of the early work on securing ROS include
The present work tackles this question experimentally. We perform a targeted security exercise, namely red teaming, to determine whether ROS and more specifically, ROS and ROS-Industrial packages could be used securely in an industrial setup. We construct a synthetic industrial scenario and choose one of the most common industrial robots with ROS-I support to build it. We then apply available security measures to the setup following official recommendations
Using this setup, we perform a red teaming exercise with the overall goal to take control of the ROS computational graph. To achieve this goal, we create four different attacks that target the ROS-Industrial and ROS packages. The results show that ROS Melodic Morenia presents several unpatched security flaws, even when hardened with community recommendations.
The remaining content is organized as follows: Section II presents related work. Section III describes the selected industrial application and use case. Section IV provides a walk-through on the red teaming activity. Finally, Section VI summarizes results and draws some conclusions while hinting on future work actions.
2 Related work
Red teaming is a full-scope, holistic and targeted (with specific goals) attack simulation designed to measure how well a system can withstand an attack. Opposed to Penetration Testing (pentesting or PT), a red teaming activity does not seek to find as many vulnerabilities as possible to risk-assess them, but has a specific goal. Red teaming looks for vulnerabilities that will maximize damage and meet the selected goals. Its ultimate objective is to test an organization/system detection and response capabilities in production and with respect a given set of objectives. Past works in robot cybersecurity
To the best of our knowledge, no prior public work has performed a red teaming activity on ROS-Industrial packages (or in any other robotics technology for that matter), and challenged its security extensions. In this paper, we present a study in which we aim to do so in a realistic industrial scenario.
3 Use case
We build a synthetic assembly line operated by ROS-powered robots while following industrial guidelines on setup and security. The scenario is built following NIST Special Publication 800-82
The use case involves several robots with their corresponding controllers. Most of them presented as provided by the manufacturer and some others hardened. For robot (endpoint) hardening we use a commercial Robot Endpoint Protection Platform (REPP) solution applied to the controllers, the Robot Immune System (RIS)
4 Red teaming ROS
We performed a red teaming exercise on the ROS network including ROS and ROS-Industrial packages. While targeting ROS, a variety of attack vectors were evaluated. Before diving into the attacks, below, we first specify the goals of the red teaming exercise, defining certain boundaries to steer our research. After that, we analyze a series of attacks that successfully meet the defined goals.
4.1 Goals
For the red teaming exercise, our efforts focus on achieving the following goal:
Goal \(G_{1}\) : Control, deny access or disrupt the ROS computational graph.
Note that if appropriate security mechanisms are implemented, control of the ROS network might not necessarily imply control of the robots thereby in addition, as a secondary target, we also aim at:
Goal \(G_{2}\) : Control, deny access or disrupt the operation of robots (ROS-powered or not).
4.2 Scope
For the purpose of this red teaming exercise and as part of the robotic systems selected, the mechanics are required to be connected to the corresponding controllers, which are the ones operating and interfacing between the robot and other systems. We discard and scope out all activities related to the physical damage of the robot mechanics (servos, encoders and related) by insider threats. All mechanical aspects including malfunctions or related are also considered out of the scope. Similarly and to reduce the complexity of the scenario, while remaining faithful to most industrial deployments, we assume that no wireless connection happens between control stations, robot controllers and/or other devices. In addition, we assume that no social engineering is performed and no kernel exploits are used.
4.3 Attack 1 ( \(A_{1}\) ): Targeting ROS-Industrial and ROS core packages
In this attack, we adopt the position of an attacker with access to and privileges in a development machine \(D_{1}\) at the IT side (see Level 4 in Figure 2). Reaching such a machine is beyond the scope of this 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 \(D_{1}\) and obtain a certain amount of privileges (step 1 of the attack diagram of Figure 2). Further, a privilege escalation will be performed by the exploitation of additionally vulnerable services, which allows the attacker to eventually gain privileges into \(D_{1}\) and command it as desired (step 2). From \(D_{1}\) , an attacker would pivot into Level 3 by exploiting a vulnerability in the ROS core and/or ROS-Industrial packages (step 3). Having gained control of the Central Control Station \(\hat{S_{7}}\) the attacker could decide to establish a reverse channel of communications directly – avoiding the developer station – (step 4) or proceed to control Operational Technology (OT, Level 2 and below) by sending commands via the ROS computational graph (step 5). The following subsections detail some of the steps involved on how our team managed to execute steps 3-5.
Step 3: exploiting vulnerability in ROS or ROS-Industrial packages for remote code execution
Since we are targeting \(\hat{S_{7}}\) , we scanned the source code of Melodic and the common ROS-Industrial packages being used on it as a ROS Master. We encountered several potentially exploitable flaws and reported them all in RVD
def yaml_msgs_str(type_, yaml_str, filename=None):
import yaml
yaml_doc = yaml.load(yaml_str)
msgs = []
for msg_dict in yaml_doc:
if not isinstance(msg_dict, dict):
if filename:
raise ValueError(yaml file [%s] does not contain a list of dictionaries % filename)
else:
raise ValueError(yaml string does not contain a list of dictionaries)
m = type_()
roslib.message.fill_message_args(m, msg_dict)
msgs.append(m)
return msgs 
The flaw itself is caused by an unsafe parsing of YAML values which happens whenever an action message is processed to be sent, and allows for the creation of Python objects (step 3). Through this flaw in the ROS core package of actionlib, an attacker can make \(\hat{S_{7}}\) , the central control station that runs ROS Master, execute arbitrary code in Python. Note that actionlib is common in ROS and ROS-Industrial deployments. Also, the selected flaw affects actionlib’s tools and depending on the setup, might require certain user interaction for its exploitation. We considered the following two attack scenarios:
Remote arbitrary code execution: \(D_{1}\) and \(\hat{S_{7}}\) have previously exchanged keys
( \(A_{1.1}\) ). A common (though insecure) practice in industrial environments is to temporarily (or even permanently) exchange keys to facilitate remote control and monitoring of machines in the DMZ level (Level 3). This aligns nicely with the fact that it is common in ROS deployments to rely on SSH key exchanges for remote ROS node launches (via XML launch files
Privilege escalation: Attacker obtains limited access to \(\hat{S_{7}}\) via other means
( \(A_{1.2}\) ). Provided the attacker could execute arbitrary commands on \(\hat{S_{7}}\) for diagnosis (e.g. with a maintainer user) but not with a ROS graph privileged one, we believe it’s worth further studying whether the exploitation of the same vulnerabilities could lead to obtain privileges that allow to modify the ROS computational graph. Due to time and budget restrictions for the experiment we were not able to confirm this, however we argue that is possible unless ROS specific measures on user privilege-separation have been implemented.
<launch> <env name="DISPLAY" value=":0.0"/> <machine name="s7" address="16.0.0.20" env-loader="/opt/ros_ur_ws/devel/env.sh"/> <node name="action" machine="s7" pkg="actionlib" type="axclient.py" args="//ur_hardware_interface/set_mode"/> </launch>
Step 4: establishing a reverse shell
With listing 2 remotely executed on the target ROS Master ( \(\hat{S_{7}}\) ) we were able to demonstrate how an attacker can remotely execute arbitrary code. To continue with our attack we seek for a persistent connection and thereby build a custom payload that spawns a reverse shell. The code to do this is depicted in Figure 3(b). It constructs a string which when processed for generating ROS communication artifacts (messages), gets executed. The string itself declares a Python object which on creation launches a reverse shell back to the attacker’s ( \(D_{1}\) ) hardcoded IP address.
Step 5: control the computational graph and other machines within the OT levels
Once the attacker has at its disposal a reverse shell to \(\hat{S_{7}}\) it becomes relatively easy to command the different industrial subsystems. \(\hat{S_{7}}\) acts as the ROS Master of the industrial network and thereby can easily influence all ROS-Industrial package deployments living in the control stations \(S_{1}\) to \(S_{5}\) . Such exploitation has been covered by other authors including
Responsible disclosure and mitigation efforts
Our team announced the Robot Vulnerability Database in October 2019 for the ROS community
4.4 Attack 2 ( \(A_{2}\) ): Disrupting ROS-Industrial communications by attacking underlying network protocols
As pointed out previously, ROS-Industrial software builds on top of ROS packages which build on top of traditional networking protocols at OSI layers 4 and 3. It is common to find ROS deployments using TCP/IP in the Transport and Network levels of the communication stack. To further test the limits of these underlying layers and its impact on ROS, we developed a complete ROSTCP networking package dissector and used it as a tool for attacks. These consists of a malicious attacker with privileged access to an internal ROS-enabled control station (e.g. \(S_{1}\) ) disrupting the ROS-Industrial communications and interactions between other 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.
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 are able to heavily impact the ROS and ROS-Industrial operation
4.5 Attack 3 ( \(A_{3}\) ): Person-In-The-Middle attack to a ROS control station
A Person-in-the-Middle (PitM) attack targeting a control station (e.g. \(\hat{S_{2}}\) ) consists of an adversary gaining access to the network flow of information and sitting in the middle, interfering with communications between the original publisher and subscriber as desired. PitM demands to conflict not just with the resolution and addressing mechanisms but also to hijack the control protocol being manipulated (ROSTCP). The attack gets initiated by a malicious actor gaining access and control of a machine in the network (step 1), such as done with \(A_{1}\) . Then, using the compromised computer on the control network, the attacker poisons the ARP tables on the target host ( \(\hat{S_{7}}\) ) and informs its target that it must route all its traffic through a specific IP and hardware address (step 2), i.e., the attacker’s owned machine. By manipulating the ARP tables, the attacker can insert themselves between \(\hat{S_{7}}\) and \(\hat{S_{2}}\) (step 3)
Once adversaries have successfully inserted their machine into the information stream, they have full control over the communication and could carry out several types of attacks. For example, the replay attack (step 4). In its simplest form, captured data from \(\hat{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.
4.6 Attack 4 ( \(A_{4}\) ): Exploiting known vulnerabilities in a robot endpoint to compromise the ROS network
Attacks do not only necessarily come from the outside (IT Level or the Cloud). Increasingly more reports
5 Discussion
In this section, we summarize and discuss our findings and lessons learned.
5.1 Findings
Table I summarizes the attacks and their impact with respect to our two goals. \(G_{1}\) is achieved in all the presented attacks whereas \(G_{2}\) is mostly achieved yet depends on the hardening of the corresponding control stations and robotic endpoints. At the time of writing, among the vulnerabilities we exploited most remain active. An exception is RVD#2401 which got resolved by Open Robotics within 30 hours from the moment we submitted a mitigation.
| Attack | Description | Goals met |
|---|---|---|
| \(A_{1.1}\) : remove arbitrary code execution | Subject to some prior interactions, attacker with control of \(D_{1}\) is able to exploit a vulnerability in ROS and launch arbitrary remote code executions from a privileged ROS end-point compromising completely the computational graph | \(G_{1}\) and \(G_{2}\) ( \(R_{1}\) , \(R_{2}\) , \(R_{3}\) , \(R_{4}\) and \(R_{5}\) ) |
| \(A_{1.2}\) : privilege escalation | Subject to local access, attacker is able to exploit a vulnerability in ROS and escalate privileges (to the ROS ones) in such machine | \(G_{1}\) |
| \(A_{2}\) : FIN-ACK flood attack targeting ROS | Attacker attempts to deny ROSTCP connection on target destination by forcing a maxed-out number of connections | \(G_{1}\) and \(G_{2}\) ( \(R_{1}\) , \(R_{2}\) , \(R_{3}\) , \(R_{4}\) and \(R_{5}\) ) |
| \(A_{3}\) : PitM attack to a ROS control station | Attacker poisons ARP tables and gains access to the network flow of information siting between targeted publishers and subscribers, interfering with communications as desired. | \(G_{1}\) and \(G_{2}\) ( \(R_{1}\) , \(R_{2}\) , \(R_{3}\) , \(R_{4}\) and \(R_{5}\) ) |
| \(A_{4}\) : Insider endpoint via unprotected robot controller | Attackers exploit known vulnerabilities in a robot endpoint to compromise the controller and pivot into the ROS network. | \(G_{1}\) and \(G_{2}\) ( \(R_{1}\) , \(R_{2}\) , \(R_{3}\) , \(R_{4}\) , \(R_{5}\) and \(R_{6}\) ) |
The original research question posed whether ROS could be used securely on industrial use cases. Based on our experimental results, we found: With the current status of ROS, it is hardly possible to guarantee security without additional measures.
5.2 Lessons learned
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
Dedicated robotic security protection systems like the Robot Immune System (RIS)
6 Conclusions
In this study, we presented four targeted attacks over a synthetic industrial scenario constructed by following international ICS cybersecurity standards where the control logic is operated by ROS and ROS-Industrial packages. Our attacks exploited both new and known vulnerabilities of ROS achieving the two goals we set. We managed to execute code remotely ( \(A_{1}\) ) in a ROS end-point, disrupt the ROS computational graph ( \(A_{2}\) ), impersonate a ROS control station through PitM ( \(A_{3}\) ) and finally use an unprotected robot endpoint to pivot into the ROS network ( \(A_{4}\) ). For future work we plan to look into other Operating Systems as a starting point for secure ROS deployment and explore additional security measures.
7ACKNOWLEDGMENTS
This research has been partially funded by Alias Robotics and by the European Union‘s Horizon 2020 research and innovation programme under grant agreement No 732287, under ROSin project through the FTP RedROS-I. Thanks also to the Basque Government, throughout the Business Development Agency of the Basque Country (SPRI). Special thanks to BIC Araba and the Basque Cybersecurity Centre (BCSC) for the support provided. Finally, this research was also financially supported by the Spanish Government through CDTI Neotec actions (SNEO-20181238).