Hace más de dos décadas que existe una empresa de software llamada Treck Inc., de la cual posiblemente nunca has oído hablar pero posiblemente alguno de sus productos estén implementados en los dispositivos que utiliza tu empresa u organización. Esta compañía, centrada sobre todo en el desarrollo de librerías para la implementación a bajo nivel de la pila de protocolos TCP/IP, basa todo éxito en el desarrollo de frameworks para todo tipo de dispositivos IoT.
El éxito de su producto es tal que grandes fabricantes de de “aparatos” como, por ejemplo, impresoras, todo tipo de dispositivos industriales, SmartHome, dispositivos para entornos médicos, etcétera, llevan años utilizándolo. Y no es para menos, ya que sus librerías facilitan muchísimo el trabajo de del desarrollador a la hora de conectar cualquier dispositivo a la red de redes.
Es casi imposible rastrear el número real de fabricantes de hardware IoT que han comprado y/o utilizado las librerías de pila TCP/IP de Treck. Ya sea por la gran cantidad de clientes o simplemente porque algunas empresas directamente fueron compradas por otras, su número es difícil de cuantificar. Lo que está claro es que son compañías entre las que podemos encontrar a HP, Intel, Schneider Electric, Caterpillar, etcétera (sólo por nombrar algunas de las más conocidas) que han vendido sus productos con dichas librerías implementadas, a otras que incluso tienen Infraestructuras Críticas (como Transporte, Energía, Hospitales, etcétera) como clientes.
 |
| Figura 1: Ripple20: Serios fallos de seguridad en el mundo de los Sistemas Industriales e Infraestructuras Críticas |
El éxito de su producto es tal que grandes fabricantes de de “aparatos” como, por ejemplo, impresoras, todo tipo de dispositivos industriales, SmartHome, dispositivos para entornos médicos, etcétera, llevan años utilizándolo. Y no es para menos, ya que sus librerías facilitan muchísimo el trabajo de del desarrollador a la hora de conectar cualquier dispositivo a la red de redes.
 |
| Figura 2: Libro Infraestructuras Críticas y Sistemas Industriales: Auditoría de Seguridad y Fortificación de Juan Francisco Bolivar |
Es casi imposible rastrear el número real de fabricantes de hardware IoT que han comprado y/o utilizado las librerías de pila TCP/IP de Treck. Ya sea por la gran cantidad de clientes o simplemente porque algunas empresas directamente fueron compradas por otras, su número es difícil de cuantificar. Lo que está claro es que son compañías entre las que podemos encontrar a HP, Intel, Schneider Electric, Caterpillar, etcétera (sólo por nombrar algunas de las más conocidas) que han vendido sus productos con dichas librerías implementadas, a otras que incluso tienen Infraestructuras Críticas (como Transporte, Energía, Hospitales, etcétera) como clientes.
Como cualquier dispositivo IoT, tenga la función que tenga, necesitará conexión a la red de algún tipo, esta librería se ha hecho tremendamente popular. Por cierto, si quieres saber y entender el mundo de la seguridad IoT de las Infraestructuras Críticas, no puedes perderte el libro de uno de los buenos expertos en la seguridad de ellas, Juan Francisco Bolivar, llamado “Infraestructuras críticas y sistemas industriales: Auditorías de seguridad y fortificación”, de la editorial 0xWord.
OWASP no falla …
Antes de entrar en materia sobre qué ha ocurrido con esta empresa o más bien con el producto que desarrolla, vamos a echar un vistazo al OWASP TOP 10 de aplicaciones y de APIs. Todos conocemos estos listados de OWASP los cuales nos permiten tener una visión de los mayores problemas de seguridad web orientados a desarrolladores.
En los puestos 6 y 7 respectivamente, podemos encontrar el término “Security Misconfiguration” el cual describe los problemas relacionados con la configuración insuficiente de seguridad (o la no actualización de los mismos entre otros) y en el OWASP Top 10 de aplicaciones, en el puesto número 9 podemos encontrar otra vulnerabilidad que definen como “Using componentes with known vulnerabilities” (utilizar componentes con vulnerabilidades conocidas).
Todas tienen algo en común, y es el que creador de la aplicación o dispositivo, por mucho esfuerzo que haya puesto en programar código seguro para su programa, si utiliza una librería, framework, sistema operativo, etcétera, que tenga vulnerabilidades (presentes o futuras por no actualizar el código), todo el esfuerzo por securizar nuestro producto se irá al traste.
¿Qué es Ripple20?
Pues esto es justo lo que ha ocurrido con Ripple20 (ripple significa “onda” y debido a que puede afectar a toda la “supply chain” o cadena de suministro, le han dado este nombre) en el que el mundo de la Ciberseguridad y del IoT están aún asimilando cómo enfrentarse a las 19 vulnerabilidades que pueden llegar a afectar a millones de dispositivos repartidos todo el mundo. La empresa JSOF ha descubierto estos zero-days en la librería de la pila TPC/IP de Treck, incluyendo algunos con los temidos ataques tipo RCE.
Figura 5: ElevenPaths Radio "Actualidad": Asegurando la Cadena de Suministros
Todavía no se saben todos los detalles técnicos en profundidad ya que lo presentarán en la próxima edición de BlackHat USA (donde por cierto también estaremos nosotros en la sección Arsenal, presentando ATTPWN). De las vulnerabilidades encontradas, 4 son críticas que incluyen RCE (con una puntuación CVSS mayor o igual a 9), otras 4 tienen una puntuación CVSS mayor o igual a 7, finalmente 11 con menor impacto donde se pueden encontrar security leaks (fugas de información) y DoS, entre otros.
Un ejemplo, el CVE-2020-11896
Este CVE-2020-11896 sirve para etiquetar una vulnerabilidad crítica en la librería Treck que permite RCE realizado por un atacante que pueda enviar paquetes UDP a un puerto abierto del dispositivo objetivo (por cierto, con una puntuación de CVSS de 10, la máxima). Para que este ataque tenga efecto, es necesario que el dispositivo soporte fragmentación IP con tunneling.
¿Qué es Ripple20?
Pues esto es justo lo que ha ocurrido con Ripple20 (ripple significa “onda” y debido a que puede afectar a toda la “supply chain” o cadena de suministro, le han dado este nombre) en el que el mundo de la Ciberseguridad y del IoT están aún asimilando cómo enfrentarse a las 19 vulnerabilidades que pueden llegar a afectar a millones de dispositivos repartidos todo el mundo. La empresa JSOF ha descubierto estos zero-days en la librería de la pila TPC/IP de Treck, incluyendo algunos con los temidos ataques tipo RCE.
Figura 5: ElevenPaths Radio "Actualidad": Asegurando la Cadena de Suministros
Todavía no se saben todos los detalles técnicos en profundidad ya que lo presentarán en la próxima edición de BlackHat USA (donde por cierto también estaremos nosotros en la sección Arsenal, presentando ATTPWN). De las vulnerabilidades encontradas, 4 son críticas que incluyen RCE (con una puntuación CVSS mayor o igual a 9), otras 4 tienen una puntuación CVSS mayor o igual a 7, finalmente 11 con menor impacto donde se pueden encontrar security leaks (fugas de información) y DoS, entre otros.
Un ejemplo, el CVE-2020-11896
Este CVE-2020-11896 sirve para etiquetar una vulnerabilidad crítica en la librería Treck que permite RCE realizado por un atacante que pueda enviar paquetes UDP a un puerto abierto del dispositivo objetivo (por cierto, con una puntuación de CVSS de 10, la máxima). Para que este ataque tenga efecto, es necesario que el dispositivo soporte fragmentación IP con tunneling.
 |
| Figura 6: Libro de "Ataques en redes de datos IPv4 & iPv6" 3ª Ed en 0xWord, de Chema Alonso, Pablo González y Juan Luis Rambla. |
A pesar de todo, si este dispositivo no cumpliera estos requisitos, sería posible realizar en su lugar un ataque DoS. En general, lo que ocurre es que la pila TCP/IP de la librería de Treck no gestiona correctamente los fragmentos IPv4 sobre un túnel IP-in-IP. Esto permitiría que un atacante (sin autenticar) pudiera obtener acceso a información localizada en el heap de la memoria.
En el paper publicado por JSOF se ofrece en detalle la raíz teórica de esta vulnerabilidad y su funcionamiento. Para explotarla han utilizado un dispositivo Digi Connect ME 9210 para implementar la PoC del RCE. Este dispositivo tiene la forma de un conector RJ-45 pero es realmente un sistema ultra compacto que incluye CPU, un sistema operativo (Linux) y las librerías Treck de la pila TCP/IP.
El resto de las vulnerabilidades más importantes son:
 |
| Figura 7: Digi Connect ME 9210 utilizado en las pruebas |
En el paper publicado por JSOF se ofrece en detalle la raíz teórica de esta vulnerabilidad y su funcionamiento. Para explotarla han utilizado un dispositivo Digi Connect ME 9210 para implementar la PoC del RCE. Este dispositivo tiene la forma de un conector RJ-45 pero es realmente un sistema ultra compacto que incluye CPU, un sistema operativo (Linux) y las librerías Treck de la pila TCP/IP.
 |
| Figura 8: Papper de Ripple20 |
El resto de las vulnerabilidades más importantes son:
• CVE-2020-11897 - CVSSv3 score: 10 - Similar a la vulnerabilidad 11896 solo que esta vez utilizando la misma técnica con paquetes IPv6.
• CVE-2020-11898 - CVSSv3 score: 9.8 - Manejo impropio de la longitud de los parámetros de inconsistencia en IPv4/ICMPv4 podría exponer información sensible.
• CVE-2020-11899 - CVSSv3 score: 9.8 - Validación impropia en IPv6 cuando se está gestionando un paquete enviado por un atacante en la red no autorizado, la cual puede exponer información sensible.
¿Cómo se solucionan?
JSOF ha estado trabajando con varias organizaciones como CERT/CC, CISA y la FDA entre otras, para ver cómo solucionar este problema realizando un parcheo o actualización de software. La misma empresa Treck ha creado varios parches de seguridad para solucionar este problema, pero aquí nos encontramos con otra problemática, y es el acceso a dichos dispositivos IoT.
Algunos dispositivos IoT no son fáciles de actualizar, ya sea por su peculiaridad configuración de hardware específico, relevancia en la infraestructura (no se pueden apagar o reiniciar tan fácilmente) o simplemente porque llevan tanto tiempo si actualizarse que la nueva actualización puede dejar inoperativo al aparato en sí (incompatibilidad). En estos casos sólo resta minimizar la amenaza de alguna forma externa.
Para mitigar este problema de seguridad el primer paso debe de ser buscar y catalogar aquellos dispositivos que estén afectados por alguna de estas vulnerabilidades. El siguiente paso será actualizar siempre que sea posible el dispositivo con los parches publicados por Treck. En caso de no ser posible, la solución será segmentar, aislar y sobre todo controlar todo el acceso de red desde y hacia el dispositivo vulnerable, para detectar posibles ataques.
 |
| Figura 9: Sala de control "vintage" de una Central Nuclear sovietica |
Para mitigar este problema de seguridad el primer paso debe de ser buscar y catalogar aquellos dispositivos que estén afectados por alguna de estas vulnerabilidades. El siguiente paso será actualizar siempre que sea posible el dispositivo con los parches publicados por Treck. En caso de no ser posible, la solución será segmentar, aislar y sobre todo controlar todo el acceso de red desde y hacia el dispositivo vulnerable, para detectar posibles ataques.
Pero una cosa es segura, si un atacante es capaz de acceder a este dispositivo, ya sea desde la red local o desde Internet, el primer problema lo tienes en la seguridad de tu arquitectura permitiendo que este usuario pueda alcanzar dicho aparato.
¿Es tan preocupante?
Las vulnerabilidades Ripple20 son importantes, muy importantes, pero hay también que rebajar un poco la alarma y mirar con perspectiva. No es la primera vez que vemos un titular de este tipo que muestra un escenario apocalíptico. Ya nos pasó por ejemplo con Meltdown y Spectre y aquí seguimos todos trabajando sin problema (aunque es cierto que el problema de estas vulnerabilidades era su muy difícil implementación, en el caso de Ripple20 parece que es más sencilla de implementar).
Por lo tanto, precaución, seguir los pasos recomendados por el fabricante para parchear los dispositivos (siempre que se pueda) y calma, mucha calma. Para poder explotar alguna de estas vulnerabilidades el atacante necesita una conexión directa con el dispositivo afectado o con una ruta creada desde Internet hacia otra interna y de aquí al dispositivo.
Por lo tanto, otro de los pasos a ejecutar tiene que ser detectar cuáles de estos dispositivos tiene conexión a Internet, y una forma sencilla si usamos SHODAN buscando la cadena “Treck” (aunque afinando más por modelos, características y usando la API de Shodan, podemos concretarlo más). Pero “lo normal” es que un dispositivo de una Infraestructura Crítica no tenga acceso directo a Internet, por lo tanto, habría que potenciar los controles de acceso local a red donde se encuentre.
¿Es tan preocupante?
Las vulnerabilidades Ripple20 son importantes, muy importantes, pero hay también que rebajar un poco la alarma y mirar con perspectiva. No es la primera vez que vemos un titular de este tipo que muestra un escenario apocalíptico. Ya nos pasó por ejemplo con Meltdown y Spectre y aquí seguimos todos trabajando sin problema (aunque es cierto que el problema de estas vulnerabilidades era su muy difícil implementación, en el caso de Ripple20 parece que es más sencilla de implementar).
Por lo tanto, precaución, seguir los pasos recomendados por el fabricante para parchear los dispositivos (siempre que se pueda) y calma, mucha calma. Para poder explotar alguna de estas vulnerabilidades el atacante necesita una conexión directa con el dispositivo afectado o con una ruta creada desde Internet hacia otra interna y de aquí al dispositivo.
Por lo tanto, otro de los pasos a ejecutar tiene que ser detectar cuáles de estos dispositivos tiene conexión a Internet, y una forma sencilla si usamos SHODAN buscando la cadena “Treck” (aunque afinando más por modelos, características y usando la API de Shodan, podemos concretarlo más). Pero “lo normal” es que un dispositivo de una Infraestructura Crítica no tenga acceso directo a Internet, por lo tanto, habría que potenciar los controles de acceso local a red donde se encuentre.
La buena noticia es que JSOF reportó directamente al fabricante estas vulnerabilidades, dos ellas de forma anónima y esto ha permitido la rápida creación de los diferentes parches de seguridad. Además, tampoco han publicado ninguna PoC (al menos el código) donde se implemente este tipo de ataque, tendremos que esperar a la BlackHat para verlo, lo bueno es que la mayoría de los dispositivos (o eso esperamos) ya estarán parcheados.
Resumiendo, como en la mayoría de los problemas de seguridad, el primer paso es tener toda nuestra infraestructura segura en general. Luego, para estas vulnerabilidades, la solución pasa por actualizar las librerías, pero justo en este caso, no es posible aplicarlos en todos los dispositivos por lo que provoca la activación de una capa adicional de seguridad centrada esta vez en la monitorización y los controles de red donde se encuentre el aparato.
Finalmente, y a modo de moraleja, que una implementación funcione bien durante años no quiere decir que esté exenta de problemas de seguridad, por lo que es necesario auditarla y actualizarla de forma periódica. Pero también es nuestra misión tener controladas esas librerías y comprobar que se actualicen periódicamente, aunque esto es un poco más complicado en el caso del IoT. Pero vamos, si tienes un dispositivo IoT SteamPunk ;) que no has tocado durante veinte años aunque funcione bien … seguro que alguna “pequeña” actualización habrá necesitado en todo este tiempo ¿verdad? ;)
Finalmente, y a modo de moraleja, que una implementación funcione bien durante años no quiere decir que esté exenta de problemas de seguridad, por lo que es necesario auditarla y actualizarla de forma periódica. Pero también es nuestra misión tener controladas esas librerías y comprobar que se actualicen periódicamente, aunque esto es un poco más complicado en el caso del IoT. Pero vamos, si tienes un dispositivo IoT SteamPunk ;) que no has tocado durante veinte años aunque funcione bien … seguro que alguna “pequeña” actualización habrá necesitado en todo este tiempo ¿verdad? ;)
Happy Hacking Hackers!!!
Autores:
Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.
 |
| Contactar con Fran Ramírez en MyPublicInbox |
No hay comentarios:
Publicar un comentario