ICS OT
Defending the Supply Chain: Why the DDS Protocol is Critical in Industrial and Software Systems
In 2021, a team of researchers from Trend Micro Research, TXOne, ADLINK, Alias Robotics, and ZDI looked into the Data Distribution Service (DDS) standard and its implementations from a security angle. The full findings of this research will be presented in the S4X22 Conference in April 2022.
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. Er steuert seit etwa einem Jahrzehnt Eisenbahnen, autonome Fahrzeuge, Flughäfen, Raumfahrzeuge, bildgebende Diagnosegeräte, Gepäckabfertigung, Industrieroboter, Militärpanzer oder auch Fregatten, und seine Verbreitung nimmt stetig zu. Deshalb haben wir innerhalb eines Forschungsprojekts, eine Zusammenarbeit von Trend Micro Research und TXOne Networks, ADLINK Labs, Alias Robotics und Trend Micro Zero Day Initiative (ZDI) die Middleware unter die Lupe genommen. Wir analysierten die DDS-Spezifikationen und die sechs Implementierungen, die von zertifizierten Anbietern mit Millionen von Implementierungen weltweit gepflegt werden. Wir entdeckten mehrere Sicherheitslücken, die zu 13 neuen CVE-IDs für die sechs gängigsten DDS-Implementierungen geführt haben. Dazu gehören eine Schwachstelle in den Standardspezifikationen und andere Einsatzprobleme im DDS-Software-Ökosystem (einschließlich eines vollständig offenen Produktionssystems). Diese Schwachstellen wurden, seit wir sie gemeldet haben, von den Anbietern gepatcht oder behoben.
Wir fanden innerhalb eines Monats in 34 Ländern 643 verschiedene öffentlich zugängliche DDS-Dienste, die 100 Organisationen über 89 Internet Service Provider (ISPs) betrafen. Von den DDS-Implementierungen von sieben verschiedenen Anbietern wurden 202 private IP-Adressen (die sich auf Details der internen Netzwerkarchitektur beziehen) und sieben vermeintlich geheime URLs veröffentlicht. Ein paar dieser IP-Adressen exponieren nicht gepatchte oder veraltete DDS-Implementierungen, die von einigen der Schwachstellen betroffen sind, die wir im November entdeckten und veröffentlicht haben.
Die erfolgreiche Ausnutzung dieser Schwachstellen in einem der kritischen Sektoren, in denen DDS eingesetzt wird, kann folgende Folgen haben (einschließlich der Nomenklatur, die sich auf den ATT&CK-ICS-Rahmen bezieht):
- Kontrollverlust (T0827)
- Safety-Verlust (T0880)
- Denial of Service (DoS, T0814) via Brute Force (T0806)
- Erleichtert Erstzugang (TA0108) über Missbrauch von Remote Services (T0866, T0886) oder Kompromittierung der Supply Chain (T0862)
- Ermöglicht Angreifern Erkundungen durchzuführen (TA0102, T0856) über den Missbrauch des Discovery-Protokolls
- Missbrauch des Protokolls selbst, um einen effizienten Command-and-Control-Kanal zu schaffen (T0869)
Unsere Erkenntnisse gelten weltweit und betreffen Milliarden von Geräten in allen vertikalen Bereichen, einschließlich aller kritischen Anwendungen wie autonomes Fahren, intelligenter öffentlicher Verkehr, Telekommunikation, Cloud, Gesundheitswesen, Verbraucher- und Industrierobotik sowie Verteidigungssysteme. Da es sich um eine kritische Technologie handelt, die nur wenig Aufmerksamkeit erhält, empfehlen wir anderen Forschern, DDS-Nutzern und Implementierern, das Sicherheitsbewusstsein für DDS und sein Ökosystem zu fördern. Nach unserer Analyse empfehlen wir Abhilfemaßnahmen wie:
- Schwachstellen-Scanning (M1016)
- Network Intrusion Prevention (M1031)
- Netzwerksegmentierung (M1030)
- Filtern des Netzwerkverkehrs (M1037)
- Verhindern der Ausführung (M1038)
- Auditing (M1047)
Auf der Grundlage unserer Erkenntnisse und einer Präsentation ihrer Auswirkungen auf die Schlüsselsektoren des DDS plädieren wir für kontinuierliche Sicherheitstests des DDS und anderer damit verbundener kritischer Technologien. Wir geben auch umsetzbare Empfehlungen für eine sichere DDS-Integration.
Um das Bewusstsein für die Bedeutung der DDS-Sicherheit zu schärfen, stellen wir in einem weiteren Beitrag den Standard vor und zeigen zwei Beispiele, wie ein Angreifer den Netzwerkverkehr intensivieren kann, was zu Echtzeit- und Determinismusproblemen führt, oder bewirken kann, dass ein autonomes Fahrzeug die Kontrolle verliert und mit Objekten kollidiert, 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).
DDS wird unter anderen von diesen Organisationen genutzt:
- National Aeronautics and Space Administration (NASA) im Kennedy Raumfahrtzentrum
- Siemens AG in Windkraftwerke
- Volkswagen und Bosch für autonome Parkservice-Systeme
- Nav Canada und European ATM Performance CoFlight für Luftverkehrskontrolle
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.
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.
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™, and EdgeFire™ sind durch folgende Regel geschützt:
- 1137699 ICS DDS RTPS-mode Amplification Attack (CVE-2021-38429)
Sehen Sie auch unser Video zum Thema:
https://youtu.be/fUvggLRMq1M?list=TLGGyxo9EKJ14NMwMzAyMjAyMg