Abstract. The reuse of technologies and inherent complexity of most robotic systems is increasingly leading to robots with wide attack surfaces and a variety of potential vulnerabilities. Given their growing presence in public environments, security research is increasingly becoming more important than in any other area, specially due to the safety implications that robot vulnerabilities could cause on humans. We argue that security triage in robotics is still immature and that new tools must be developed to accelerate the testing-triage-exploitation cycle, necessary for prioritizing and accelerating the mitigation of flaws. The present work tackles the current lack of offensive cybersecurity research in robotics by presenting a toolbox and the results obtained with it through several use cases conducted over a year period. We propose a modular and composable toolbox for robot cybersecurity: alurity. By ensuring that both roboticists and security researchers working on a project have a common, consistent and easily reproducible development environment, alurity aims to facilitate the cybersecurity research and the collaboration across teams.
Full text transcribed from the arXiv (ar5iv) HTML of the original paper.
AbstractThe reuse of technologies and inherent complexity of most robotic systems is increasingly leading to robots with wide attack surfaces and a variety of potential vulnerabilities. Given their growing presence in public environments, security research is increasingly becoming more important than in any other area, specially due to the safety implications that robot vulnerabilities could cause on humans. We argue that security triage in robotics is still immature and that new tools must be developed to accelerate the testing-triage-exploitation cycle, necessary for prioritizing and accelerating the mitigation of flaws.
The present work tackles the current lack of offensive cybersecurity research in robotics by presenting a toolbox and the results obtained with it through several use cases conducted over a year period. We propose a modular and composable toolbox for robot cybersecurity: alurity. By ensuring that both roboticists and security researchers working on a project have a common, consistent and easily reproducible development environment, alurity aims to facilitate the cybersecurity research and the collaboration across teams.
I Introduction
Cybersecurity is not a product, but a process. One that needs to be continuously assessed in a periodic manner, as systems evolve and new cyber-threats are discovered. This becomes specially relevant with the re-use of (software and hardware) components and the increasing complexity of such systems . Robotics is the art of system integration . Its modular characteristic by nature, both in hardware and software, provides unlimited flexibility to its system designers. This flexibility however comes at the cost of increased complexity. Current robotic systems are often highly complex, a condition that in most cases leads to wide attack surfaces and a variety of potential vulnerabilities, which increase the complexity of remaining secure by solely relying on the use of traditional perimeter-based approaches.
Robot cybersecurity vulnerabilities are potential attack points in robotic systems that can lead not only to considerable loss of data, but also to safety incidents involving humans . Some claim that unresolved vulnerabilities are the main cause of loss in cyber-incidents. Given the interaction robots have with humans and our environments, the qualification of a security flaw, commonly known as triage, seems of special relevance in the domain of robotics. Mitigating a vulnerability or a bug often requires one to first triage and reproduce the flaw in a deterministic manner. Dealing with robots requires interacting with both hardware and software. The strong interdisciplinary of the robotics fields (which is an inherent characteristic of the complexity of the area) and the trade-off obtained with its modularity demands for knowledge across multiple domains in order to comprehensively analyze a robot system. Correspondingly, triaging and reproducing security flaws in robotics can become extremely demanding in terms of time and resources, especially when cooperating with team members across multiple locations, several of which don’t necessarily may have access to the same hardware.
To address this and accelerate research, a toolbox for robot cybersecurity should facilitate the creation of virtual environments that capture not only software components, but also hardware ones. OS-virtualization and hardware-virtualization are both needed in robotics, specially with the growing adoption of modular frameworks like the Robot Operating System (ROS) . We believe that emulation and simulation should co-exist for robot cybersecurity research, and it should be possible to easily interface these with real hardware.
The present article attempts to deal with these problems by proposing a cybersecurity toolbox that aims to enable roboticists and security researchers cooperating in project to have a common, consistent and easily reproducible development environment, facilitating the security process (DevSecOps ) in robotics and the collaboration across multiple teams. The contributions of this work are threefold. First, we present a modular toolbox for robot cybersecurity that facilitates the cybersecurity processes. It reflects the modular nature of robotics while at the same time makes the resulting complexity easier to handle for cybersecurity researchers. Second, we demonstrate support for mixed simulation and emulation environments in robotics. This helps research scenarios involving high-fidelity virtual versions of hardware and software robot components. Finally, through composability, the toolbox provides modules that can be selected and assembled in various combinations, providing facilities for automation of security testing, evaluation and demonstration while enhancing the triage and reproducibility of security flaws.
The remaining content is organized as follows: Section II presents previous related work. Section III describes the toolbox and section IV a series of use case experiences. Section V presents results using the toolbox and argues about some of the lessons learned throughout the process. Finally, Section VI summarizes our work and draws some conclusions while hinting on future work actions.
II Related work
| Scope | Simulation | Emulation | Mixed | Scalable | Flexible | |
|---|---|---|---|---|---|---|
| DETERlab | testbed facility, hardware testing | No | Yes | No | Low | Yes |
| VINE | computer networks, dynamic and moving target defenses | No | Yes | No | Med | Yes |
| SmallWorld | computer networks, network devices, hardware devices | No | Yes | No | Med | Yes |
| BRAWL | enterprise computer networks | No | Yes | No | Med | Windows |
| Galaxy | computer networks | No | Yes | No | Low | Debian-based |
| Insight | computer networks, network devices, hardware devices | Yes | No | No | High | Yes |
| CANDLES | computer networks, game theory | Yes | No | No | High | Yes |
| Pentesting Simulations | computer networks, penetration testing, machine learning | Yes | No | No | High | Yes |
| CyAMS | computer networks, malware propagation | Yes | Yes | No | High | Yes |
| CybORG | computer networks, machine learning | Yes | Yes | No | High | Yes |
| alurity (ours) | robotics, industrial devices, computer networks | Yes | Yes | Yes | High | Yes |
The mitigation and patching of vulnerabilities has been an active area of research in computer science and other technological domains. Unfortunately, with robotics being an interdisciplinary field composed from a set of heterogeneous disciplines (including computer science), to the best of our knowledge and literature review, except for a few preliminary tools and reviews , not much vulnerability mitigation research related to robotics has been presented so far.
Due to their expensive prices and shortage, getting access to robots for testing is somewhat comparable to the difficulties researchers face when analyzing complex computer networking systems. The Galaxy framework researched this and proposed a high-fidelity computer network emulation tool designed to support rapid, parallel experimentation with the automated design of software agents in mind. By leveraging virtualization, the authors of Galaxy create a high-fidelity clone of a network that takes snapshots to always have a copy of this known base state. With this cloned network, researchers can distribute the work and perform experiments to see how the network performs with certain kind of attacks.
Virtualization is a commonly used technique in other areas allowing developers and security practitioners to more easily test, reuse and ship systems. When using virtualization, there are often two approaches, emulation and simulation. Emulation is generally implemented through hardware-virtualization, typically using full-virtualization with type two hypervisors (e.g. VirtualBox, VMWare Worksation or QEMU) , commonly referred to as Virtual Machines (VMs). This provides complete isolation between guest kernels and host, while allowing to run many different operating Systems (OS) within the same physical host. Simulation is often implemented with simpler abstractions such as state machines or through OS-virtualization, using a shared kernel across both the host and guests. OS-virtualization is typically referred to as ”containers” in Linux , and is widely considered the most efficient virtualization method for its highest performance and fastest ”start-up” time. Different approaches to simulation are presented at .
The authors of confirm that shifting from simulated to emulated experiments removed the luxury of real-world abstractions and acknowledge that VMs must be power cycled, or reverted to reset states, as opposed to quicker simulations. They further mention that VM emulation is bulky and computationally expensive, whereas containers (OS-virtualization) use fewer system resources and have faster power cycle actions. A concerning matter regarding OS-virtualization is that unlike VMs, which emulate the entire network architecture stack, containers share the host kernel which comes at the cost of fidelity. This was raised by however Handigol et al. and Heller demonstrated how containers, could be used without a relevant loss of fidelity, which further encourages the use of containerization. Other approaches to emulation include or .
A similar experience to was described more recently by which targets research in Autonomous Cyber Operations (ACO). The authors of proposed a high-fidelity emulation using VMs, and a low-fidelity simulation using a finite state machine design that could model networks. Virtualization of the different scenarios was realized by using a description file (YAML) and a flag determined the use of either simulation or emulation. The results obtained of this dual approach show promise and the authors already hint that future work might train in low-fidelity simulation, and later optimize in high-fidelity emulation.
Our work builds on top of these past experiences and proposes a toolbox that facilitates the virtualization of robotic scenarios with the capability of doing both high-fidelity emulation and simulation using VMs and containers, respectively. Moreover, by extending the networking abstractions of both VMs and containers, our toolbox allows for mixed heterogeneous virtual environments, where emulated endpoints (VMs) can interact with simulated ones (containers), providing more flexibility for roboticists and security researchers. Table I presents our approach compared to past work.
III alurity
Alurity is a modular and composable toolbox for robot cybersecurity. It ensures that both roboticists and security researchers working on a project, have a common, consistent and easily reproducible development environment facilitating the security process and the collaboration across teams. It’s available for Linux (across distributions) and Mac OS, with limited support at the time of writing for Windows. Featuring dozens of different tools in the form of individual components, alurity simplifies and speeds up the cybersecurity research in robotics. The toolbox organizes security and robotics components in different groups that allow for easy composition and use. Figure 1 illustrates this aspect and the different groups, while constructing a robotic subject with it.
Similar to , alurity toolbox allows to build scenarios using a simple description file in YAML format. Listing 1 provides an example of such format while modeling the scenario of Figure 2(a).
III-A Simulated, emulated or real endpoints
Dealing with robots requires interacting with both hardware and software. Correspondingly, a toolbox that helps security researchers and roboticists in their cybersecurity efforts should consider virtual environments that capture not only software components, but also hardware ones. OS-virtualization and hardware-virtualization are both needed. In other words, emulation and simulation should co-exist.
Virtualization in alurity defaults to simulation. Built using containers (OS-virtualization) it delivers an efficient, high-fidelity, high-performance and fast virtualization method. Most alurity modules (tools) are containerized this way and can be easily composed as demonstrated in listing 1. High-fidelity emulation is implemented using VMs (hardware-virtualization)—more specifically—on top of VirtualBox VMs (full-virtualization, type two hypervisor). The YAML syntax for emulation is similar to the one for simulation and exemplified in listing 2:
Alurity allows to easily build robotic subjects of study through the virtualization of different robots, networks (e.g. LANs, serial comms, VPNs, VLANs, VXLANs, WLANs, etc) and robot components, including security protection mechanisms as depicted in Figure 2(c). It supports both, simulation and emulation of modules and allows for mixed environments where emulated endpoints can co-exist and interact (networking-wise) with simulated ones. This logic is implemented at the core of the toolbox through private network internals to the host so that containers on this network can communicate with VMs. Behind the scenes, alurity creates the necessary bridges, internal virtual network interfaces, iptables rules, and host routes to make this connectivity possible.
Beyond virtualization (emulation or simulation), alurity was built to include real robot endpoints in the scenarios. Correspondingly, the toolbox and its networking capabilities allow to interface with public networks and interoperate with real robots, while leveraging the power to build virtual attackers and weaponize them with different tools and exploits.
III-B Flows
Alurity operates mostly through its Command Line Interface (CLI), which facilitates to download your configuration YAML file modules and start the scenarios, to begin with the corresponding experiments. Beyond core modules, alurity provides an additional capability called alurity flows meant to facilitate evidence generation and reproduction. Flows are series of commands within a scenario built with alurity. A flow allows to automate interactions between endpoints through the launch of a series of commands and applications via simple YAML format. Simply put, flows allow researchers to reproduce each other’s work and results by simply providing a YAML file with the scenario description and one (or multiple) flows. alurity flows are built using a mix of tools including byobu, tmux and other utilities which are embed into a base layer present in every alurity module. Listing 3 exemplifies a flow where an attacker targets the ROS core of an industrial setup.
To further automate security research, alurity YAML files, including the flows, can be integrated into vulnerability tickets of robot vulnerability databases, such as the Robot Vulnerability Database (RVD) , allowing other researchers to simply alurity run --rvd
III-C Pipelines
When performing a security exercise, researchers often spend a considerable amount of time with information gathering and testing, for bug identification. This process is often performed manually, consuming resources that could instead be used for exploitation and/or mitigation. In order to alleviate this effort we built alurity pipelines, automated end-to-end and on-demand security pipelines that automatically build an alurity YAML file with selected tools and ”runs them” through the desired target module. For each security flaw identified, the pipeline generates a YAML file describing the flaw using RVD taxonomy either in a local directory or pushing the flaw directly as an issue to Github or Gitlab. This way, pipelines support the robotics DevSecOps pushing each potential vulnerability to a centralized flaw management registry.
IV Use cases
To illustrate the flexibility of the alurity toolbox, Figure 2 depicts several use cases of robot cybersecurity research conducted with it. For each one of these scenarios, either simulation and/or emulation was used, interfacing when appropriate with real hardware for final validation of the flaws. We discuss below briefly each use case and the virtualization mechanisms used:
IV-A Penetration testing Universal Robots’s UR series
Using alurity, we conducted a penetration testing security exercise with the aim of providing a practical assessment of the UR3, UR5 and UR10 robot insecurities. Before the exercise, there were five reported vulnerabilities for these collaborative robots. After the penetration testing assessment, more than 80 were publicly available, many with proof-of-concept exploits.
Figure 2(a) depicts the scenario we assumed for the exercise with a Universal Robots UR3 robot and a CB3.1 controller connected to a process level network, where an attacker had compromised a machine. The scenario was simulated with alurity and both the robot controller and the attacker were containerized. The mechanics of the robot were ignored for the purpose of the study. While emulation could have added additional fidelity to the robot controller virtualization at the expense of additional time, we decided not to proceed in that direction and instead focused mostly on simulation, with the exception of physical attack vectors, which were conducted against the real robot with an alurity simulated attacker. Public results were discussed at . A complete list of the vulnerabilities released is available at https://bit.ly/3183cQF.
IV-B Penetration testing ABB’s IRC5 controller
We studied ABB’s IRC5 compact robot controller with the IRB 140 manipulator and the DSQC 679 teach pendant. For the use case, we assumed the controller was connected to a simulated process level network where an attacker had compromised a machine. Given the closed environment of ABB’s technology, in this case, we used alurity to mix simulation, emulation and real hardware while conducting the penetration testing assessment. The Attacker was simulated, the manipulator and the teach pendant were real and the controller was either real or emulated. Emulations of the controller consisted of isolated components extracted from its firmware. Public results of the exercise were discussed at . A complete list of the vulnerabilities released during the exercise conducted within 2020 for ABB is available at https://bit.ly/2FsZQzX
IV-C Penetration testing KICS
This use case considered a more sophisticated environment involving more elements and capturing a selected portion of a secure industrial factory automation process. In particular, we focused our study on how insecure robots could be used as entry points to further compromise the Kaspersky Industrial CyberSecurity (KICS) solution, a commercial product. KICS imposes strong demands on the kernel and the hardware devices available from the file system, thereby after struggling with containerization for a while, we opted for emulating KICS-related entities including KSC, KICS for Networks and the associated sensors. We used alurity to harmonize all networking aspects of the scenario and simulate the rest of the endpoints involved including robot controllers, workstations and other ICS elements. Results of the exercise are not publicly available at the time of writing.
IV-D Red teaming ROS-Industrial
In this use case we aimed to answer the question of whether ROS could be used securely for industrial use cases. We did so experimentally by performing a targeted offensive security exercise in a use case involving ROS-Industrial and ROS packages. We built a synthetic industrial scenario which presented a network segmented in 5 levels, with segregation implemented following standardized recommendations. Alurity was used to simulate all entities and network elements, including those necessary for segmentation and segregation. By doing so we obtained a lightweight yet high-fidelity environment whereto perform attacks. Results of the exercise are discussed at and further documented in .
V Lessons learned and results
At the time of writing alurity toolbox features more than 70 different modules, including security tools, industrial common endpoints (e.g. PLCs or HMIs), robots and robot components. Due to our aim to use well-tested and established technology, as opposed to reinvent the wheel on security tooling, we re-used as much past work as possible when building the toolbox. Specially on the simulation and virtualization infrastructure side which led us to save a significant amount of resources, focusing our efforts instead on a) usability and b) optimizing the delivery of cybersecurity research products, namely vulnerabilities, proof-of-concept (PoC) exploits and mitigations. Maintaining this focused attitude on re-use is what led us to produce usable cybersecurity research results. Out of the use cases in Figure 2, we produced several dozens of vulnerabilities and received multiple new CVE IDs while responsibly disclosing the flaws to the upstream manufacturers. Public disclosure of these vulnerabilities happened in RVD with results catalogued by manufacturer, robot or robot component.
Thanks to the use of virtualization, a significant amount of time was saved. Research could run in parallel among researchers and across groups, with the few physical robots available used only for final validation. The use of high-fidelity simulation also accelerated the process of dynamic testing, wherein the robot often entered into unstable states. Power-booting simulations required just a few seconds (as opposed to minutes with emulated robots, or an even longer time if having to re-flash firmware in the real robot). A particular alurity feature that simplified peer-triage was alurity flows which when embed into vulnerability reports (as in or ) complemented nicely exploit PoCs with additional context. Another aspect of the toolbox that proved useful was to run known attacks on new firmware versions of the robots or robot components. Specially in combination with simulations described by the YAML syntax which allowed for quick changing of the targets by simply modifying only one YAML line. The same applied to new security mechanisms, which could be tested against attacks, and across robots easily with alurity.
Overall, after these experiences and although we don’t feel we could generalize for all use cases, we strongly recommend security researchers to consider testing and triaging in simulation before defaulting to emulation and ultimately, to real endpoints. This will save them a considerable amount of time and will facilitate reproduction and interactions with upstream vendors, who are likely the final recipients of their security results.
VI Conclusions
In this study we presented alurity, a modular and composable toolbox for robot cybersecurity that ensures that both roboticists and security researchers have a common, consistent and easily reproducible development environment. We described the architecture of alurity including its capabilities for virtualization. We also described additional features that facilitate the security process and cooperation across teams, namely flows and pipelines. We then presented four real use cases conducted with alurity and shared some lessons learned, emphasizing that simulation appears to speed up significantly cybersecurity research in robotics.
The lack of documentation for alurity is currently the biggest hurdle preventing us from disclosing it to a wider audience. Future work should focus on this. We also plan to look into preserving the state of the simulated scenarios across runs, as well as improved Windows support.
ACKNOWLEDGMENTS
This research has been funded by Alias Robotics, by the INNOEM-2020/00037 Álava Innova research grant throughout the Economic Development and Innovation Service of the Foral Council of Álava and finally, also by the Spanish Government through CDTI Neotec actions (SNEO-20181238). Thanks also to the City Council of Vitoria-Gasteiz and 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.