DDS: Bedrohungen und Abwehr

Originalartikel von Federico Maggi, Erik Boasson, Mars Cheng, Patrick Kuo, Chizuru Toyama, Víctor Mayoral Vilches, Rainer Vosseler, Ta-Lun Yen, Threat Researchers

Der Data Distribution Service (DDS)-Standard ist die am weitesten verbreitete, kritischste und am wenigsten bekannte Middleware-Technologie, die Eisenbahnen, autonome Fahrzeuge, Flughäfen, Raumfahrzeuge, bildgebende Diagnosegeräte, Gepäckabfertigung, Industrieroboter, Militärpanzer oder auch Fregatten steuert. Innerhalb eines Forschungsprojekts haben wir in Zusammenarbeit von Trend Micro Research und TXOne Networks, ADLINK Labs, Alias Robotics und Trend Micro Zero Day Initiative (ZDI) die DDS-Spezifikationen und sechs Implementierungen analysiert, die von zertifizierten Anbietern mit Millionen von Implementierungen weltweit gepflegt werden. In unserem ersten Beitrag stellten wir die Ergebnisse dar, die Bedrohung, die von der Ausnutzung der Schwachstellen ausgehen kann, und empfahlen einige Abwehrmaßnahmen. Nun sollen zwei Beispiele zeigen, was passieren kann, wenn nicht die richtigen Sicherheitsmaßnahmen getroffen werden.

Was ist DDS und warum ist die Technologie kritisch?

DDS ist eine Machine-to-Machine-Technologie für Publish-Subscribe-Middleware-Anwendungen in Echtzeit und Embedded Systems. Dieser Standard wird von der Object Management Group (OMG) gepflegt und wird für alle Arten von kritischen Anwendungen eingesetzt, um zuverlässige Kommunikationsschichten zwischen Sensoren, Steuerungen und Aktoren zu implementieren.

Wenn beispielsweise die künstliche Intelligenz (KI) eines autonomen Fahrzeugs den Befehl „links abbiegen“ geben muss, wird DDS verwendet, um diesen Befehl von der elektronischen Steuereinheit (ECU) (dem „Gehirn“ des Fahrzeugs) zu den Servomotoren der Lenkung zu übertragen. Dasselbe geschieht auch, wenn Geschwindigkeitssensoren Informationen vom Motor zum Steuergerät senden. Wir haben verifiziert, dass das DDS erfolgreich auf Starterkit-Steuergeräten läuft, was jedes autonome Fahrzeug, das auf diesem Hardware- und Software-Stack basiert, anfällig für unsere Erkenntnisse macht.

Ein anderes Beispiel wäre ein Flughafenbetreiber, der im Tower die Landebahn beleuchten muss. Auf modernen Flughäfen werden diese spezifischen Signale per Software übertragen, und DDS wird eingesetzt, um die rechtzeitige Übermittlung der Befehle zu gewährleisten. Die durchschnittliche Start- und Landebahn eines Flughafens hat Tausende von Kontrollpunkten: Wenn man bedenkt, dass es weltweit mehr als 10.000 (und voraussichtlich 44.000) Flughäfen gibt, von denen jeder durchschnittlich 2,5 Start- und Landebahnen (bis hin zu 36) hat, dann würde dies, selbst wenn nur 1 % von ihnen DDS verwendet (konservativ geschätzt), etwa 250.000 DDS-Knoten (bis hin zu 1,1 Mio.) allein in Flughäfen ergeben.

DDS steht ganz am Anfang der Software-Supply Chain und kann daher leicht aus dem Fokus zu geraten. Deshalb ist der Service für Angriffe oder Kompromittierung attraktiv. Zwischen 2020 und 2021 zielten 66 % der Angriffe in der Softwarebranche auf die Software von Lieferanten ab. Bei unseren Untersuchungen stießen wir auf ein exponiertes Quellcode-Repository, das eine proprietäre Implementierung von DDS enthielt, wodurch ein Angreifer den Quellcode hätte infizieren können (T0873, T0839).

Bild 1. DDS ist eine standardisierte Softwarebibliothek für softwaregestützt kontrollierte Systeme, direkt oder über das Betriebssystem ROS 2

DDS wird unter anderen von diesen Organisationen genutzt:

Die Middleware stellt auch die Grundlage für weitere Industriestandards dar, wie etwa Open Field Message Bus (OpenFMB) für  Smart-Grid Applikationen, Adaptive AUTOSAR, Medical Device Plug-and-Play (MD PnP) Interoperability Program, Generic Vehicle Architecture (GVA) und NATO GVA (NGVA). Das Robot Operating System 2 (ROS 2), das De-facto-Standardbetriebssystem für Roboter und Automatisierung, setzt DDS als Standard-Middleware ein. Die kürzlich von der NASA ins Leben gerufene Space ROS-Initiative wird ROS 2 im Weltraum einsetzen. DDS wird außerdem für Systemvirtualisierungs- und Cloud-Computing-Anwendungen verwendet, hauptsächlich für den Datenaustausch zwischen Maschinen und Rechenzentren.

Eine Schwachstelle in den Spezifikationen des Standards

Wie jedes andere technische Produkt weist auch DDS Schwachstellen in seiner Codebasis und seinem Ökosystem auf (z. B. Entwicklungswerkzeuge, Cloud-Backends, Docker Images und Integrationsbibliotheken). Ein auffälliger Fund betrifft eine Amplifikationsschwachstelle (CVE-2021-38487, CVE-2021-38429), die es einem böswilligen Akteur ermöglicht, Angriffe zur Überflutung des Netzwerks auszulösen, indem er ein einzelnes DDS-Discovery-Paket fälscht. Wird diese Schwachstelle ausgenutzt, führt dies zu einer Fehlfunktion des Services und zur Beschädigung der Echtzeit-Eigenschaften der Kommunikation. Interessanterweise lässt sich diese Amplifikationsschwachstelle schon beim Lesen der DDS-Standardspezifikationen erkennen. Diese sehen keine angemessenen Überprüfungen vor, mit denen sich Fälle vermeiden ließen, die ein Angreifer ausnutzen könnte. Wir haben überprüft, dass derselbe Exploit unverändert bei mehreren Produkten funktioniert, und das bestätigt, dass es sich nicht nur um ein implementierungsspezifisches Problem handelt.

Bild 2. Durch Spoofing des Teilnehmer-Locators kann jeder Teilnehmer vorgeben, ein anderer zu sein, und der Empfänger ist gezwungen (gemäß der Spezifikation), so lange zu antworten, bis er eine gültige Bestätigung erhält

Exponierte DDS-Entwicklungsumgebung

Bei der Suche nach exponierten Continuous-Integration/Continuous-Deployment (CI/CD)-Systemen über Shodan stellten wir fest, dass ein DDS-Entwickler seine benutzerdefinierte CI/CD-Umgebung vollständig dem Internet mit Standard-Anmeldedaten zugänglich gemacht hatte. Trotz unserer zahlreichen Versuche, diesen Anbieter zu kontaktieren, auch über Schwachstellen-Broker und Computer Emergency Readiness Teams (CERTs), erhielten wir keine Antwort. Glücklicherweise wurde die Umgebung nach einigen Monaten angemessen abgesichert.

Mögliche Konsequenzen

Ein Angreifer, der über funktionierende Exploits für diese Schwachstellen verfügt, könnte den normalen Betrieb eines Zielgeräts durch Netzwerk-DoS stören, sich lateral bewegen oder (in einigen Fällen) einen Computer kontrollieren. Da DDS in unternehmenskritischen Anwendungen eingesetzt wird, kann selbst eine einfache DoS-Funktion als Sprungbrett für mächtige, erpresserische Angriffe genutzt werden, wie 2020 und 2021 geschehen. Wir fanden 643 eindeutige IPs, die DDS-Endpunkte offenlegen. Wenn man bedenkt, dass DDS nur in einem lokalen Netzwerk eingesetzt werden soll, ist 643 eine beachtliche Zahl. Darüber hinaus geben einige dieser Endpunkte Informationen über die interne Netzwerkstruktur preis, wie z. B. private IPs.

Anhand der Merkmale und Daten dieser Endpunkte konnten wir Vermutungen über die DDS-Produktversion anstellen, die dahinter läuft. Wir können sagen, dass alle bis auf vier von ihnen für mindestens eine unserer CVEs anfällig sind (vergleichen Sie die CVE-Tabelle mit der Versionsspalte).

Die Network Reflection-Schwachstelle betrifft sowohl die Spezifikationen als auch die meisten Implementierungen. Eclipse CycloneDDS und GurumDDS sind nicht betroffen, was bedeutet, dass sie über eingebaute Abhilfemaßnahmen verfügen (obwohl sie immer noch anfällig für Reflection-Angriffe sind). Darüber hinaus sind die meisten Implementierungen von mindestens einer Sicherheitslücke betroffen. Die Möglichkeit der Ausnutzung (T1210) kann je nach Laufzeitumgebung variieren. Insbesondere Schutzmaßnahmen wie Stack Canaries oder Address Space Layout Randomization (ASLR), die normalerweise in herkömmlichen Endgeräten verfügbar sind, werden in eingebetteten Systemen nicht immer implementiert.

Tabelle 1. Zusammenfassung der gefundenen Schwachstellen mit den zugewiesenen CVEs in den wichtigsten DDS-Implementierungen und Standardspezifikationen

Wir haben nur einige der Kompromittierungen und Angriffen aufgeführt, falls diese DDS-Schwachstellen ungesichert bleiben, zusammen mit der entsprechenden MITRE ATT&CK ICS-Taxonomie — Kontrollverlust (T0827), Sicherheitsverlust (T0880) und Denial-of-Service (T0814) über Brute-Forcing (T0806). Darüber hinaus sind mehrere Implementierungen von Stack- oder Heap-basierten Overflow-Schwachstellen betroffen, die ausgenutzt werden können, um den Erstzugriff (TA0108) über die Ausnutzung von Remote-Diensten (T0866, T0886) zu erleichtern.

Da drei bekannte DDS-Distributionen quelloffen sind, ist eine Kompromittierung der Supply-Chain (T0862) in jedem Fall ein mögliches Szenario. Durch das Erstellen eines automatisierten Netzwerk-Scanners haben wir nachgewiesen, dass ein Angreifer eine automatische Discovery (TA0102, T0856) durchführen kann, indem er das integrierte Discovery-Protokoll missbraucht, oder sogar das Protokoll selbst, um einen effizienten Command-and-Control-Kanal zu erstellen (T0869).

Abhilfemaßnahmen: Über das Patchen hinaus

Kurzfristig empfehlen wir Abhilfemaßnahmen wie regelmäßige Schwachstellen-Scans (M1016), um nicht gepatchte Dienste zu finden, den Einsatz von Network Intrusion Prevention (M1031), Netzwerksegmentierung (M1030) und Filterung des Netzwerkverkehrs (M1037), um gefälschte DDS-Nachrichten zu erkennen und die Ausnutzung der Reflection-Schwachstelle zu verhindern. Wir empfehlen auch Maßnahmen zur Verhinderung der Ausführung (M1038), um die Ausnutzung von Speicherfehlern zu verringern, und regelmäßige Audits (M1047).

Wenn es um die Sicherheit kritischer Software wie DDS in der Supply Chain geht, so es dringend erforderlich, die Codebasis zugänglicher zu machen für die Integration automatisierter Sicherheitstest-Tools. Nehmen wir das Fuzz-Testing als Beispiel: Alle kritischen Softwarebibliotheken wie DDS sollten zusätzlich zu den traditionellen Unit-Tests stark auf Sicherheitstests ausgerichtet werden. Die Situation hat sich dank Initiativen wie OSS-Fuzz enorm verbessert, doch existiert immer noch eine Kluft zwischen Sicherheitsingenieuren und Softwareentwicklern. Dies führt zu langwierigen manuellen Code-Reviews, unerwünschten Änderungen am Code zur Integration von Sicherheitsprüfungen usw.

Last but not least, soll hier die positive und engagierte Reaktion von ADLINK auf unsere Enthüllung erwähnt werden, die sogar so weit ging, den Trend Micro-Forschern bei der Erstellung guter Fuzz-Targets für ihre eigene Codebasis zu helfen. Dies sollte der gesamten Softwareentwicklungsbranche als Beispiel dienen.

Trend Micro-Lösungen

Die Kunden von Trend Micro™ TXOne™, Networks EdgeIPS Pro™EdgeIPS™ und EdgeFire™ sind durch folgende Regel geschützt:

  • 1137699 ICS DDS RTPS-mode Amplification Attack (CVE-2021-38429)

Sehen Sie auch unser Video zum Thema:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.