Cómo funciona TRITON (TRISIS): Un malware para Sistemas de Control Industrial del que protegerse

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

Aunque parece que no ha evolucionado sí que continua contando con persistencia activa en algunos sistemas industriales e incluso sus creadores ha aparecido involucrados en el malware utilizado en ataques realizados en este mes de Abril a Sistemas de Control Industrial en Arabia Saudí que terminaron con explosiones.

Figura 2: Noticia en TechCrunch sobre Triton de Abril de este año

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.

Figura 3: "Infraestructuras Críticas y Sistemas Industriales:
Autidoría de seguridad y fortificación"

La familia de malware TRITON, 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.

Figura 4: Sistema Triconex

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.

• Control de acceso remoto/logico:  Mediante cualquier sistema de conexión controladores SIS, ya sea una etehrnet, wifi, ,pendrive, vpn, vnc, teamviewer, etcétera, se debe requerir un sistema e autenticación fuerte y recomendable un Segundo Factor de Autenticación (2FA).

• 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.

Figura 10: Notificación de seguridad para TRITON de Schneider Electric

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.

Figura 11: Notificación de seguridad de ABB sobre TRITON/TRISIS

Dada esta posibilidad tan peligrosa, la empresa ABB también lanzó una Notificación de seguridad cibernética el 22 de diciembre de 2017 con pasos de mitigación similares para sus controladores de seguridad.

Autoría:

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.

Autor: Jordi ubach (@jubachm)

Más referencias de seguridad en Sistemas de Control Industrial e Infraestructuras Críticas

- Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación
- Hacking de Dispositivos IIoT (Industrial Internet of Things)
- Libro de Python para Pentesters en 0xWord
- Libro de Hacking con Python en 0xWord
- PLCs de Allen Bradley envían la password de Administración
- Informe Mandiant sobre APT1
- Ataque de fuerza bruta a PLC Omron CJ2H CPU64-EIP
- Captura de claves en PLCs industriales CP1L-EM de Omron
- Tu industria en mis manos
- Qué fácil es ver las flaquezas de seguridad de algunos ICS (Sistemas de Control Industrial)
- SCADA: Halcones heridos en tus Infraestructuras Críticas
- Otra de passwords por defecto en Honeywell WebStat (Niagara Web Server)
- Concentradores de Telegestión de Contadores PLC de Telecon integran Latch
- Shodan y sistemas SCADA
- Intentan envenenar agua de un planta depuradora en UK
- La historia del carnicero agradecido
- Unidad de (des)cuidados intensivos
- Hundir la flota por computador: Fallos de seguridad en miles de barcos navegando
- AntiDDoS para dispositivos IoT usando un GSM Shield hecho con Stack SMS