Triton/Trisis/Hatman; un malware para SIS. Actualizado 14/02/21

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.

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:

Más información:

 

Análisis de dispositivos USB

Aunque su uso esté ampliamente extendido, de sobra son conocidos los riesgos que entraña el mal uso de memorias de almacenamiento USB y discos de duros externos. Si bien son de mucha utilidad, y en muchos de los casos única vía de compartir de ficheros, pueden convertirse en transmisores de código malicioso, robo de información, entre otros.

Si bien existen soluciones de protección de puesto para PC donde se puede limitar el uso a unos pocos mediante la identificación y registro previo, en entornos industriales existen otro tipo de dispositivos y sistemas que también los utilizan. Ejemplo de ello pueden ser los Controladores Numéricos (CNC) en máquina herramienta o maletas de programación en controladores de brazos robóticos. En el primero de los casos para la transmisión de programas para la realización tareas de mecanizado y en el segundo para las trayectorias de o los brazos.

En esos casos donde es posible no implementar soluciones software resulta necesario realizar un análisis previo para reducir la posibilidad de que estemos empleando unos medios de transmisión de ficheros infectados por alguna pieza de código malicioso. Y digo reducir la posibilidad ya que, como cualquier otra solución basada en firmas, y en concreto los antivirus, podrían no alcanzar una protección sobre ciertas piezas de código. Aunque hace tiempo de aquello, no nos olvidemos del caso IRONGATE en la que dicha pieza no fue descubierta por las distintas herramientas empleadas por el portal VIRUSTOTAL tal y como recogía el siguiente artículo.

Irongate Malware, Thoughts and Lessons Learned for ICS/SCADA Defenders.

Así pues, en aras de proceder a un análisis previo para un uso posterior podemos recurrir a estaciones en las que introducir el elemento USB, proceder a un análisis por un software antivirus y, una vez que tengamos el resultado en la que no se ha detectado código malicioso, proceder a su uso en las estaciones o elementos del entorno de planta.

Para ello Podemos contar con soluciones “SafeDoor” de la compañía AuthUSB.

Se trata de un dispositivo hardware con un software en su interior que nos permitirá analizar, acceder y gestionar la información almacenada. Además, nos ofrecerá protección contra ataques de índole eléctrico como USB Killer o también BadUSB para la generación de interfaces o instrucciones programadas que permitan interactuar con el equipo al que se conecta.

Para su uso, dispone de una conexión de red a cuya IP deberemos conectarnos para acceder al contenido de las memorias conectadas y la distinta configuración disponible como la generación de usuarios con permisos de lectura/escritura; certificados; etc. cuando lo hagamos como administradores.

Al introducir una memoria el dispositivo realizará un análisis en busca de malware a partir de los motores habilitados a tal efecto, pudiendo disponer hasta dos en la versión utilizada para el presente artículo.

Una vez finalizado nos informará de si la unidad está infectada, o no. El resultado podrá verse de forma inmediata a través de uno de los leds que dispone en el frontal. Rojo si ha localizado alguna anomalía o verde si todo está OK.

Luego, accediendo a la interfaz web, podremos obtener información sobre el o los ficheros que ha identificado como maliciosos, así como su ubicación dentro de la misma. En es te caso he empleado a modo de prueba de concepto el fichero EICAR Test File que podéis encontrar aquí.

Dado que dispone de dos conexiones USB, si no hay infección podremos descargar el contenido o copiarlo en una segunda unidad.

Respecto al acceso, podremos definir un conjunto de usuarios con permisos de lectura o escritura, según decidamos al volumen concreto. Esto es, podremos definir sobré qué y cómo se puede acceder.

También podríamos acceder a su contenido por red, siempre y cuando esto pueda llevarse ya que como todos sabemos podemos disponer de elementos aún si esa capacidad. En ese caso visualizaremos los directorios y ficheros pudiendo realizar distintas acciones.

Sin duda los dispositivos USB son elementos no sólo muy utilizados sino que además necesarios dentro de estrategias de recuperación ante desastres como un disco duro externo con copias de respaldo de proyectos de PLCs, programas, ficheros de texto con logs, actualizaciones de software, despliegue de licenciamiento, etc.

Hasta aquí la entrada de hoy. ¡Nos vemos en la siguiente!

Un saludo!

EKANS, SNAKE; new Ransomware targeting ICS environments, Update 07/30/20

New ransomware sample was detected and announced to the community. Here you can find some interesting information that will be updated in the future.

07/30/20