Por qué el protocolo DDS es fundamental en los sistemas industriales y de software

Fecha de publicación
Cateogría del artículo Tecnología
Visualizaciones del artículo Leído  2556  veces

En 2021, un equipo de investigadores de Trend Micro Research, TXOne, ADLINK, Alias Robotics y ZDI estudió el estándar Data Distribution Service (DDS) y sus implementaciones desde el punto de vista de la seguridad. Avanzamos algunas de las ocnclusiones del estudio que se presentará de manera ampliada en la Conferencia S4X22 en abril de 2022.

Por qué el protocolo DDS es fundamental en los sistemas industriales y de software

Un artículo de Federico Maggi, Erik Boasson, Mars Cheng, Patrick Kuo, Chizuru Toyama, Víctor Mayoral Vilches, Rainer Vosseler y  Ta-Lun Yen

Si existiera un premio a la tecnología de middleware más omnipresente, crítica y menos conocida, el estándar del Servicio de Distribución de Datos (DDS) lo ganaría sin duda. Cuando presentamos por primera vez los resultados de esta investigación en las sesiones informativas de Black Hat Europe, el público parecía desconocer por completo (incluso avergonzado) que DDS impulsa los ferrocarriles, los coches autónomos, los aeropuertos, las naves espaciales, las máquinas de diagnóstico por imagen, la manipulación de equipajes, los robots industriales, los tanques militares y las fragatas desde hace aproximadamente una década, y que su adopción aumenta constantemente.

Dada la omnipresencia de esta tecnología, decidimos investigar más a fondo y descubrimos múltiples vulnerabilidades de seguridad, lo que dio lugar a 13 nuevas identificaciones CVE para las seis implementaciones de DDS más comunes. Esto incluye una vulnerabilidad en las especificaciones estándar y otros problemas de implementación en el ecosistema del software DDS (incluyendo un sistema de producción totalmente abierto). Estas vulnerabilidades han sido parcheadas o mitigadas por los proveedores desde que informamos de ellas.

Figura 1. Encontramos sistemas DDS expuestos en 34 países, incluyendo los vulnerables, identificados a través de distintas IPs que filtran datos

Al medir la exposición de los servicios DDS, en un mes encontramos 643 servicios DDS distintos de cara al público en 34 países que afectan a 100 organizaciones a través de 89 proveedores de servicios de Internet (ISP). De las implementaciones de DDS por parte de siete proveedores distintos (uno de los cuales desconocíamos inicialmente), se filtraron 202 direcciones IP privadas (referidas a detalles de la arquitectura de red interna) y siete URL supuestamente secretas. Algunas de estas direcciones IP exponen implementaciones DDS sin parches o anticuadas, que están afectadas por algunas de las vulnerabilidades que hemos descubierto y revelado en noviembre.

Esta investigación es fruto de la colaboración de Trend Micro Research y TXOne Networks (Federico Maggi, Mars Cheng, Patrick Kuo, Chizuru Toyama, Rainer Vosseler y Ta-Lun Yen), ADLINK Labs (con Erik Boasson, uno de los inventores y desarrolladores principales de DDS), Alias Robotics (con Víctor Mayoral Vilches, arquitecto de robótica) y Trend Micro Zero Day Initiative (ZDI). Analizamos las especificaciones de DDS y las seis implementaciones mantenidas por proveedores certificados con millones de despliegues en todo el mundo. Durante nuestra investigación, entrevistamos a los principales usuarios de DDS y a los integradores de sistemas para recabar su opinión sobre nuestros hallazgos y la importancia de DDS para la innovación en sus respectivos sectores.

En un mes encontramos 643 servicios DDS distintos de cara al público en 34 países que afectan a 100 organizaciones a través de 89 proveedores de servicios de internet

Como pieza crítica de la tecnología que recibe poca atención y teniendo en cuenta nuestros hallazgos, animamos a otros investigadores, usuarios de DDS e implementadores a promover la conciencia de seguridad sobre DDS y su ecosistema. La explotación exitosa de estas vulnerabilidades en cualquiera de los sectores críticos en los que se utiliza el DDS puede tener consecuencias, tales como (incluyendo la nomenclatura referida al marco ATT&CK ICS):

- pérdida de control (T0827)
- pérdida de seguridad (T0880)
- denegación de servicio (DoST0814) mediante fuerza bruta (T0806)
- facilitar el acceso inicial (TA0108) mediante la explotación de servicios remotos (T0866T0886) o el compromiso de la cadena de suministro (T0862)
- permitir que los atacantes realicen el descubrimiento (TA0102T0856) abusando del protocolo de descubrimiento
- abusar del propio protocolo para crear un canal de mando y control eficiente (T0869)

Según nuestro análisis, recomendamos mitigaciones como:

- exploración de vulnerabilidades (M1016)
- prevención de intrusiones en la red (M1031)
- segmentación de red (M1030)
- filtrar el tráfico de red (M1037)
- prevención de ejecución (M1038)
- auditoría (M1047)

Nuestros hallazgos se aplican en todo el mundo y afectan a miles de millones de dispositivos en todos los sectores verticales, incluidas todas las aplicaciones críticas tales como la conducción autónoma, el transporte público inteligente, las telecomunicaciones, la nube, la atención médica, la robótica industrial y de consumo, y los sistemas de defensa.

Abogamos por la realización de pruebas de seguridad continuas de DDS y de otras tecnologías críticas relacionadas.

Basándonos en nuestros hallazgos y en la demostración del impacto de DDS en sectores clave, abogamos por la realización de pruebas de seguridad continuas de DDS y de otras tecnologías críticas relacionadas. También proporcionamos recomendaciones prácticas para una integración segura del DDS. Para ayudar a concienciar sobre la importancia de la seguridad del DDS, proporcionamos dos ejemplos que muestran cómo un atacante puede amplificar el tráfico de la red, provocando problemas de tiempo real y de determinismo, o hacer que un vehículo autónomo pierda el control y colisione contra objetos cuando se implementa sin las medidas de seguridad adecuadas.

Dado que el DDS es poco conocido, pero bastante omnipresente, animamos a los expertos en la materia a reutilizar nuestras pruebas de concepto para aumentar la concienciación y ayudar a los responsables de la toma de decisiones a asignar los recursos adecuados para asegurar las implantaciones de DDS actuales y futuras.

¿Qué es el DDS y por qué es fundamental?

DDS es una tecnología de máquina-a-máquina utilizada para aplicaciones de middleware de publicación-suscripción en sistemas de tiempo real** y embebidos. Este estándar lo mantiene  Object Management Group (OMG) y se utiliza en toda clase de aplicaciones críticas para implementar capas de comunicación fiables entre sensores, controladores y actuadores.

Por ejemplo, cuando la inteligencia artificial (IA) de un coche autónomo necesita emitir una orden de "giro a la izquierda", se utiliza DDS para transportar esa orden desde la unidad de control electrónico (ECU) (el "cerebro" del coche) hasta los servomotores de dirección. Lo mismo ocurre cuando los sensores de velocidad envían información desde el motor hasta la ECU. Hemos comprobado que el DDS funciona con éxito en las ECU del kit de arranque, lo que hace que cualquier vehículo autónomo basado en este stack de hardware y software sea susceptible de nuestros hallazgos.

Otro ejemplo es cuando un operador aeroportuario de la torre de control del tráfico aéreo necesita iluminar la pista de un aeropuerto. En los aeropuertos modernos, estas señales específicas se transmiten a través de software, y el DDS se utiliza para garantizar la entrega oportuna de esos comandos. La pista media de un aeropuerto tiene miles de puntos de control: si se tiene en cuenta que hay más de 10.000 (se espera que lleguen a ser 44.000) aeropuertos en el mundo, cada uno con una media de 2,5 pistas (hasta 36), incluso si solo el 1% de ellos utilizara DDS (de forma conservadora), esto haría que hubiera unos 250.000 nodos DDS (hasta 1,1M) solo en los aeropuertos.

Como se ve en la figura 1, DDS está en el inicio de la cadena de suministro de software, por lo que es fácil perderle el rastro. Debido a esto, DDS es atractivo para ser atacado o comprometido por el impacto resultante. Entre 2020 y 2021, el 66% de los ataques en la industria del software tuvieron como objetivo el software de los proveedores. Durante nuestra investigación, encontramos un repositorio de código fuente expuesto que albergaba una implementación propietaria de DDS, lo que habría permitido a un atacante infectar el código fuente (T0873T0839).

Figura 2. DDS es una biblioteca de software estandarizada que se utiliza para sistemas controlados por software, directamente o a través de ROS

DDS es la base de otros estándares industriales, como el Bus de Mensajes de Campo Abierto (OpenFMB), utilizado para aplicaciones de redes inteligentes, AUTOSAR Adaptativo, el Programa de interoperabilidad Plug-and-Play para dispositivos médicos (MD PnP), la Arquitectura Genérica de Vehículos (GVA) y la GVA de la OTAN (NGVA). El Sistema Operativo para Robots 2 (ROS 2), que es el sistema operativo (OS) estándar de facto para robots y automatización, tiene DDS como middleware por defecto. Cabe destacar que la reciente iniciativa Space ROS de la NASA llevará ROS 2 al espacio. DDS también se utiliza para aplicaciones de virtualización de sistemas y computación en la nube, principalmente para intercambiar datos entre máquinas y centros de datos.

Una vulnerabilidad en las especificaciones del estándar

Como cualquier otro producto de ingeniería, DDS también tiene vulnerabilidades en su base de código y ecosistema (por ejemplo, herramientas de desarrollo, back-ends de la nube, imágenes Docker y bibliotecas de integración). Un hallazgo peculiar es una vulnerabilidad de amplificación (CVE-2021-38487, CVE-2021-38429) que permite a un actor malicioso desencadenar ataques de inundación de la red mediante la suplantación de un solo paquete de descubrimiento de DDS. Cuando se compromete, esto conduce a un mal funcionamiento del servicio y a la ruptura de las propiedades en tiempo real de la comunicación. Curiosamente, esta vulnerabilidad de amplificación es evidente con solo leer las especificaciones del estándar DDS, que no exigen comprobaciones adecuadas que eviten los casos límite que un atacante podría explotar. Hemos comprobado que el mismo exploit funciona sin modificaciones contra múltiples productos, lo que confirma que no se trata de un problema específico de la implementación.

Figura 3. Mediante la suplantación del localizador de participantes, cualquier participante puede hacerse pasar por otro, y el receptor se ve obligado (siguiendo el requisito de la especificación) a responder hasta recibir un acuse de recibo válido

Entorno de desarrollo DDS expuesto a Internet

Durante la supervisión de los sistemas de integración continua/despliegue continuo (CI/CD) expuestos a través de Shodan, descubrimos que un desarrollador de DDS dejó su entorno CI/CD personalizado totalmente expuesto a Internet con credenciales predeterminadas. A pesar de nuestros numerosos intentos de contactar con este proveedor, incluso a través de brokers de vulnerabilidad y equipos de preparación para emergencias informáticas (CERT), no recibimos ninguna respuesta. Afortunadamente, el sistema expuesto se bloqueó adecuadamente después de unos meses. Si se hubiera dejado abierto, podría haber permitido a un actor malicioso borrar, robar o troyanizar su propiedad intelectual más valiosa: el código fuente.

Figura 4. Un sistema de integración continua expuesto utilizado por un desarrollador de DDS, con credenciales de acceso por defecto en texto plano

¿Cuáles son las posibles consecuencias?

Un atacante armado con exploits que funcionen para estas vulnerabilidades podría interrumpir el funcionamiento normal de un dispositivo objetivo a través de la red DoS, moverse lateralmente o (en algunos casos) controlar una máquina. Dado que DDS se utiliza en aplicaciones de misión crítica, incluso una capacidad DoS simple puede utilizarse como palanca para poderosos ataques basados en extorsión, como observamos a lo largo de 2020 y 2021. Encontramos 643 IPs únicas que exponen endpoints DDS. Teniendo en cuenta que se supone que el DDS solo se despliega en una red local, 643 es un número significativo. Además, algunos de estos endpoints filtran información sobre la estructura de la red interna, como las IP privadas.

Por las características y los datos de esos endpoints, pudimos plantear la hipótesis de la versión del producto DDS que se ejecuta detrás. Podemos decir que todos ellos, excepto cuatro, son vulnerables a al menos una de nuestras CVE (compare la tabla de CVE con la columna de versiones).

La vulnerabilidad de reflexión en la red afecta tanto a las especificaciones como a la mayoría de las implementaciones. Eclipse CycloneDDS y GurumDDS no están afectados, lo que significa que tienen medidas de mitigación incorporadas (aunque siguen siendo susceptibles a los ataques de reflexión). Además, la mayoría de las implementaciones están afectadas por al menos una vulnerabilidad. La posibilidad de explotación (T1210) puede variar dependiendo del entorno de ejecución. En particular, protecciones como stack canaries o la aleatorización de la disposición del espacio de direcciones (ASLR), que normalmente están disponibles en los terminales tradicionales, no siempre están implementados en los sistemas embebidos.

Tabla 1. Resumen de las vulnerabilidades encontradas y con los CVEs asignados a través de las principales implementaciones de DDS y la especificación estándar.

Enumeramos solo algunos de los resultados de compromiso y ataques en caso de que estas vulnerabilidades DDS se dejen sin asegurar, junto con la correspondiente taxonomía MITRE ATT&CK ICS, como la pérdida de control (T0827), la pérdida de seguridad (T0880) y la denegación de servicio (T0814) a través de la fuerza bruta (T0806). Además, algunas implementaciones están afectadas por vulnerabilidades de stack o heap-based overflow, que pueden ser explotadas para facilitar el acceso inicial (TA0108) a través de la explotación de servicios remotos (T0866, T0886). En cualquier caso, dado que tres distribuciones populares de DDS son de código abierto, el compromiso de la cadena de suministro (T0862) también es un escenario viable. Al escribir un escáner de red automatizado, demostramos que es posible para un atacante realizar un descubrimiento automatizado (TA0102, T0856) abusando del protocolo de descubrimiento incorporado, o incluso abusar del propio protocolo para crear un canal de mando y control eficiente (T0869).

Solución: más allá de los parches

A corto plazo, recomendamos medidas de mitigación como el escaneo periódico de vulnerabilidades (M1016) para detectar la presencia de servicios sin parchear, y el despliegue de prevención de intrusiones en la red (M1031), la segmentación de la red (M1030) y el filtrado del tráfico de red (M1037) para detectar mensajes DDS falsos y evitar la explotación de la vulnerabilidad de reflexión. También recomendamos medidas de prevención de la ejecución (M1038) para reducir la explotación de los errores de memoria, y la auditoría periódica (M1047).

Cuando se trata de la seguridad del software crítico en la cadena de suministro, como DDS, la necesidad más apremiante es hacer que la base de código sea más susceptible a la integración de herramientas automatizadas de pruebas de seguridad. Tomando fuzz-testing como ejemplo representativo. Abogamos por que todas las bibliotecas de software críticas, como DDS, se desarrollen con una fuerte orientación a las pruebas de seguridad, además de las pruebas unitarias tradicionales. La situación ha mejorado enormemente gracias a iniciativas como OSS-Fuzz, pero todavía existe una brecha significativa entre los ingenieros de seguridad y los ingenieros de software. Esto da lugar a tediosas revisiones manuales del código, a modificaciones no deseadas en el código para integrar las comprobaciones de seguridad, etc., lo que retrasa la adopción a gran escala de las herramientas de seguridad disponibles.

La respuesta positiva y atractiva a nuestra divulgación por parte de ADLINK, que llegó a ayudar a los investigadores de Trend Micro a crear buenos objetivos fuzz contra su propia base de código, debería servir de ejemplo a toda la industria de la ingeniería de software. Esperemos que esto sirva de ejemplo a toda la industria del software.

Descargas