Data Distribution Service: Mitigating Risks Part 3

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.



Source link