- Join BJ's Wholesale Club for $20, and get a $20 gift card: Deal
- Delivering better business outcomes for CIOs
- Docker Desktop 4.35: Organization Access Tokens, Docker Home, Volumes Export, and Terminal in Docker Desktop | Docker
- Cybercriminals Exploit DocuSign APIs to Send Fake Invoices
- Your iPhone's next iOS 18.2 update may come earlier than usual - with these AI features
Data Distribution Service: Exploring Vulnerabilities and Risks Part 2
Privacy & Risks
In part two of our series, we’ll highlight both known and new DDS vulnerabilities and what they mean for mission critical operations.
July 06, 2022
Read time: ( words)
In part one, we have an exhaustive overview of Data Distribution Services (DDS). We also highlighted where this middleware software is used, which includes systems that drive systems such as railways, autonomous cars, spacecraft, diagnostic imaging machines, and military tanks, among others.
In this installation, we highlight the current status of DDS, its vulnerabilities and risks.
Vulnerabilities and exposure
The complexity of parsing dynamic and custom-defined data types (known to be prone to bugs) makes DDS a security-critical building block. A single vulnerability will impact the rest of the software stack. Aside from software vulnerabilities, we found DDS hosts being incidentally exposed on public-facing networks such as the internet.
Here are known vulnerabilities that researchers before us have identified. These know vulnerabilities allow local or remote attackers compromise a system or conduct a DoS-based attack:
Four out of seven of publicly known vulnerabilities have yet to be assigned a CVE ID, specifically for reconnaissance of the Nessus script. This lack of an ID prevents tracking patches, exploits, and network signatures, making identification and monitoring also difficult for security teams and researchers.
We also noted that CVE-2019-15135 affects all DDS Security extensions, which adds confidentiality, integrity, and authentication to DDS. When abused, CVE-2019-15135 allows an attacker to collect information about the DDS nodes in a network due to the verbosity of the DDS security layer. The layer sends cleartext metadata such as endpoint identifiers, internal IP addresses, vendor, and product version.
Here are new vulnerabilities we discovered, affecting ROS 2:
Vulnerabilities affecting network attack surfaces let attackers perform spoofing, reconnaissance, and automated data. Collection and denial of service. This will in turn affect an exposed system. The vulnerabilities affecting configuration attack surface can negatively impact the developer or system integrator and potentially compromise the integrity of the software supply chain.
By focusing on RTPS (de)serialization and XML parsing functions, we discovered nine vulnerabilities allowing an attacker read-or-write access to the stack or the heap, and up to 6 bytes into the instruction pointer.
To complement our understanding of the security posture of DDS vendors, we also looked at the available Docker images related to or based on DDS implementations and found these:
Additionally, we discovered hundreds of distinct IPs reflecting packets to our collector, with some of them still continuing to send us data from day zero. We received data from all six DDS “flavors,” plus one (namely ETRI Technology) that we were initially unaware of.
Table 6 shows the data classified according to DDS vendor, confirming that our initial selection of the six DDS implementations matches the popularity of these platforms. We used the version information (when available) to estimate how many services are running outdated versions of DDS. Note that “N/A” means that we were unable to find any version information, making the estimation a lower bound of the real numbers.
Almost 63% of the publicly accessible endpoints exposed at least one private IP (for example, 172.16.0.8 and 192.168.3.10), a total of 202 private IPs. In addition, we found seven Rebus70 URLs, which reference internal endpoints. All the URLs contained a keyword that uniquely identified a leading manufacturer of telecom equipment.
Following the zero-trust principle, every component of a software supply chain should at least be analyzed for the presence of known security vulnerabilities. It is also a common best practice to continuously update software versions.
In the final part of the series, we’ll focus on how these vulnerabilities can be mitigated. We’ll also discuss our findings and recommendations.
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.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
