Red teaming ROS and ROS-Industrial packages

ROS-Industrial
1

![ros_readteaming_scenario](upload://fQGKmIvzcouKV1drsOymMQBg4Q7.png)

TL;DR, we challenge the cyber security status of ROS and ROS-Industrial packages within Melodic experimentally by a) constructing a synthetic industrial scenario, b) hardening it according to industrial and existing available recommendations and c) performing a targeted security exercise, namely red teaming. We found ROS/ROS-I computational graph vulnerable to a variety of attacks and managed to take control of the underlying robots.

For more, refer to the following resources:

Red teaming

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 mostly focus on proof-of-concept attacks and basic penetration testing, detecting flaws in ROS.

![ros_readteaming_scenario](upload://rpfLSP6dsHobRMj38onthNFfbPe.png)

Goals for the offensive security exercise

  • Goal G_1: Control, deny access or disrupt the ROS computational graph.
  • Goal G_2: Control, deny access or disrupt the operation of robots (ROS-powered or not).

Findings

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)

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. This further confirmed that

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 are of little use against targeted attacks, as demonstrated. Certain ongoing hardening efforts for ROS Melodic (e.g. the CIS Benchmark for Melodic) helped mitigate some issues but regardless, most goals were still achieved with attacks targeting threats like zero days, 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 stillhijacked 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 to 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.

Due to constraints on resources and time, the following items remain open and might be tackled in future work:

  • We showed how Ubuntu Bionic 18.04 was not a valid starting point for secure ROS (Melodic Morenia) industrial deployments. In the future we will look into other Linux file systems and Operating Systems as a starting point. Particularly and given Windows’ popularity in industry and its recent activity and support of ROS for development, we recommend its security evaluation in future research efforts.

  • The security mechanisms in the Robot Immune System (RIS) do not currently allow it to detect threats on its interconnecting components (other devices) and seems a difficult endeavour since it would require RIS (at the endpoint) to constantly monitor and exchange communications with other segments of the industrial network (which will further compromise some of the segmentation and segregation assumptions). Instead, we believe future work should focus on a) reviewing the interoperability services offered by RIS in the robotic endpoint while ensures Zero Trust principles are applied and b) guarantee ROS computational graphs can be hardened regardless of their packages.

  • We only applied a subset of ISA/IEC 62443 and was included into the use case scenario via the hardening step. Future work should extend our setup and complement it with additional security measures following this norm. Though we strongly believe this is of valuable research interest, our interactions with industrial operators indicate that the level of compliance with ICS standards is still on its early phases. Correspondingly, we reckon that the use case assumed while synthetic, captures an already high degree of security measures when compared to real scenarios.

  • While we failed to find exploitable security flaws within the triaged ROS-Industrial drivers, further work needs to be put into mitigating existing ones archived in RVD. Moreover, we encourage for a periodic review of the drivers using both static and dynamic testing.

  • We consider it would be extremely interesting to analyze the dynamics of having heterogeneous robots, from different vendor in a security case study. Future work might consider to extend the scenario we assumed with robots from mixed vendors, mixing ROS packages and incurring into a much more complex software engineering security scenario.

Conclusions

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).

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.

Acknowledgements

This research has been partially funded 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. This research was also financially supported by the Spanish Government through CDTI Neotec actions (SNEO-20181238).

The following names presented in no particular order helped, advised or supported bringing up this work: Bernhard Dieber, Stefan Rass, Martin Pinzger, Alejandro Hernåndez Cordero, Alfonso Glera, Odei Olalde, Lander Usategui San Juan, Gorka Olalde, Xabier Perez-Baskaran, Iñigo Ibiriku, Oxel Urzelai and Nuria García.

Reproduction and results availability

Our setup can be reproduced using the following:

alurity.yaml file to reproduce our setup 
############
# Networks
############
networks:

  # Level 1: Control Networks, connect controllers and control stations
  #  for each controller, we expect a dedicated control-network  w
  - network:
    - name: control-network_c1_s1
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.0.0/24
  - network:
    - name: control-network_c2_s2
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.2.0/24
  - network:
    - name: control-network_c4_s4
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.4.0/24
  - network:
    - name: control-network_c5_s5
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 12.0.5.0/24

  # Level 2: Process Network
  - network:
    - name: process-network
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 13.0.0.0/24

  # Level 3: DMZ 2 sub-network
  # NOTE: used to interface Process Network with machines in DMZ 2
  #  (e.g. a historian, additional servers and related)
  - network:
    - name: dmz2
    - driver: overlay
    - internal: true
    - encryption: false
    - subnet: 14.0.0.0/24

  # Level 4: IT Network
  - network:
    - name: it-network
    - driver: overlay
    - encryption: false
    - internal: true
    - subnet: 15.0.0.0/24

  # Level 3: DMZ 1 sub-network
  # NOTE: used used to interface IT Network with central control station
  - network:
    - name: dmz1
    - driver: overlay
    - encryption: false
    - internal: true
    - subnet: 16.0.0.0/24

  # Beyond lvl4: Cloud
  - network:
    - name: cloud-network
    - driver: overlay
    - encryption: false
    - internal: false
    - subnet: 17.0.0.0/24

#################################
# Firewalls and network elements
#################################
firewalls:
     - container:
       - name: firewall-it-dmz1
       - ingress: it-network
       - egress: dmz1
       - rules:
         - iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
         - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
         - iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
         - iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
         - iptables -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth2 -j ACCEPT
         - route add 13.0.0.20 gw 16.0.0.254 eth2
     - container:
       - name: firewall-process-dmz2
       - ingress: process-network
       - egress: dmz2
       - rules:
         - iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
         - iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
         - iptables -A FORWARD -i eth1 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
         - iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

############
# Containers
############
containers:

  #
  # Controllers
  #
  # C1
  - container:
    - name: "c1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         # - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.12.1
         # - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:3.12.1-controller
         - network:
           - control-network_c1_s1
           # - field-network_r1_c1
    - ip: 12.0.0.20  # assign manually an ip address
    - cpus: 4
    - memory: 2048
    - mount: Controller:/root/.urcaps/

  # C^2
  - container:
    - name: "c2"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         # - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:3.12.1-controller
         - network:
           - control-network_c2_s2
           # - field-network_r2_c2
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install
    - extra-options: SYS_PTRACE
  # C3
  - container:
    - name: "c3"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - process-network
           # - field-network_r3_c3
    - ip: 13.0.0.30  # manually assign an ip address
    - cpus: 4
    - memory: 2048
    - extra-options: SYS_PTRACE
  # C4
  - container:
    - name: "c4"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - control-network_c4_s4
           # - field-network_r4_c4
    - cpus: 4
    - memory: 2048
  # C^5
  - container:
    - name: "c5"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - control-network_c5_s5
           # - field-network_r5_c5
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install
    - extra-options: SYS_PTRACE
  # C^6
  - container:
    - name: "c6"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/robo_ur_cb3_1:3.13.0
         - network:
           - process-network
           # - field-network_r6_c6
    - cpus: 4
    - memory: 2048
    - mount: /tmp/ris_install:/tmp/ris_install    
    - extra-options: SYS_PTRACE

  #
  # Control stations
  #
  # S1
  - container:
    - name: "s1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c1_s1
           - process-network

    - ip:
      - 12.0.0.50  # ip for control-network_c1_s1
      - 13.0.0.5  # ip in process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S^2
  - container:
    - name: "s2"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario-hardened
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c2_s2
           - process-network
    - ip:
        - 12.0.2.50  # ip for control-network_c2_s2
        # - 13.0.0.6  # ip for process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S^4
  - container:
    - name: "s4"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario-hardened
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c4_s4
           - process-network
    - ip: 12.0.4.50  # ip for control-network_c4_s4
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN
  # S5
  - container:
    - name: "s5"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - control-network_c5_s5
           - process-network
    - ip: 12.0.5.50  # ip for control-network_c5_s5
    - cpus: 4
    - memory: 4096
    
  # S7
  - container:
    - name: "s7"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - dmz1
           - process-network
    - ip:
      - 16.0.0.20  # ip in dmz1
      - 13.0.0.20  # ip in process-network
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN

  #
  # Development stations
  #
  # D1
  - container:
    - name: "d1"
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros_ur:melodic-official-scenario
         - network:
           - it-network
           - dmz1
           - cloud-network
           # - process-network  # bypass firewall restrictions by connecting directly
    - ip:
      - 15.0.0.30  # ip in IT
      - 16.0.0.30  # ip in dmz1
      - 17.0.0.30  # ip in cloud
      # - 13.0.0.9
    - cpus: 4
    - memory: 4096
    - extra-options: NET_ADMIN

  #
  # Attackers
  #
  - container:
    - name: attacker_cloud
    - modules:
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_robosploit/expl_robosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_binwalk:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_icssploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_rospento:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_rosploit:latest
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/expl_metasploit:latest
         - network:
           # - it-network
           - cloud-network
    - extra-options: ALL

  - container:
    - name: attacker_dmz1
    - modules:
         # - base: registry.gitlab.com/aliasrobotics/offensive/alurity/alurity:latest
         - base: registry.gitlab.com/aliasrobotics/offensive/alurity/comp_ros:melodic-scenario
         - volume: registry.gitlab.com/aliasrobotics/offensive/alurity/reco_nmap:latest
         - network:
           - dmz1
           - process-network
    - extra-options: ALL

  #
  # extra elements
  #

  # connector of
  #  - it-network
  #  - dmz2
  #  - dmz1
  - container:
    - name: firewall-it-dmz1
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:firewall-three-net
      - network:
        - it-network
        - dmz2
        - dmz1
    - extra-options: NET_ADMIN
    - ip:
      - 15.0.0.254
      - 14.0.0.254
      - 16.0.0.254
  # DMZ machine
  - container:
    - name: dmz-server
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:dmz
      - network: dmz2
    - extra-options: NET_ADMIN
    - ip: 14.0.0.20
  # Connector of process-network and dmz2
  - container:
    - name: firewall-process-dmz2
    - modules:
      - base: registry.gitlab.com/aliasrobotics/offensive/projects/rosin-redros-i:firewall-two
      - network:
        - dmz2
        - process-network
    - extra-options: NET_ADMIN
    - ip:
      - 14.0.0.253
      - 13.0.0.254

In an attempt to bring awareness, transparency and fight against the current trend of security-by-obscurity, most of our tools have been open sourced at https://github.com/aliasrobotics. Results have also been cataloged at the Robot Vulnerability Database. We encourage roboticists and security researchers to dive into the material generated and help triage remaining flaws.

For more, refer to the Red teaming ROS-Industrial extended report (white paper) (56 pages).

4 Likes
2

Thanks for the whitepaper @vmayoral, there were some interesting points in there.

I’m curious though if you could share a bit more about the exploits you describe, I’m not an expert, but from the attacks described in the whitepaper it would seem only the actionlib one is really ROS specific. The others appear to be generic ones which would work against any unpatched/unhardened target.

The actionlib one was an interesting one; would you happen to have identified more of those kinds of vulnerabilities?

3

Glad you enjoyed some of the bits presented @gavanderhoorn. We are somewhat happy about the actionlib flaw, regardless of its simplicity, because it does show evidence that we should care more about our development and deployment processes with ROS (and ROS 2).

Shortly, we used multiple vulnerabilities for the demonstrations and attacks. Some were ROS-specific and some arguably were not (e.g. exploited flaws in underlying systems such as the networking stack or misconfigurations (often catalogued as exposures) in the file system). Within the ROS ones, some were novel like the actionlib issues and some others were known and still remain active. Among the ROS ones, there are flaws like the mentioned ones for actionlib, others that have been previously reported [1], and some others (new) that arguably also could be tagged as ROS-related.

It’s important to highlight that our target was not to find as many security flaws in ROS as possible (this is commonly what a penetration testing does and it was conducted in past work like [1]) but instead evaluate if we could achieve the goals planned via a cyber attack targetting ROS (G_1) and from there the connected robots (G_2) (a targeted offensive exercise is what red teaming is all about).

We indeed conducted testing phases for several months and found a significant amount of bugs which we registered. Specifically, out of static analysis on ROS and ROS-I packages we identified lots of possible flaws (e.g. here). Out of dynamic analysis we located multiple memory overflows and race conditions and further, we built fuzzers which helped us perform more dynamic tests. Fuzzing was conducted first at the OSI L7 layer (on top of ROS abstractions) and later building a ROSTCP package crafter/dissector which allowed much more flexibility fuzzing layers across the OSI stack and seeing the responses at the ROS level. We wrote a piece about this last bit at Hacking ROS and ROS-Industrial communications via underlying protocols with some results. In this article you’ll find two attacks, the first one tackles a well-known vulnerability in TCP (SYN-ACK DoS) which can get mitigated also via proper hardening as documented in our study. The second one, dives into a new flaw from the ROS’s perspective which performs a flooding attack ( FIN-ACK DoS) only feasible due to the lack of authentication and authorization in ROS (vulnerabilities previously discussed in [1], among other articles). Note that the entry point for this attack vector is also TCP as well, however, point in here is that this is exploitable because of the lack of these security considerations in the particular setup of ROS we considered. Is it then a ROS vulnerability (because the version of ROSTCP used doesn’t enforce auth[enticatoin|orization])? or it isn’t?

Bottom line, we collected tons (tons of) evidence to believe that several more like the ROS-specific actionlib flaws were exploitable and attempted to push a portion publicly into RVD (the results of static analysis) so that anyone interested in securing their systems can help triage them. We may push the rest in the future but frankly, it’s lots of work to maintain an archive of security flaws with consistent format when coming from different sources/outputs so I won’t make any commitment beyond what we’ve pushed already. For what concerns our project and research, once we met our objectives, we didn’t dig any further on ROS packages (though there are some interesting ones left). We did dig a bit more on ROS-I packages but we didn’t manage to exploit any of them (which does not mean they aren’t exploitable) within the time we allocated.

Answering more directly, I believe we may have more flaws catalogued like the actionlib one affecting directly ROS or ROS-I packages, we just haven’t invested enough time to build PoCs (including composing and attack, developing and exploit, creating a reproducible setup, etc. ). It’s very expensive to build things constructively, even with the right tooling. We are rapidly improving though so we look forward to continue contributing in this line.

We learned quite a few things while doing this exercise honestly. One key lesson learned is that if we want more flaws like these to appear, be discussed and mitigated, we need a transparent peer-reviewed process of security discussion. If there is enough transparency in the process, once an issue is triaged and an exploit available, mitigation then becomes straightforward and its upstream acceptance simplified. Given how expensive it is to triage things and build PoCs, more the reason to share the load with the community members. We ourselves tested this and filed PRs for a couple of flaws which then got mitigated in less than a couple of days by Open Robotics (this is extremely fast when compared to what we’re seeing with other communities and/or vendors, which frankly take 2 orders of magnitude more of time to fix). From this we confirmed our suspicions that “triaging and transparency are key for accelerating the security cycle”. We have been advocating for this with RVD however the ROS Security WG has disregarded this difficulting security cooperation at multiple levels in this community.

Today, we are conducting a similar study for ROS 2 which hopefully will shed some light into the actual status of cyber security of ROS 2 in production environments. Nevertheless, the path towards a “better security” goes through a) building the right security primitives and b) take control of the security lifecycle process. The second is what’s going to lead us to see more and more vulnerabilities like the one discussed on actionlib.

[1]: Dieber, B., White, R., Taurer, S., Breiling, B., Caiazza, G., Christensen, H., & Cortesi, A. (2020). Penetration testing ROS. In Robot Operating System (ROS) (pp. 183-225). Springer, Cham.

4

First off: Thank you for doing this work. I haven’t had time to look into the whole white paper, so my following comment only concerns the specific actionlib flaw. Sorry in advance that my first response to this is a bit of criticism.

In my opinion, the severity of the actionlib bug is very low. The first thing that should be stated clearly is that the bug is only in the debugging tools axclient and axserver, not in the core actionlib itself.

The whole attack is detailed in section 4.4.1 of the white paper. The attack makes several assumptions:

  1. The attacker has access to a private SSH key who’s public key is listed in authorized_keys of the target machine. (!)
  2. The target machine allows X11 forwarding over SSH.

Based on these assumptions, they construct a launch file that remotely launches axclient on the target machine (that’s what they need assumption 1 for). The axclient window gets displayed over X11 forwarding on the attacker’s machine (assumption 2), and finally a special yaml string is pasted into the axclient window that starts a remote shell on the target machine (here’s where the bug in actionlib comes in).

But the first assumption already gives the attacker access to the machine, right? So they don’t actually need to exploit the actionlib bug in order to get a remote shell on the target machine - they can just SSH into it. In other words: this bug is only exploitable if the attacker already has full access, gaining them nothing.

Nevertheless, the bug should of course be fixed, and already has been, thanks to the team at aliasrobotics. :+1:

2 Likes
5

Hi @Martin_Guenther and thanks for sharing your thoughts.

Thanks also for reviewing that piece of our work! A_1 is indeed constructed on those assumptions which we detail all in the paper, as you nicely highlighted. There’s truth in your criticisms in that (at least as far as we looked into it and with this flaw), remote code execution demands for these conditions to be met.

Note however that we looked at this in the context of a particular use case which we tried detailing :). Such use case was constructed following ICS guidelines as well as ROS community ones. E.g. roslaunch/XML/machine - ROS Wiki hint towards key exchange for increased robustness (and frankly, we’ve seen much worse than D_1 exchanging keys with \hat{S_7}, though of course we wouldn’t approve it if we were to advice on such a deployment).

I believe @mgrrx shared a similar feeling, I’d invite both to jump into RVD#2401: Use of unsafe yaml load, ./src/actionlib/tools/library.py:132 · Issue #2401 · aliasrobotics/RVD · GitHub and share your views on how would you improve/modify the existing severity assessed (refer to the CVSS vector in there). Help is definitely welcome improving the tickets.

This is arguable and we droped a few comments on this as well (starting in page 25):

Privilege escalation, attacker obtains limited access to \hat{S_7} via other means: 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 is 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 restrictions we were not able to confirm this, however we suspect it to be possible unless ROS specific measures on user privilege-separation have been taken.

We didn’t build a PoC so I can’t state anything for sure but my gut feeling is that it might lead to an interesting result.

1 Like
6

Needless to say, we would love to hear your thoughts on A_2, A_3 and A_4 as well @Martin_Guenther and @mgrrx.

7

I’m really happy these topics get the needed attention, but personally, I always start to almost lose interest when I read “could, potentially, eventually, lead to 
 under the right circumstances, in case of a coincident exploit in X, such that we can cross-over to Y, if there would be 
”.

Coming from a scientific environment I certainly appreciate the reservedness which one almost must use when making these kinds of statements, but sometimes I wish security researchers could just keep it to what they found and not speculate so much :wink: . It always makes things sound so dramatic. Just state the facts, they are bad enough already.

(yes, I realise they’re not always to blame, as popular media can do really atrocious things to carefully crafted statements (from scientists and others))

4 Likes
8

(I know this is old, but this is the thread people seem to find while Googling and ask me about, so I’m posting a final follow-up here)

I’ve been getting some questions about why I seem to say here I don’t think security research (in the context of ROS and/or robotics) is important or why I seem to dismiss the results achieved by @vmayoral and his team.

Just to be clear: security research is always important. Period. It doesn’t matter which field it targets, or in which context it is done.

Having written that: what I referred to in my comments was the tendency (which I personally felt I’d observed in some of the publications on the subject I read at the time) to speculate about what could potentially be consequences of any particular bug, flaw, mistake, vulnerability or something else identified while red teaming, analysing or pen testing.

Stating the facts should be sufficient (holes in software are bad enough). Speculation about what could potentially be done hopping from vulnerability to vulnerability quickly appears contrived and dilutes the message.

3 Likes