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 arXiv (ar5iv) HTML of the original paper.
AbstractWith 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.
I Introduction
The Robot Operating System (ROS) is the de facto framework for robot application development . At the time of writing, the original ROS article has been cited more than 6800 times, which shows its wide acceptance for research and academic purposes. ROS was born in this environment: its primary goal was to provide the software tools that users would need to undertake novel research and development. ROS’ popularity has continued to grow in industry supported by projects like ROS-Industrial (ROS-I for short), an open-source initiative that extends the advanced capabilities of ROS software to industrial relevant hardware and applications.
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 or , all of them appearing in the second half of 2016. At the time of writing, none of these efforts remain actively maintained and the community focus on security efforts has switched to ROS 2, the next generation of ROS. ROS 2 builds on top of DDS and shows promise. However, to the best of our knowledge, there’re still no known robots running ROS 2 in production at scale. From our experience analyzing robots used in industry, their operating systems, libraries and dependencies, we argue that ROS 2 is still years from being widely deployed for major automation tasks. Until then, ROS will prevail. With the advent of ROS in industry and professional use, one question remains: Even though ROS was not designed with security in mind, can companies use it securely for industrial use cases?
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 and program a simple flow of operation.
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.
II 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 criticize the current status of cybersecurity in robotics and reckon the need of further research. Previous attempts to review the security of robots via offensive exercises or tools include which mostly focus on proof-of-concept attacks and basic penetration testing, detecting flaws in ROS. A recent study mentions the identification of several flaws within ROS-Industrial codebase, however it does not explicitly describe ROS-specific flaws. Considerations are made with regard the open and insecure architecture predominant in ROS-Industrial deployments throughout its open source drivers. From interactions with the authors of , it was confirmed that the reported security issues were made generic on purpose, further highlighting the need for further investment on understanding the security landscape of ROS-Industrial setups.
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.
III 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 Guide to Industrial Control Systems (ICS) Security as well as some parts of ISA/IEC 62443 family of norms . We segregate the use case in 5 network levels as depicted in Figure 1.
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). In addition, each robot is connected to a Linux-based control station that runs the ROS-Industrial drivers. Control stations are hardened by following the guidelines described in . To simplify, for the majority of the cases we assume that the controller is connected to a dedicated Linux-based control station that runs ROS Melodic Morenia distribution and the corresponding ROS-Industrial driver. For those cases that do not follow the previous guideline, the robot controller operates independent from the ROS network (e.g. robots \(R_{3}\) and \(R_{6}\) ). To select the target robots, we performed a preliminary evaluation of the different common ROS-Industrial packages. We base our assessment on the potential security bugs identified with static analysis also covered at . The results showed that Universal Robots drivers presented the biggest number of bugs which together with its popularity, made us select it as our target. The whole process is documented in which presents an extended version of this study. Figure 1 presents the architecture diagram of the use case. To speed up the cybersecurity research and have a common, consistent and easily reproducible development environment, we containerized simulations using alurity toolbox. In most cases, for simulation purposes, the corresponding file systems of each element in the scenario is embed into a Linux container with the right services triggered at launch, facilitating the cooperation across teams of engineers working remotely. The complete use case depicted in Figure 1 can be reproduced with the alurity YAML configuration file available for download at https://bit.ly/3lWn41G.
IV 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.
IV-A 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).
IV-B 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.
IV-C 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.
IV-C1 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 . Then, we decided to focus on one existing flaw in the ROS actionlib package. Part of the ROS core, the actionlib stack provides a standardized interface for interacting with preemptable tasks. Examples of use include exchanging information with an articulated robotic arm (e.g. setting a specific state). In our setup, actionlib is used both by the Universal_Robots_ROS_Driver and the ur_modern_driver ROS-Industrial drivers. These are running in the control stations \(S_{1}\) , \(S_{2}\) , \(S_{4}\) and \(S_{5}\) , which interface with robots \(R_{1}\) , \(R_{2}\) , \(R_{4}\) and \(R_{5}\) , respectively. The specific exploitable flaws identified in the actionlib tools are further illustrated in listing 1. Note, while this flaw is present in a ROS core package (detected in Melodic, but also in Noetic and prior released ROS distros), the distributed software architecture of ROS propagates this vulnerability to both of the ROS-Industrial drivers mentioned.
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). Correspondingly, we built a custom launch file (listing 2) that enables us to drop a malicious payload that exploits the vulnerabilities described above. Once a malicious attacker operating from \(D_{1}\) initiates this launch file, it establishes an SSH connection between \(D_{1}\) and \(\hat{S_{7}}\) using pre-shared keys, and forwards the action client GUI visualization to \(D_{1}\) as depicted in Figure 3(a). This way, the attacker can introduce a payload that exploits said vulnerability. We demonstrate this step in Figure 3(b). When sent this message causes the action client (actionlib) to execute the malicious payload. The described process allows for arbitrary remote code execution (with the privileges of the ROS setup) exclusively through ROS exploitation. That is, a flaw in ROS allows the attacker to take control of the remote machine \(\hat{S_{7}}\) via common ROS tools.
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.
IV-C2 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.
IV-C3 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 and we refer the reader to this study for further exploration on how to take control of the ROS computational graph using the ROS Master and Slave APIs.
IV-C4 Responsible disclosure and mitigation efforts
Our team announced the Robot Vulnerability Database in October 2019 for the ROS community and openly disclosed our intention of cataloging and recording early-phase security flaws applying to ROS. The flaw described in here was first publicly filed in June 2020 and later elevated to a vulnerability in August 2020 with subsequent pull requests patching actionlib in ROS Melodic Morenia and ROS Noetic Ninjemys. The suggested mitigations propose the use of safe parsing. This way, the construction of communication artifacts would only allow for simple objects like strings or integers, removing the threat.
IV-D 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. Our team considered a FIN-ACK attack which aims to disrupt network activity by saturating bandwidth and resources on stateful interactions (i.e. TCPROS sockets). The simple proof-of-concept we developed for validating this flaw can be downloaded from https://bit.ly/3h5Fn11. Further details are available in our extended report .
IV-E 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). 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 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.
IV-F 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 are informing about the relevance of insider threats with more than half of the attack vectors requiring physical access. We studied one of such scenarios where we attempted first to compromise \(\hat{C_{6}}\) (failed) and then \(C_{3}\) using previously reported and known (yet unresolved) zero day vulnerabilities in the robot controller. Due to the lack of concerns for security from manufacturers, 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 \(C_{3}\) . From that point on, we could access the ROS network completely and pivot ( \(A_{1}\) ), disrupt ( \(A_{2}\) ) or PitM ( \(A_{3}\) ) as desired.
V Discussion
In this section, we summarize and discuss our findings and lessons learned.
V-A 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.
V-B 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 for securing ROS were of little use against targeted attacks. Certain ongoing hardening efforts for ROS Melodic helped mitigate some issues but as highlighted in Table I, most goals were still achieved with attacks targeting threats like zero day vulnerabilities, wide and availability of industrial components, inadequate security practices or non-patched OS and firmware.
Dedicated robotic security protection systems like the Robot Immune System (RIS) used in \(\hat{C_{2}}\) , \(\hat{C_{5}}\) or \(\hat{C_{6}}\) managed to secure the corresponding robot avoiding directed attacks. However \(R_{2}\) and \(R_{5}\) robots were still hijacked by compromising the ROS computational graph via their control stations. RIS was not able to stop these attacks because they came from trusted sources whose behavior was learned over a prior training phase. An exception was \(R_{6}\) which we were not able to compromise thanks RIS being installed at \(\hat{C_{6}}\) whereas \(R_{3}\) (not protected) was easily compromised and used as a rogue endpoint for attackers to pivot into other malicious endeavors. From this, we conclude that industrial scenarios like the one presented in this use case using ROS must not only follow ICS guidelines but also harden robot endpoints and the ROS computational graph across each phase, from development to post-production .
VI 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.
ACKNOWLEDGMENTS
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).