Esta es la pregunta que más me han hecho desde que comenzó el apagón eléctrico de la historia de España. La respuesta no la sabremos hasta que los equipos que están investigando el incidente hayan podido analizar "Root Cause" del incidente, y para ello van a necesitar tiempo. Y lo más importante es recuperar la energía lo antes posible, que hay muchos sitios críticos donde la existencia de la energía puede salvar vidas.
Figura 1: ¿Podría ser el Apagón Eléctrico de España un ciberataque?
¿Podría haber sido un ciberataque? Pues no lo sabemos aún, y no seré yo el que vaya a especular sobre esto, pero es una de las posibilidades que podrían ser, por supuesto. Pero también podrían ser otras las causas que han producido esto, así que lo mejor es no especular y esperar a ver lo que los forenses que estén en el CSIRT ahora nos digan cuando tengan los datos.
Al final, en el pasado hemos visto caídas de sistemas de Internet, de energía, de llamadas, de gas, y de casi cualquier suministro crítico por causas que puedan interrumpir el sistema que distribuyen la luz, el gas, las redes de telefonía o datos. Y ahora no sabemos más que puede ser cualquier de ellos.
Las causas posibles, os las podéis imaginar:
Accidente: Un incendio, una inundación, una nevada, un volcán. De todo esto hemos vivido en los años recientes con Filomena, la Dana, el Volcán de La Palma, o los Incendios que nos han asolado durante mucho años parte de nuestro territorio. Estos suelen producir cortes locales, o puntuales, porque destrozan partes del sistema, pero no han solido ser nacionales porque no han tocado el corazón del sistema, y cuando se diseña un sistema crítico es necesario redundar las partes core que pueden discontinuar el sistema.
Pero puede ser de gran intensidad o tocar un punto clave. Durante la Dana, hubo que hacer un trabajo especial para reforzar los centros de llamadas del 112 que estaban saturados, y que fue una de las prioridades durante la crisis, ya que no podían atender tantas llamadas. Que se pudieran atender todas las llamadas de emergencia lo antes posible, y para eso hubo que re-enrutar comunicaciones a centros de respaldo en otras ubicaciones.
Pero los ha habido mucho más cercanos en el tiempo .En el año 2023 se alertó del ataque al sector eléctrico de Dinamarca, donde más de dos docenas de centrales fueron afectadas en tres oleadas, lo que deja claro que fue un ataque coordinado y organizado contra una infraestructura crítica de un país.
Ahora mismo no sabemos nada. Serán los expertos que estén analizando el caso los que tengan que dar las informaciones, así que todo son especulaciones, por lo que hay que evitar caer en asegurar nada, porque solo los que tengan los datos tienen la información. Lo que sí que está claro es que algo ha pasado en el sistema y hay que saber qué es para que no vuelva a pasar.
Que llevamos tiempo deseando que la normalidad, la antigua, vuelva a nuestras vidas no es algo nuevo. La deseamos y estamos ansiosos por que esté aquí con nosotros. El pasado viernes 4 de febrero Luis Eduardo Álvarez y yo presentamos on-the-fly en la H-c0n con un taller sobre el uso de la herramienta. Una herramienta que se desarrolló en IdeasLocas y que es OpenSource para que cualquiera pueda ampliarla, mejorarla, estudiarla y aprender con ella sobre evaluaciones en la seguridad de la red.
Figura 1: H-CON: Hackeando con On-the-fly entre "Humans"
La H-c0n nos brindó la posibilidad de volver a amigos y conocidos que no veíamos desde hace casi dos años. Nos permitió conocer nuevos trabajos de compañeros y volver a juntarnos, sin pantalla de por medio, y volver a sentir lo que es una CON en estado puro. El workshop que presentamos era el de on-the-fly, la herramienta que IdeasLocas llevó a BlackHat Europe 2021 para extender la mochila del pentester en proyectos de Ethical Hacking.
El trabajo dispone de un paper en el que se puede desglosar toda la herramienta desde el punto de vista de arquitectura, lo que aporta como herramienta OpenSource y algunos casos de uso con los módulos que trabaja la herramienta. Desde el punto de vista de un pentesting a entornos TI tiene sus puntos fuertes, pero también está pensada para poder trabajar en entornos IoT e ICS, aunque aún le falta crecer en este aspecto.
En el workshop trabajamos para mostrar casos de uso en diferentes ámbitos de uso de on-the-fly: TI, IoT o ICS. Aunque con dos horas no era suficiente para poder trastear con la herramienta todo lo que nos hubiera gustado. Además, con un auditorio con bastante gente no se podía interactuar mucho con los diferentes ejemplos.
Instalación on-the-fly
Como comenté, estamos trabajando en facilitar la instalación de on-the-fly a través de un script que automatice la instalación de dependencias, configuración de Python y otras necesidades identificadas en la herramienta para que se pueda instalar de manera sencilla en Ubuntu y Kali Linux (al menos).
Lo primero fue explicar cómo instalar la herramienta y aquí os dejo la receta del paso a paso para que la instalación funcione (Kali Linux testeado):
- git clone https://github.com/Telefonica/on-the-fly.git
- apt install libssl-dev libncurses5-dev build-essential libffi-dev libnetfilter-queue-dev
- Descargamos Python 3.7 (o 3.X dónde X es <=7).
Es recomendable hacer esto, aunque todo pueda funcionar con un Python superior (antes no funcionaba de forma estable).
- https://github.com/deadsnakes/python3.7
o ./configure
o make
o make test
o sudo make install
- NetfilterQueue
o https://github.com/oremanj/python-netfilterqueue
o From pipy
Python3.7 –m pip install NetfilterQueue
- Python3.7 –m pip install –r requirements.txt
Ya podemos hacer: sudo python3.7 on-the-fly.py
Después de la instalación se mostró el uso básico de la herramienta, especificando el pequeño conjunto de comandos que tiene la herramienta, pero que permiten encadenar una serie de pruebas de ataques a redes para evaluar la seguridad del entorno. Además, se mostraron las familias de los módulos que on-the-fly tiene, todo esto se puede ver en su paper.
Figura 5: Módulos de on-the-fly
Uno de los puntos fuertes de la herramienta es la gestión de hilos y cómo los módulos se pueden ir “apilando”, es decir, un pentester puede empezar lanzando un ataque en red IPv4 como ARP Spoofing para, posteriormente, empezar a sniffar todo el tráfico que pasa por la máquina y añadir, más adelante, otro módulo para hacer una manipulación de paquetes sobre MySQL.
La idea de la herramienta es apilar una serie de módulos para construir pruebas de evaluación grandes, a partir de pequeños módulos que van haciendo acciones concretas. Aquí está la fuerza de la herramienta. Para poder gestionar el “apile” de los módulos se dispone del comando ‘jobs’, el cual permite gestionar los módulos para poder finalizarlos cuando ya no se requieran.
Figura 7: Jobs en on-the-fly
Hablamos sobre la arquitectura y lo fácil que es que cualquier usuario pueda añadir a la herramienta un módulo para implementar una funcionalidad necesaria. Lo interesante es que viendo su arquitectura, la herramienta es muy sencilla de escalar.
Figura 8: Arquitectura de módulos on-the-fly
La parte interesante del workshop vino cuando comentamos los diferentes casos de uso a modo de ejemplo, para que los asistentes pudieran contemplar las diferentes posibilidades de la herramienta y en sus diferentes ámbitos.
Casos de uso de On-the-fly
El primer ejemplo fue la manipulación de paquetes a través del uso de dos módulos:
- ARP Spoofing entre un cliente de base de datos y un servidor de base de datos
- MySQL Manipulation para que el tráfico que pasa por on-the-fly pueda ser modificado por la sentencia que interese al pentester.
Figura 10: On-they-fly: PoC of Network Packet Manipulation to inject users in MySQL
Otro de los casos de ejemplo que se tocó en el seminario es el de usar on-the-fly como un pivote para reenviar tráfico a través de TCP Port-Forwarding o convertir a on-the-fly en un proxy SOCKS4.
Figura 11: Convirtiendo on-the-fly en un Proxy Socks4
En el siguiente vídeo tienes un ejemplo de cómo funciona este proceso completo utilizando on-the-fly.
Figura 12: On the fly: PoC de enrutado ProxySocks
Posteriormente, empezamos con la parte de SSDP y Modbus. El protocolo SSDP o Simple Service Discovery Protocol, es un protocolo muy utilizado para el descubrimiento de servicios en redes de área local, por lo que la parte más IoT de casa lo utiliza y mucho. En esta demo, Luis, mostró un ejemplo de cómo on-the-fly puede suplantar cualquier tipo de servicio haciéndose pasar por cualquier dispositivo que se puede encontrar en un hogar o en una oficina. Es perfecto para un ejercicio de Red Team.
Figura 13: On-the-fly: PoC SSDP-Fake
Además, por lo que pudimos ver, la herramienta ha servido de inspiración para algunos compañeros, lo cual nos alegra mucho, ya que no todo es el uso que se pueda dar a on-the-fly, si no que ver cómo otros compañeros te cuentan que les interesa la herramienta porque ellos están haciendo algo parecido para un entorno similar y que les gustaría echar un ojo y ver cómo pueden enfocar su herramienta es perfecto. De eso se trata cuando una herramienta es para la comunidad y para la mejora en ciberseguridad.
En el equipo de Ideas Locas tenemos algunas sorpresas para estas semanas. Una de ellas es la publicación de una nueva herramienta denominada on-the-fly, la cual ya está disponible en su Github. Pronto anunciaremos algo más sobre un par de herramientas y algunos sitios donde se podrán ver y donde realmente se darán a conocer.
Figura 1: On-the-fly. Una nueva herramienta para auditar redes TI, IoT & ICS
Hoy queremos hablar del trabajo que ha sido sacar esta herramienta. La idea es proporciona una herramienta modular que permita al usuario ir configurando módulos que permitan realizar ataques de redes tanto en el mundo TI, IoT o ICS.
Algo que se debe tener claro es que la utilización de diferentes tecnologías entre estos dispositivos que nos rodean hace que la seguridad sea heterogénea. Cuando se afronta un Ethical Hacking en cualquier entorno, uno de los factores importantes es la red. La red conecta el mundo del Internet de las cosas, el mundo de los sistemas de control industrial y el mundo de las tecnologías de la información.
La irrupción del paradigma IoT, la conectividad del mundo OT / ICS y el crecimiento exponencial del mundo TI hacen que el pentester requiera conocer todos estos espacios para poder trabajar acorde a lo necesario. Una herramienta que centraliza diferentes técnicas de evaluación de vulnerabilidades o debilidades en una red es un concepto interesante. Dándole el concepto de modular se consigue lograr varias cosas:
1. Que cualquier usuario de la comunidad (hay que recordar que la herramienta es Open Source) puede colaborar y ampliar las posibilidades de ésta, gracias a la implementación de un módulo.
2. Disponer de diferentes técnicas modernas para llevar a cabo este tipo de evaluación y que fácilmente sea ampliable.
3. Lectura y entendimiento sencilla para poder implementar módulos y compartirlos con la comunidad.
“La herramienta ‘on-the-fly’ es un framework que proporciona funcionalidades para llevar a cabo tareas de pentesting en redes de datos en entornos IoT, ICS y TI. La herramienta permite ejecutar diferentes acciones de forma simultánea y de forma modular, simplificando el encadenamiento de acciones y otorgando la posibilidad de realizar diferentes ataques simultáneos.”
‘on-the-fly’ tiene una arquitectura modular y dispone de más de 40 módulos con funcionalidades para el pentesting en entornos IoT, ICS & TI. Esto es algo interesante, ya que cualquier usuario podría ampliar la base de conocimiento de la herramienta. La arquitectura de la herramienta es la siguiente:
Figura 5: Arquitectura de "on the fly"
A continuación se enumeran los tipos de módulos principales:
Figura 6: Módulos de 'on-the-fly'
- Discovery: En este tipo de módulos se pueden encontrar funcionalidades para descubrir diferentes tipos de servicios y máquinas. Se utilizan diferentes protocolos: Modbus para descubrimiento ICS, TCP para descubrimiento de servicios y máquinas, MDNS y SSDP, etcétera.
- Manipulation: Este tipo de módulos permiten manipular ‘al vuelo’ (on-the-fly) el tráfico que pasa a través de la máquina. Son módulos especializados en cambiar valores que pueden observarse y manipularse. Permiten obtener ventaja, por ejemplo, manipulando las consultas a una base de datos y consiguiendo acceso.
- Server:Este tipo de módulos proporcionan al pentester la posibilidad de levanar un servicio o servidor y disponer de un servicio fake sobre SSDP, MQTT o DNS, por ejemplo.
- Spoof:Este tipo de módulo permite llevar a cabo ataques de spoofing entre diferentes máquinas. Por ejemplo, se puede hacer los clásicos ARP Spoofing, DNS Spoofing o NTP Spoofing, pero también ataques de spoofing en COAP y MQTT (IoT) y en Modbus (ICS).
- Pivot:Este tipo de módulo permite utilizar ‘on-the-fly’ como herramienta para pivotar en un pentest. Permite utilizar SOCKS4 y un port-forwarding sobre TCP para redirigir el tráfico. Una funcionalidad necesaria para el pentester.
- Sniffer:Este tipo de módulo permite llevar a cabo un ‘sniffing’ de paquetes. Hay módulos que vienen preparados para ‘sniffar’ tráfico concreto, y otros módulos permiten configurar qué se quiere sniffar, cómo y dónde almacenarlo.
- Examples: Este tipo de módulo muestra ejemplos de implementación de un módulo. Esto sirve para que un usuario pueda crear de manera sencilla su propio módulo con la funcionalidad que quiera.
Los comandos disponibles en la herramienta ‘on-the-fly’ son los siguientes que puedes ver en la siguiente captura. De ellos, el comando jobs muestra los módulos que generan ‘hilos’ y están en ejecución. Desde este comando podemos ‘terminar’ un módulo cuando se quiera. ‘on-the-fly’ tiene un sistema de gestión de hilos interno para poder ejecutar en background cualquier trabajo y poder finalizarlo cuando el usuario lo requiera.
Figura 7: Comandos de 'on-the-fly'
Esta funcionalidad es la que permite poder cargar diferentes módulos para un ataque de red y poder juntar funcionalidades a través del uso de hilos. La gestión se lleva a cabo a través del comando Jobs.
Figura 8: Descripción de los comandos de 'on-the-fly'
Próximamente hablaremos de cómo hacer un módulo en on-the-fly o ver algunas de las funcionalidades interesantes que podemos encontrar. Es un proyecto en fabricación y que ha visto la luz recientemente. Todos los comentarios de mejora serán bienvenidos. Hay mucho más detalle en su repositorio de Github. Para finalizar, os dejamos con los siguientes vídeos donde se puede ver un ataque de SSDP fake, engañando a los dispositivos de la red tal como se puede ver en el artículo sobre EvilSSDP.
Figura 9: Ataque SSDP Fake
Por otro lado, os dejamos un ejemplo de spoofing en Modbus.
Figura 10: Demo de Spoofing de Modbus con 'on-the-fly'
Han sido meses de ir haciendo poco a poco la herramienta, pensar los módulos e ir añadiendo funcionalidades. Todavía queda camino, ya que el proyecto puede acabar con un gran número de implementaciones. Gracias a todos los miembros del equipo que han ido participando en el proyecto. Casi todos hemos pasado por la herramienta para aportar nuestro granito de arena. Pronto más noticias :)
Hace unos días os hablé en la primera parte de este artículo sobre de los protocolos utilizados en sistemas de de control industrial y e hicimos una breve explicación de en qué consisten y cómo funcionan algunos de los mas conocidos. En el día de hoy os hablaremos de cómo es posible integrarlos en una placa de Raspberry Pi (o similar) y cuáles son sus ventajas para hacer pruebas de seguridad y hacking. Vamos a hacer algo para hackers & makers.
Figura 1: Protocolos utilizados en Sistemas de Control Industrial: Desde sus inicios hasta la Raspberry Pi (Parte 2 de 2)
A la hora de montar una fábrica hay que tener en cuenta varios factores como la productividad de los equipos, su consumo o simplemente el espacio que ocupa cierta maquinaria o componentes, esto ha hecho que en muchos casos se opte por soluciones de hardware libre que pueden resultar mas baratas y muy configurables.
En cualquier sector de la industria es de vital importancia contar con elementos de protección que garanticen la seguridad tanto de los trabajadores como de la maquinaria y el software. Para proteger la comunicación entre los distintos dispositivos de la red es necesario que estas soluciones “low cost” permitan el cifrado de punto a punto. Esto no supone ningún problema, ya que la inmensa mayoría de estas nuevas placas (o microcontroladores) permiten hacer uso del cifrado AES a través de hardware que resulta ser bastante más rápido que el cifrado de software.
A pesar de que este tipo de sistemas habitualmente no están pensados parea utilizarse en un entorno industrial algunos están diseñados y preparados para soportar duras condiciones como las que se pueden dar en el interior de una fábrica (altas temperaturas, humedad, interferencias eléctricas, etcétera) además ofrecen la posibilidad de conectarles una gran variedad de sensores o dispositivos periféricos como pantallas o cámaras, tal y como vimos en el artículo de Raspberry Pi Zero donde veíamos 6 proyectos para makers con un montón de dispositivos periféricos.
En cuanto a limitaciones solo hay que decir que el hardware de la mayoría de estos dispositivos no permite la comunicación en algunos de los protocolos mas utilizados en la industria, sin embargo, existen algunos dispositivos diseñados específicamente para hacer esto posible, como por ejemplo las placas HAT diseñadas para la Raspberry Pi3 W.
Figura 4: Placa Serial Hat para protocolos ICS en Raspberry Pi
Dicho todo esto, a continuación, os voy a explicar cómo se puede realizar la integración de una placa SBC con un Sistema de Control Industrial o ICS. En este caso hemos elegido la Raspberry Pi para el experimento debido a que es posiblemente la placa más versátil con la que se puede trabajar en este caso, ya que se le puede instalar sistema operativo GNU/Linux y por lo tanto podremos trabajar con librerías y otros módulos que harán más fácil la implementación de protocolos de control. Otra de las razones por las que escoger esta placa es su capacidad para trabajar con la mayoría de protocolos basados en ethernet como el protocolo MODBUS o el ProfiNET de los cuales os hablamos en el anterior artículo.
Integración MODBUS Raspberry Pi
Como ya vimos anteriormente, durante los últimos años el protocolo MODBUS se ha convertido en un estándar para los procesos de comunicación industrial y es uno de los más utilizados en varios sectores de la industria. Lo mas habitual es utilizar Modbus RTU o Modbus ASCII como capa física con la posibilidad de convertir la Raspberry Pi en el cerebro de las aplicaciones. Para hacerlo posible es necesario utilizar un módulo o tarjeta HAT diseñada específicamente para esta función (en este caso una RS422 o RS485).
Figura 5: Conexiones módulo para RS422 a RS485 en tarjeta HAT
El montaje del módulo es sencillo, únicamente hay que soldar la placa a los pines de extensión de la Raspberry Pi, hecho esto solo tendremos que conectar el sistema Modbus utilizando los terminales del HAT y apretando los tornillos con un destornillador de punta plana. Este modelo de HAT está preparado para realizar múltiples funciones, por eso mismo no necesitaremos utilizar todas sus salidas. Solo tendremos que conectar las salidas A y B dejando libres las demás (Y, Z y SHIELD).
La placa cuenta también con tres juegos de interruptores DIP (con cuatro interruptores con dos posiciones) que hay que configurar de una forma determinada para que todo funcione correctamente. La posición de los sensores debe de ser la siguiente:
+Switch 1: 1 OFF, 2 ON, 3 ON, 4 OFF.
+Switch 2: 1 OFF, 2 OFF, 3 ON, 4 ON.
+Switch 3: 1 DEPENDE, 2 OFF, 3 OFF, 4 OFF.
Para configurar el tercer switch tendremos que tener en cuenta la posición de nuestra Raspberry Pi en la línea Modbus. Si se encuentra en uno de los extremos de la línea bus deberemos de ponerlo en la posición ON, en el caso contrario lo dejaremos en la posición OFF.
Figura 6: Configuración de switches
Con el hardware ya preparado el siguiente paso es configurar el software, la forma mas sencilla de hacerlo es liberar el puerto serie y habilitar el UART (Universal Asynchronous Receiver-Transmitter). Utilizando una imagen de Raspbian reciente y la herramienta raspi-config tendremos que acceder a las opciones de interfaz (5 Interfacing Options) y desde ellas al sub-apartado “P6 Serial”. Ahora deberemos asegurarnos de que los siguientes apartados tengan estos valores:
+ ”Would you like a login shell to be accessible over serial?: NO”
+ ”Would you like the serial port hardware to be eneabled?: YES”
Una vez hayamos terminado con los pasos anteriores solo habrá que salir de la aplicación raspi-config y reiniciar nuestra Raspberry Pi. Si todo esta bien configurado podremos acceder a la UART desde /dev/serial0.
Por último, tendremos que instalar la implementación de Modbus en Python, este es un proceso bastante sencillo, podréis descargarlo desde GitHub o utilizando el comando que os facilitamos a continuación en la consola de GNU/Linux.
wget https://pypi.python.org/packages/source/M/MinimalModbus/MinimalModbus-0.7.tar.gz TODO
Y una vez que tengas tu Raspberry Pi conectada a la línea de protocolos ICS ya puedes comenzar a buscar las maneras de atacar al sistema, de protegerlo, o de hacer tu trabajo de "hacker" desde este dispositivo que te has hecho como "maker".
Autor: Sergio Sancho Azcoitia, Security Researcher en el equipo de Ideas Locas de CDCO
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.
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.
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.
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.
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:
• 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.
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.
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? ;)
Tras Stuxnet en 2010 (Irán) e Industroyer en 2016 (Ucrania), no se habían visto ataques combinados y sofisticados focalizados principalmente para atacar y persistir en Infraestructuras Críticas y Sistemas de Control Industrial, diseñados específicamente para manipular e incluso destruir los sistemas infectados.
A fecha de hoy, un año después, auditando algunas infraestructuras SCI, todavía se puede constatar que de la familia de malware TRITON sigue alguna “versión” activa.
Figura 1: Cómo funciona TRITON (TRISIS): Un malware para Sistemas de Control Industrial del que protegerse
Los sistemas objetivo del malware TRITON, proporcionaron la capacidad de realizar una parada de emergencia totalmente incontrolada con los peligros reales que dicha parada implica, desarrollando una capacidad para causar daño físico en los sistemas y operaciones aleatorias de apagado o interrupción involuntaria de los dispositivos afectados.
La familia de malwareTRITON, consta de varios componentes ya identificados creados y dirigidos a los Sistemas de instrumentación de Seguridad (SIS) de Triconex. Dicha familia de malware, venía “disfrazada” de Trilogger (un producto de la marca Triconex), software de grabación, análisis de datos operativos de los sistemas Triconex. El malware es altamente destructivo, e implementado principalmente en Python.
Una vez el atacante obtiene acceso al dispositivo, es posible re-programar los controladores SIS, que a su vez provocan la alteración del sistema de control de seguridad y provoca un apagado del Sistema de Control Industrial. Esto le permite al atacante decidir si procede a realizar un apagado controlado, o un apagado disruptivo del sistema y todos sus componentes. Esto altera el funcionamiento normal del ICS, y provoca mensajes de error en cascada de MP (Memory Protection), al acceder a partes de la memoria del sistema de control de Triconex - en este caso provocando incluso destrozos físicos y en algunos casos poner en peligro los empleados de la factoría o provocar catástrofes ecológicas -.
Dichas modificaciones del SIS, pueden ser moldeables arbitrariamente por el atacante, provocando sistemáticamente apagados incontrolados, y en intervalos de tiempo predefinidos, haciendo que los objetivos infectados sean difíciles de detectar. Vamos a analizar ahora un poco su línea temporal y funcionamiento interno, haciendo un poco de análisis al código del malware.
Timeline:
Agosto 2017: Posible fecha de desarrollo y noticia de la primera infección.
Septiembre 2017: Segunda infección detectada en industria energética, contrastada con la prueba de malware subida a repositorios para detección de malware.
Octubre 2017: Auge de infecciones detectadas en varias factorías.
Diciembre 2017: primeros informes de respuestas a incidentes.
Módulo principal TRICONEX
Fichero: Trilog.exe
Sha-1: dc81f383624955e0c0441734f9f1dabfe03f373c
Hash MD5: 6c39c3f4a08d3d78f2eb973a94bd7718
Tamaño: 21KB
Date-Time: 0x49180192 (11/10/2008 1:40:34 AM)
Compilador: Microsoft Visual C/C++ (2008) [msvcrt] / Microsoft Linker (9.0)
Figura 5: Código módulo principal de trilog.exe
Figura 6: Módulo payload adicional
Figura 7: Hex-dump del payload
Figura 8: Tslow, interface de bajo nivel para Tristation
El modulo Tslow, es uno de los principales “activos” del malware y capaz de ejecutar las siguientes instrucciones y procesos dentro el ataque:
_init_: inicializar la comunicación con valores por defecto.
Close: crear todas las comunicaciones TCM y UDP.
detect_ip: detecta la dirección IP enviando un mensaje de ping precargado al 255.255.255.255:1502
connect- se conecta a la dirección IP del controlador.
udp_close: cierra las conexiones UDP.
udp_send - envía paquetes UDP para mantener la conexión en vivo.
udp_flush - vacía paquetes UDP.
udp_recv - recibe un paquete UDP ficticio.
udp_exec – exec la comunicación UDP.
udp_result - return el estado de la ejecución de las funciones del protocolo UDP.
tcm_ping - envía ping a través de TCM.
tcm_connect - se conecta a través de TCM.
tcm_disconnect - desconecta la conexión TCM.
tcm_reconnect - restablece la conexión TCM.
tcm_exec - ejecuta la comunicación TCM.
tcm_result: - devuelve el resultado de ejecutar funciones de protocolo TCM.
ts_update_cnt - cuenta el número de comandos ejecutados.
ts_result - devuelve el estado de ejecutar comandos TS.
ts_exec - ejecuta un comando TS.
Además de estos módulos principales, consta de 36 módulos adicionales que le confieren una potencia destructiva de los sistemas muy elevada.
Figura 9: Esquema principal TSAA Triconex
El malware TRITON también esta implementado para comunicarse con los dispositivos utilizando el protocolo propietario Tristation (protocolo que carece de documentación publica). La vulnerabilidad principal en Triconex, es la denegación de servicio, lo que provoca en este tipo de dispositivos la caída de toda la red de intercomunicación OT que depende del Triconex. Dicha vulnerabilidad DDoS se puede desencadenar enviando paquetes TSAA por el puerto UDP 1500.
Mitigación y protección:
Se deben tomar una serie de medidas adicionales para mitigar y controlar un posible ataque dcon malware de la familia TRITON:
• Acceso físico: Un buen control al acceso físico a los controladores SIS, así como el resto de componentes hardware , deben mantenerse en espacios cerrados controlados por acceso limitado , monitoreados y accesibles solo para personal autorizado. Asimismo el switch físico en los controladores Triconex debe mantenerse en la posición "Ejecutar" durante las operaciones normales, a fin de limitar accesos o cambios malintencionados de un cambio de configuración no controlada o no autorizada.
• Control y segmentación de la red: Mantener les dispositivos SIS en una red aislada y controlada.
• Escaneado permanente de la red: Instalar tecnologías de monitoreo de la red, de forma continua y sistemática con análisis del trafico en la misma. Implementar tecnologías de IA, con el fin de mejorar el análisis automático para detectar flujos de comunicación inesperados entre dispositivos, detección de nuevos dispositivos conectados, escaneo de todos los métodos de intercambio de datos entre la red.
Schneider Electric lanzó una Notificación de Seguridad con nivel "Importante" con pasos de mitigación específicos con respecto a sus controladores de seguridad Triconex. Schneider Electric recomienda verificaciones periódicas para las actualizaciones de la notificación de seguridad, incluidos los requisitos de configuración técnica específica.
A ciencia cierta se desconoce la autoría del malware, ya que no se han notificado secuestros ni pagos en ninguna de las formas que se conoce hasta ahora el secuestro de sistemas o archivos. Todo indica que los objetivos y el daño a infligir, estaban muy claros, empresas energéticas muy bien definidas, aunque seguramente experimentaron con un objetivo mas amplio (Arabia Saudí, Asia y Europa). Todo este desarrollo, conocimiento del producto, así como de algún protocolo sin documentar a ataques de estado.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Para consultas puedes usar el 
