Privacy & Risks
Data Distribution Service: Mitigating Risks Part 3
In the final chapter of our blog series, we discuss mitigating strategies and recommendations to keep DDS protected from malicious actors.
Save to Folio
In part two, we thoroughly discussed both known and newly discovered vulnerabilities affecting DDS. Thirteen vulnerabilities discovered by our team were given new CVE IDs in November 2021 from the six most common DDS implementations, plus one vulnerability in the standard specifications.
For the final, let’s explore an attack scenario to showcase what would happen if DDS is compromised, several mitigation strategies and recommendations that enterprises can utilize to ensure their systems are well-protected.
Attack scenario: Autonomous Driving Platform
The impact of any vulnerability in the DDS can be fully appreciated only by considering how it’s embedded in a final product, considering that the middleware is at the very beginning of the software supply chain.
In this attack scenario, we look will infiltrate an autonomous driving platform which uses a software-based simulation of an autonomous-driving mobile robot based on the ROS 2 stack, which uses DDS as its default middleware.
We created a simulated environment using Gazebo, a simulator used by roboticists to test algorithms, design robots, perform regression testing, and train AI systems using realistic scenarios.
The teleoperated autonomous-driving mobile robot runs a ROS 2 graph that moves it in a 3D-simulated world, avoiding obstacles thanks to a Lidar sensor, exactly like the sensor used by TurtleBot3.
Both CVE-2021-38447 and CVE-2021-38445 affects OpenDDS, leading ROS 2 nodes to either crash or execute arbitrary code due to DDS not handling the length of the PID_BUILTIN_ENDPOINT_QOS parameter within RTPS’s RTPSSubMessage_DATA submessage properly. With the Scapy RTPS layer (), creating an exploit for these vulnerabilities is as easy as setting the parameter Length to 4 null bytes.
This shows the mobile robot moving in a 3D environment with nine obstacles (seen as white circles), with the Lidar sensor “seeing” clear ways (blue areas) that the robot can take. On the left side, the controlling loop printing debug information about the velocity along each axis can be seen.
We created an attacker on the network that sends an RTPS payload with parameter Length set to 4 null bytes, causing the DDS layer underneath the ROS 2 node to crash abruptly. The Lidar sensor is still sending information about obstacles, but this is not delivered in time (if at all), causing the control loop to miss deadlines. Consequently, the robot will be blind to obstacles or won’t see them in time.
Recommendations
Following the MITRE ATT&CK® nomenclature, we recommend the implementation of mitigation best
practices such as:
- Periodic vulnerability scanning (M1016) to detect the presence of unpatched services
- Deploying network intrusion prevention (M1031)
- Network segmentation (M1030)
- Filtering of network traffic (M1037) to detect spoofed DDS messages and prevent the exploitation of the reflection vulnerability
- Execution prevention (M1038) to reduce the exploitation of memory errors
- Periodic auditing (M1047)
Short-term mitigation
Our internet-wide scanning revealed hundreds of exposed DDS endpoints. However, some of these were running unpatched or otherwise outdated versions of DDS, making them vulnerable to some of the weaknesses we discovered. We recommend never exposing a DDS endpoint unless necessary. We also recommend securing it with DDS Security.
If patching is not possible, or in cases where a patch is not available (such as the amplification vulnerability) we recommend deploying IPS rules to spot forged or malicious packets. Trend Micro’s TXOne™ Networks EdgeIPS Pro™, EdgeIPS™, and EdgeFire™ customers are protected under rule 1137699 ICS DDS RTPSmode Amplification Attack (CVE-2021-38429). Similarly, there are endpoint protection rules that can be configured to detect anomalous XML files.
Supply chain management of critical libraries
When dealing with supply chain security of critical software such as DDS, proper supply chain management processes allow immediate contextualization of a new vulnerability within the myriad of downstream software utilizing a certain library. We believe that using CWE-1104 is a simple but practical and effective way to pinpoint security-sensitive components in the software supply chain. The mere use of an unmaintained component is a weakness, especially if that component carries known vulnerabilities.
Shift-left approach and continuous fuzzing
The second most pressing need after managing current active assets is to make the code base more amenable to the integration of automated security-testing tools. We advocate that all critical software libraries such as DDS should be developed with a strong orientation to security testing, on top of traditional unit testing. The situation has improved greatly, thanks to initiatives such as OSS-Fuzz. But there’s still a significant gap between security engineers and software engineers, resulting in tedious manual code reviews, unwanted modifications in the code to integrate security checks, and so on.
What to know more about DDS and its security? Download our compressive technical report, “A Security Analysis of the Data Distribution Service (DDS) Protocol”, here.