Hace unos años saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.

Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.

• Safety, Parte I
• Safety, Parte II

Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.

Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.

Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.

TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.

Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.

El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.

Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “library.zip”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:

Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.

Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.

Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.

Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.

Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:

1. Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
2. Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
3. Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
4. Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.

Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.

Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:

1. Aplica a equipos concretos de un determinado fabricante, no a todos.
2. Debe darse la condición de que un conmutador físico debe estar en cierta posición.
3. Alto conocimiento de esta tecnología.
4. Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
5. No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.

Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.

1. Establecer una red físicamente independiente para los sistemas SIS.
2. Implementar NGFW que filtren el tráfico de gestión hacia ellos.
3. Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
4. Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1], [2]; Control de dispositivos USB [1]
5. Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
6. Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
7. Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.

Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.

Un saludo, nos vemos en la próxima.

Referencias:

• FireEye
• ICS-CERT
• Dragos Security
• Titanium Industrial Security
• Kaspersky
• Fortinet
• Schneider Electric

Más información:

• Webinar Dragos Security
• Midnight Blue Security Consultancy
• A Totally Tubular Treatise on TRITON and TriStation
• TRITON Actor TTP Profile, Custom Attack Tools, Detections, and ATT&CK Mapping
• Black Hat: Understanding TRITON, The First SIS Cyber Attack
• DARKNETDIARIES: EP 68 TRITON.
• VIDEOS