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

Tu PLC Sauter viene con una cuenta de e-mail de "regalo"

Sauter moduweb Vision es un módulo que proporciona un aplicativo web para la visualización de manera compacta, sencilla e intuitiva de la información que proporcionan diversos PLCs a los operarios que los utilizan en sus Sistemas Industriales. También permite interactuar de manera directa en la configuración de ciertos parámetros de este tipo de autómatas programables.

Figura 1: Tu PLC Sauter viene con una cuenta de e-mail de "regalo"

Una funcionalidad que incorpora este módulo, es la configuración de un cliente de correo electrónico para que, en el caso de que se dispare una alarma (temperatura por encima de una consigna, extractores de humo averiados, etc…), automáticamente se envié una notificación por correo electrónico a la persona responsable, avisando del tipo de incidencia.

Figura 2: PLC Sauter

Veremos en el presente artículo cómo, aprovechándonos de la configuración por defecto de acceso a la gestión del PLC mediante el módulo moduWeb Vision, es posible acceder a la configuración del cliente de correo electrónico del PLC, obtener la contraseña de la cuenta de correo indicada para las notificaciones y comprobar, con la ayuda del protocolo SMTP, si el password de acceso a la cuenta de correo electrónico realmente se corresponde con ésta.

Fase 1: Búsqueda de dispositivos Sauter con el módulo moduWeb Vision

Localizar PLCs con el módulo moduWeb Vision es realmente fácil, utilizando el patrón “Sauter moduWeb - Login” presente en el título de la web. Realizando un poco de Hacking con Buscadores, Google devuelve los siguientes resultados:

Figura 3: Dorking y resultados devueltos por Google

Fase 2: Datos de acceso por defecto

Muchos de estos PLCs conectados a Internet, que controlan entornos donde las vidas humanas tienen un papel fundamental ya que pueden estar en Sistemas Industriales o Infraestructuras Críticas, siguen presentando configuraciones inseguras por defecto. Una sencilla búsqueda en Google nos proporciona los datos de acceso por defecto a estos dispositivos con moduWeb Vision: “admin” y “password”.

Figura 4: Búsqueda de los datos de acceso por defecto

Introduciendo la información mostrada en la figura anterior, es posible acceder a buena parte de estos dispositivos. En la figura siguiente, se muestra el panel de manipulación y monitorización del sistema de calefacción de un bloque de viviendas comunitario con credenciales por defecto.

Figura 5: Diagrama de un sistema de calefacción comunitario

Fase 3: Configuración del cliente del correo electrónico del PLC

Como se ha comentado, el módulo moduWeb Visión dispone de un cliente de correo electrónico que se comunica con un servidor de correo electrónico bajo el protocolo SMTP (Simple Mail Transfer Protocol) usando el puerto 25/TCP. Para ello, hemos de proporcionar en el la configuración del cliente de correo, quién es el servidor de correo electrónico saliente que enviará el mensaje de alerta a un buzón de correo electrónico, la cuenta de correo electrónico y la contraseña de correo.

Figura 6: Parámetros de la configuración del cliente de correo electrónico por SMTP

Por defecto, léase la documentación del PLC, la opción de SSL para enviar correos electrónicos cifrados viene desactivada.

Fase 4: Seguridad por ocultación

En la figura anterior puede observarse cómo la contraseña, a primera vista, no aparece en texto plano debido al uso del campo input de tipo password en el formulario de configuración del cliente de correo SMTP. Basta realizar un cambio en caliente desde el navegador web para obtener la clave en texto claro de la cuenta de correo electrónico.

Figura 7: Modificación en el formulario del cliente para ver la password

Conocida el password de uno de los usuarios del servidor de correo saliente usado por el PLC, el siguiente paso es comprobar que realmente se trata de una identidad digital válida utilizada por el PLC. Aquí es dónde entrará en juego el protocolo SMTP.

Fase 5: Diálogo con el servidor de correo electrónico mediante SMTP

El protocolo SMTP (Simple Mail Transfer Protocol) utiliza por defecto el puerto 25/TCP. Para conectarnos, basta realizar una conexión TCP del servidor. Inicialmente intentaremos mandar un correo electrónico desde la cuenta de correo descubierta en el PLC. En caso de no estar bien configurado el servidor de correo, podríamos “spoofear” cualquier cuenta de correo electrónico (aunque el nombre de dominio fuera diferente al nombre de dominio configurado en el servidor de correo electrónico) y usar ese servidor para realizar ataques, por ejemplo, de spear phishing.

Comprobamos cómo el servidor de correo no permite el envío de correos electrónicos si no nos autenticamos correctamente en él.

Figura 8: Conexión SMTP e intento de envío sin autenticar. El servidor no lo permite.

Es en este punto es donde utilizaremos para la autenticación el password descubierto en la figura 6. Tras conectarnos al puerto 25/TCP, con la opción “auth login” decimos al servidor que queremos autenticarnos en él. El servidor nos devolverá el mensaje “334 VXNlcm5hbWU6”, que se trata de una cadena codificada en Base64 solicitando el nombre de usuario.

Introducimos el nombre de usuario codificado en Base64 (c2xxxxxxxxx20=) y el servidor nos devuelve el mensaje “334 UGFzc3dvcmQ6” codificado en Base64 solicitando el password. Codificamos el password de la figura 7 en Base64 y se lo enviamos al servidor de correo. El servidor devuelve un mensaje de que la autenticación es correcta (authentication succeeded).

Tras indicar quién es el emisor del mensaje y el destinatario, finalizar el mensaje con punto (.), el servidor devuelve el mensaje “mail accepted for delivery” (correo aceptado para la entrega). A continuación se muestran todos los pasos de la conexión SMTP AUTH a través de Telnet:

Figura 9: Conexión SMTP AUTH a través de Telnet

En estos momentos, podemos determinar que la cuenta de correo electrónico y el password presente en la configuración del cliente de correo del PLC de la figura 7, realmente pertenecen a una identidad digital válida en el servidor de correo saliente usado por el módulo moduWeb Vision del PLC Sauter y está distribuida en todos y cada uno de los dispositivos. Todos con la misma. No parece la forma más segura de crear un sistema industrial.

Autor: Amador Aparicio (@amadapa), autor del libro "Hacking Web Technologies"

Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación de @0xWord

Desde hoy está disponible a la venta un nuevo libro de 0xWord centrado en la seguridad de los Sistemas Industriales y las Infraestructuras Críticas. Es el número 43 de la colección, y en esta ocasión la temática elegida ha sido una de las más importantes en la corriente de Industria 4.0 que se nos viene hoy encima.

Figura 1: Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación

Su autor es Juan Francisco Bolívar, y ha volcado su experiencia en la auditoría de estos sistemas para explicar cómo se auditan sistemas PLCs a través de los diferentes interfaces de acceso, cómo funcionan los protocolos HMI o cuál es la arquitectura de los sistemas SCADA que se implantan en muchas fábricas automatizadas a diferentes niveles.

Figura 2: Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación

El libro se centra en explicar las tecnologías que forman parte habitualmente de los sistemas industriales, cuáles son sus protocolos y sistemas, para después pasar a explicar cómo se pueden localizar los objetivos, cuáles son las herramientas necesarias para realizar una auditoría de seguridad y termina dando buenas prácticas y recomendaciones para la fortificación de los mismos. Os he subido el índice del libro a mi SlideShare.

Figura 3: "Infraestructuras Críticas y Sistemas Industriales: Auditorias de Seguridad y Fortificación"

La portada es obra de Rodol, que como veis se ha lucido con el diseñado haciendo una de las que a mí personalmente más me han gustado. Una pieza preciosa para mi colección particular de libros. 

Saludos Malignos!

Hacking de dispositivos IIOT (Industrial Internet of Things) #IIoT #IoT #Hacking

Durante este mes de septiembre, se han celebrado al 3ª edición de la RootedCON Valencia, y la 6ª edición de Navaja Negra , en las cuales se me invitó a presentar una serie de investigaciones y ataques sobre dispositivos y equipos industriales, además de algún dispositivo IIOT, - no se incluyeron accesos a infraestructuras críticas, por posibles temas legales - se presentaron accesos a dispositivos críticos de un amplio abanico del sector industrial, con un titulo de la presentación, el cual daba que pensar, “¿A que piso va?”

Figura 1: Hacking de dispositivos IIoT (Industrial Internet of Things)

¿Qué objetivos buscamos?, básicamente se intenta demostrar, la mayoría de las veces con éxito, que existen infinidad de dispositivos vulnerables en cualquiera de nuestras industrias, rastreando varios sectores, como la generación y distribución de energía eléctrica, fotovoltaica, gas, agua, aerogeneradores, sistemas integrales de climatización, y un gran “cajón desastre”de dispositivos IIoT. Por aquí, en este mismo blog, ya se han hablado de muchos casos similares, así que para completar este artículo, puedes leer las historias de:

- PLCs de Allen Bradley envían la password de Administración
- 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
- 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 

En esta investigación, siguiendo pasos similares, vamos a ver ejemplos varios:

• Maquinaria industrial (metalurgia, alimentación, servicios auxiliares, etc...
• Energía (plantas foto-voltaicas, plantas generación eléctrica, estaciones bombeo).
• Aerogeneradores.• Sistemas integrales de climatización(edificios e industrias).
• Smartmeters (IIOT- contadores eléctricos).
• Varios( sistemas riego y alumbrado grandes ciudades, frío industrial.

Una vez focalizados los objetivos de estudio y análisis, se centran todos los esfuerzos en una serie de fabricantes concretos, debido a dos factores: experiencia en el sector industrial, y conocimiento más profundo de alguno de ellos. Los tests se realizan sin utilizar ataques de fuerza bruta, siempre con accesos directos abiertos y mediante credenciales por defecto. Se trabaja sobre dos grandes grupos de dispositivos, los controlados directamente por CPU, y los administrados por servidores web propios (generalmente GNU/Linux y versiones de Apache 1.3, o 1.4  sin fortificar - ¡gran error!-)

Figura 2: Algunos de los fabricantes principales catalogados para hacer la investigación

Durante el proceso, se detectaron una serie de vulnerabilidades en bastantes de los equipos y sistemas testeados, que aún existiendo mucha información de ellas con su correspondiente CVE publicado, el 85% de los sistemas IIoT localizados, no han sido actualizados desde el “inicio de los tiempos”. Existe un gran abismo temporal entre el fabricante, desarrollador e implantador final, que imposibilita aplicar de forma robusta políticas de ciberseguridad en muchas industrias, además de que la transición de la industria 3.0 a 4.0, es lenta y complicada por la heterogeneidad de cientos de dispositivos. Las vulnerabilidades localizadas en estos dispositivos IIoT han sido de diferentes tipos, como por ejemplo:

• Ejecución remota de código.
• Extracción arbitraria de ficheros.
• XSS en varios de los sistemas.
• Denegación de servicio.(alto porcentaje).
• Buffer overflow.
• Restricción incorrecta de operaciones de la pila.
• Inyección SQL en plataformas web(del sistema o equipo).

Una vez fijados los objetivos, tenemos dos opciones. La opción uno es hacer un poco de hacking con buscadores y utilizar Shodan o Censys para localizar los objetivos y obtener una cantidad ingente de resultados. La opción 2 consiste en filtrar la búsqueda con una herramienta a medida a fin de optimizar el resultado final.

Figura 3: Arquitectura de la herramienta creada.

Utilizando la interacción de varias herramientas como nmap o Metasploit, y la API de Shodan, se puede diseñar una pequeña herramienta escrita en Python alimentada previamente con datos de los objetivos buscados, tales como fabricantes, modelos, versiones, CPU, clock, ranuras de expansión, puertos específicos de cada fabricante, áreas de memoria, usuarios, passwords, directorios ocultos, etcétera, con el objetivo final de extraer los máximos datos posibles y minimizar falsos positivos.

Figura 4: Resultados obtenidos tras la fase de recogida de información.

Finalmente, una vez realizada la extracción y el posterior filtrado de datos,podemos iniciar el acceso a los diferentes dispositivos. Este acceso se realiza mediante el software (versión demo) de cada fabricante. Los accesos son ejecutados en formato remoto, y en modo monitor, a fin de no alterar el dispositivo auditado.

Estos son algunas de los dispositivos localizados con fallos de seguridad. El primero de ellos es el acceso a una estación de bombeo de agua.

Figura 5: El acceso está realizado mediante un enlace radio en la banda de 433 MHz.

El segundo ejemplo es el acceso a un PLC de una planta de distribución de gas. Además de permitir a un atacante modificar y actuar sobre cualquier elemento industrial, se puede extraer cierta información sensible, debido a que el dispositivo en cuestión puede enviar mensajes SMS, e-mail, se puede acceder a bases de datos (con cadenas de conexión autenticadas mediante usuario/password)  y recursos compartidos en una red MS Windows dentro de una arquitectura de Active Directory. Es decir, el atacante podría atacar la red Windows desde el PLC, haciendo bueno el concepto de Shadow IoT.

Figura 6: Acceso a PLC en planta de distribución de gas.

Acceso a un aerogenerador y a un sistema de cabecera de una planta fotovoltaica. Estos dispositivos disponen de servidor web propio integrado, con múltiples vulnerabilidades de funcionamiento y acceso, como usuarios y password por defecto, posibilidad de subida de scripts, configuración de un segundo servidor DNS, etcétera.

Figura 7: Funcionamiento del sistema de la turbina.

Figura 8: Acceso a sistema de cabecera de planta fotovoltaica.

Mediante el script Termineter, escrito en Pyhton por dos investigadores y publicado a finales del 2014, se demuestra como es posible con pocos medios y conocimientos técnicos, acceder a los smartmeters que tenemos instalados en nuestras viviendas, mostrando los datos del dispositivo y lecturas energéticas.

Figura 9: Ejecución de Termineter contra smartmeter local conectado vía serie.

Figura 10: Smartmeter al que se conecta y contra el que se lanza Termineter.

Conectando una Raspberry Pi y un pequeño script de lectura secuencial, es posible acceder a otros smartmeters conectados al mismo concentrador de la compañía - que no tenía Latch -. El acceso se realiza en modo “invitado”.

Figura 11: Lectura de varios Smartmeters conectados al mismo concentrador hecha vía remota mediante una Raspberry Pi.

Cabe destacar primero mi sorpresa a la infinidad de dispositivos vulnerables localizados y la facilidad y pocos conocimientos para acceder a ellos. Resulta chocante que sea posible acceder a sistemas tan curiosos como equipos de frío de tanatorios  - en uno de ellos incluso era posible ver los “clientes de la semana” debido a una vulnerabilidad en Mysql -, climatización de edificios públicos, sistemas automáticos de lavado de vehículos con posibilidad de limpieza “infinita”, paneles informativos de carreteras, etcétera, pero el mas preocupante a mi modo de ver es el sistema que da titulo a las charlas: Los ascensores

Figura 12: Acceso libre a un ascensor, al que es posible configurar sin seguridad.

Cantidad ingente de dispositivos vulnerables en nuestro país, con el agravante que transporta personas y vulnera su integridad física, y con los que es posible configurar, o interaccionar con el equipo hasta limites de desactivar cualquier seguridad existente.

Conclusiones finales:

En un tiempo en el que fortificamos parte de nuestra vida digital o nuestros sistemas habituales usando contraseñas, dobles factores de autenticación, cifrado de discos, smartphones protegidos, portátiles con antirrobo, tarjetas de claves, firewalls, conexiones VPN, etc..., hay ámbitos cotidianos a los que no le prestamos la atención suficiente en temas de seguridad, y hay que hacerlo, como decía el documento de Seguridad en IoT que publicaba ElevenPaths, el ámbito de uso de los dispositivos IoT, como es el caso de los dispositivos industriales, puede ser de una sensibilidad mayor.

Figura 13: El CNPIC actualmente informa a día de hoy que el riesgo de un incidente de seguridad es ALTO

Tal vez por que no tiene repercusión mediática o notoriedad el acceso a un dispositivo industrial IIoT, o simplemente porque los cibercriminales aprovechan estos fallos para hacer ataques muy dirigidos como el de la fábrica potabilizadora de agua en UK. Por otra parte parece que hay “luz al final del túnel”, porque organismos oficiales, como el Centro Nacional de Protección de Infraestructuras Críticas, están realizando un trabajo contrarreloj para mitigar y concienciar sobre el futuro de nuestros dispositivos y equipos industriales. ¡Hacedles caso que el nivel de riesgo actual es ALTO!

Autor: Jordi Ubach (@jubachm)

SmartGrids protegidos con Latch: Concentradores de Telegestión de Contadores PLC de Telecon integran Latch

Ayer se publicó en el blog de Eleven Paths un caso de uso de la tecnología Latch que nos pareció más que interesante, ya que combina el uso de dispositivos hardware con nuestra tecnología Latch. El caso de uso es bastante sencillo de entender, es una protección de un dispositivo físico desplegado en instalaciones contra accesos no autorizados. En concreto le permite a la empresa instaladora controlar el acceso a los Concentradores de Telegestión que se encargan de gestionar los Contadores PLC y que fabrica TELECON.

Figura 1: SmartGrids protegidos con Latch: Concentradores de Telegestión
de Contadores PLC de Telecon integran Latch

TELECON es una compañía española de origen gallego centrada en la fabricación de dispositivos inteligentes que se puedan aplicar a escenarios de Control Industrial Inteligente, SmartCites, soluciones (IoT) Internet of Things, o sistemas de vigilancia. Uno de los grandes problemas que se han detectado en los dispositivos hardware que se despliegan es la ausencia de segundos factores de autenticación en los procesos de control de acceso, y mucho peor, la implantación de los mismos con contraseñas por defecto o comunes.

Figura 2: Empresa Telecon

Para hacer más fácil el control de acceso a los dispositivos, desde TELECON han lanzado una línea de dispositivos hardware, estos Concentradores de Telegestión de Contadores PLC utilizados en soluciones de eficiencia energética y SmartGrids, que vienen incluidos con Latch. Esto permite a la empresa instaladora controlar el acceso a los mismos desde un dispositivo centralizo que abra y cierre las cuentas a los técnicos que deben ir a hacer las revisiones de forma centralizada.

Figura 3: Nuevos Concentradores de Telegestión que incorporan Latch

Es decir, es un dispositivo de supervisión que no solo permite elegir cuándo se van a poder realizar los accesos al dispositivo, si no que además permite - con la posibilidad de recibir una alerta cuando se acceda con el Latch abierto - saber cuándo se está accediendo a cada uno de los mismos.

Figura 4: Control del acceso a los Concentradores con Latch

Este es un caso de uso de Latch como capa de protección a un escenario de seguridad industrial, ya que desde estos dispositivos se pueden hacer cosas como cortar la luz de la instalación a la que estén conectados y tener esta posibilidad de gestión remota y supervisión de accesos mejora la protección de toda la infraestructura. Si tienes algún otro caso de uso en el que hayas implementado Latch, cuéntamelo, que nos llena de alegría ver cómo se usan nuestras tecnologías.

Saludos Malignos!

PLCs de Allen Bradley envían la password de administración

Después de contar por aquí como había realizado un ataque de fuerza bruta contra un PLC Omron CJ2H CPU64-EIP y expresar mi opinión de que los fabricantes de sistemas de automatización no se preocupan lo suficiente de la seguridad recibí críticas muy acertadas aquí y en otros foros. Algunas indicándome que no debía de generalizar diciendo que los fabricantes de sistemas de automatización no se preocupan de la seguridad y otras invitándome a que le “tocara los bits” a otras marcas.

El único motivo de haber realizado muchas pruebas con los sistemas de Omron es que tengo acceso a varios PLCs de esta marca y puedo hacerles “maldades” sin comprometer ningún sistema ajeno pero los comentarios que se publicaron no hizo otra cosa que aumentar mi curiosidad, por lo que decidí hacer un poco de hacking con buscadores para ver lo que encontraba por ahí en Internet.

Para hacer esa prueba abrí el flamante latch que ya he puesto en mi cuenta de Shodan e hice una búsqueda que pronto arrojó resultados que dejan ver la poca conciencia de seguridad que hay en el entorno de la ciberseguridad industrial, al estar esta cantidad de PLCs expuestos en la red directamente.

Figura 1: 930 resultados en Shodan con PLCs conectados a Internet

Si buscamos la cadena “Programmable Logic Controller” vemos como aparecen cientos de dispositivos de la firma Allen Bradley. Me centro en los resultados filtrando solamente España y los resultados bajan a 31. Me conecto de forma aleatoria a 5 de los controladores encontrados y solamente 2 tienen definida contraseña “para evitar el acceso no deseado”. Esto que a priori puede parecer que no es culpa del fabricante, pero podría evitarse si los fabricantes no dejaran que el establecimiento de la contraseña fuera opcional ni hubiera ninguna por defecto que alguien pudiese dejar por descuido.

Por aquello de la curiosidad me olvido rápidamente de los 3 que no están protegidos por contraseña y vamos a ver como se hace el intercambio de claves entre el PLC y el software de programación. En un principio hago lo que me parece más lógico, me conecto al PLC y cuando se va a proceder al intercambio de claves - iluso de mí - arranco Wireshark modificando las opciones de captura para limitar ésta a los paquetes que se intercambian con la “víctima” y evaluar qué solución de cifrado digital de la comunicación y el password está utilizando.

Figura 2: Opciones de captura de WireShark para analizar la negociación

Una vez tengo Wireshark listo procedo a escribir un password aleatorio en el software de administración de estos PLCs simplemente para ver cómo lo envía y pulsar OK. El resultado es un mensaje de password incorrecto, pero Wireshark no captura nada. Vuelvo a probar con un segundo password por asegurarme y sigue sin capturar nada. Algo he tenido que hacer mal.

Figura 3: Cuando se pone la contraseña de acceso Wireshark no captura tráfico

Vuelvo a conectarme al PLC, esta vez con Wireshark ya capturando todo y recibo paquetes, pero sólo hasta que el software pide el password de acceso, una vez llegados a este punto hago tres intentos al azar y no hay intercambio alguno de datos.

¿En serio?, ¿es el PLC el que envía el password al software y éste se encarga de la comprobación?

Reviso las capturas de todo el tráfico en detalle a ver si veo algo sospechoso que pudiera ser la contraseña en claro, que ya vimos en otra ocasión como capturar la clave en claro con los PLCs Omron mediante un ataque de red de tipo man in the middle. Al poco tiempo algo me llama la atención en el siguiente paquete.

Figura 4: Paquete "sospechoso" con un PIN de acceso

Lo que me llama la atención es que tiene texto en claro. Lo pruebo como clave y efectivamente, la clave es correcta, es el PLC de Allen Bradley el que envía la clave en claro al software de control para que éste la verifique. Esta vez no voy entrar en valoraciones, saquen sus propias conclusiones.

Autor: Juan Luis Valverde Padilla
jl.valverde@jvalverde.es

Ataque de fuerza bruta a PLC Omron CJ2H CPU64-EIP

Recientemente contaba en un importante portal dedicado a la automatización industrial cómo había tenido que improvisar “on the fly” un ataque por fuerza bruta contra CX-Programmer para liberar los permisos de lectura de programa en un PLC Omron modelo CQM1-CPU43 protegidos por un código decimal de cuatro dígitos - 10.000 combinaciones -.

Los motivos que permitieron el éxito del ataque fueron dos. Por un lado la CPU que con una antigüedad de 16 años como mínimo no limita el número máximo de intentos de liberación de permisos que se pueden realizar mediante peticiones a su puerto serie y  por otro lado está el tema del software, que tampoco tiene limitaciones en este sentido.

Que la CPU no limite el número de intentos por el puerto serie tiene cierta lógica cuando hablamos de equipos tan antiguos nacidos en tiempos menos preocupados por la seguridad en la electrónica industrial ya que en modelos más modernos de esa misma CPU sí que fue limitado el número de intentos que se podían hacer para desbloquear un sistema, pero me resultó algo más extraño que el software no implementara ya ningún control porque estamos hablando una versión actual del mismo.

Además, en la prueba que realicé el ataque se producida conectado al cable serie, con las limitaciones de tiempo y de necesidad física de conectarse cerca, pero ¿qué pasa con las comunicaciones TCP/IP que ya llevan este tipo de controladores? ¿Estarían protegidas contra ataques de fuerza bruta?

Un ataque de fuerza bruta a un PLC por TCP/IP

El primer paso fue el de pedir a Omron las especificaciones del protocolo FINS (Factory Intelligence Network Service) para buscar el comando de liberar la protección, pero por algún motivo han decidido no poner este comando en la lista del manual “Sysmac CS/CJ/CP Communications Commands Reference Manual” que me enviaron.

Figura 1: Listado de comandos FINS según el manual de referencia del fabricante

Como ya pudimos ver cuando capturábamos las claves de un PLC mediante un ataque MITM, Omron no cifra las comunicaciones entre el PLC y su propio software de programación. Este software de hecho utiliza el propio protocolo FINS para la comunicación con el PLC, así que fue sencillo analizar mediante Wireshark el proceso de intento de liberación de protección para ver la trama enviada del software de controla al PLC.

Figura 2: Captura de conexiones de comandos FINS

Figura 3: Detalle ampliado del comando FINS enviado desde el software CX-Programmer PLC

Si analizamos esa trama enviada y la comparamos con la estructura del comando FINS estándar que encontramos en el manual se puede comprobar que coincide perfectamente. Para no hacer demasiado extensa la explicación no voy a entrar en detalle de que es cada uno de los elementos del comando, pero vamos a descomponer el mensaje capturado con Wireshark para ver su estructura.

Figura 4: Detalle de un comando FINS

ICF: 80
RSV: 00
GCT: 07
DNA: 00
DA1: 00
DA2: 00
SNA: 00
SA1: AC
SA2: 00
SID: 7C
Command Code: 03 05
Text: FF FF 00 55 4D 00 00 00 00 00 00

Se puede ver que el comando de liberación es “03 05” y que hay otro campo con pinta de ser más que interesante dentro de la trama, el comando “Text”. Este comienza por los valores “FF FF 00” y a continuación está la representación ASCII en formato Hexadecimal de la clave que se ha utilizado para intentar liberar los permisos (UM) seguida de seis caracteres NULL.

La clave en concreto puede estar formada por una cadena de 8 caracteres dentro del espacio de valors que estos equipos pueden manejar que van desde la "A" a la "Z" mayúsculas, desde la "a" a la "z" minúsculas, y desde el "0" al "9".

Con todo esto ya tenemos los datos suficientes para componer tramas e ir enviando mensajes al PLC hasta que consigamos obtener la clave. Para la prueba de concepto establecí en el PLC una clave numérica y escribí un pequeño programa en el mejor de mis spaghetti code en VB.NET que atacaba al PLC extrayendo las claves de un diccionario de palabras. El resultado del ataque a la protección contra lectura de “User Memory” fue el siguiente.

Figura 5: Mensaje de clave encontrada

Conclusión final

Parece que Omron, después de protegerse contra los ataques por fuerza bruta en los puertos serie en algunas versiones de producto de sus PLCs vuelve a permitir este tipo de ataques unos años después por la capa TCP/IP.

Es cierto que como cualquier ataque por fuerza bruta puede volverse eterno en función del diccionario que utilicemos, podemos observar que ha tardado 29 minutos en testear menos de 300.000 contraseñas. Obviamente la aplicación que se ha escrito para la prueba de concepto no es más que una herramienta de usar y tirar sin optimizar y que seguro que se puede mejorar.

Hay que decir también que para la protección contra lectura de tareas se utiliza el mismo comando, solo que el campo texto comienza por “FF FF 02”. Ambas pruebas se realizaron contra un CJ2H CPU64-EIP y el resultado fue exitoso. El PLC aguantó el ataque y las contraseñas aparecieron.

Figura 6: PLC CJ2H CPU64-EIP

Si alguna vez tenéis que establecer una contraseña para uno de estos sistemas recordad que es importante que sea larga y compleja, como en cualquier otro acceso que deseemos proteger, porque no hay más protección en estos sistemas que la paciencia que tenga el atacante para intentar todas las combinaciones posibles en un ataque de fuerza bruta a todo el espacio posible de passwords.

Autor: Juan Luis Valverde Padilla
e.mail: jl.valverde@jvalverde.es

La historia de un carnicero agradecido con un "hacker"

Hace algún tiempo, cuando estaba recopilando información para escribir el artículo sobre la seguridad de los sistemas basados en PLCs que se llamó “Tu industria en mi manos”, creé una lista bastante extensa de equipos de automatización expuestos en Internet. Cuando el tiempo me lo permite - muy de tarde en tarde -, me dedico a volver a comprobar si los sistemas continúan “vivos y expuestos”. Los resultados son desalentadores.

¿Es que nadie leyó el artículo o es que a nadie le importa realmente la seguridad de sus automatizaciones? Lo más probable es que seguramente, salvo a los que estamos cerca del mundo de la tecnología y la seguridad, al resto de las personas no les llegan estas cosas.

Con las automatizaciones que me parecen más críticas hago un esfuerzo extra, las analizo y busco algún dato que me ayude a ponerme en contacto con el responsable de ellas de forma directa para poder ayudarle en la manera que me sea posible. Y es así, de esta forma, como comienza esta historia con un carnicero.

Entre la larga lista de automatismos expuestos sin seguridad alguna, una de las instalaciones que se encontraba desprotegida en Internet, parecía a simple vista la encargada de controlar la temperatura de alguna industria cárnica.

Figura 1:El PLC de la industria desprotegido en Internet 

Husmeando con cuidado de no romper nada en la memoria del PLC, se encuentra un comando AT para enviar mensajes SMS a un teléfono móvil con las alarmas del sistema. Esto es algo muy común en este tipo de sistemas de control que pretender avisar a los responsables en el mismo momento en que se detecte un problema que pueda afectar a su negocio.

Figura 2: Número de teléfono para el envío de alertas vía SMS

Descubierto esto, quise ponerme en contacto con el dueño de la plataforma para advertirle de la situación de inseguridad en la que se encontraba, así que decidí buscar información de esta persona haciendo un poco de trabajo de campo con los buscadores de Internet.

En este caso, simplemente poniendo el número de teléfono de que aparecía como contacto del sistema de alertas, Google devuelve - entre otros - un resultado la mar de interesante. Un fichero Excel con el número de teléfono buscado que estaba almacenado en algún servidor FTP.

Figura 3: Resultados de búsqueda del número de teléfono. Un XLS en un FTP

Pero claro, no todo iba a ser tan fácil, ya que al intentar acceder al fichero, el resultado que se obtiene no es el documento, sino que el servidor FTP solicita credenciales de acceso.

Figura 4: El servidor FTP autenticado

En este caso no dejó de ser curioso esto, ya que el documento está indexado en Google, lo que indica que en algún momento del pasado este servidor FTP estuvo abierto a todo Internet, y Google ya lo cacheó. Al abrirlo el documento arrojó un montón más de información de la que esperada en un inicio. Información que no debería ser pública según indica la LOPD. Vamos, que el dueño de ese fichero, al aplicar la LOPD se olvidó de borrar la URL de los buscadores el dueño del fichero tras ponerlo bajo acceso autenticado.

A partir de aquí, teniendo el nombre y los apellidos de alguien relacionado con el número de móvil que había sacado del PLC, y sabiendo que es una industria cárnica que se encontraba en una localidad donde estaba ubicada la dirección IP en la que se exponía el sistema, encontrarla fue coser y cantar.

Figura 5: Los datos de contacto del número de teléfono

Decidí ponerme en contacto mediante un mensaje de correo electrónico aunque he de decir que no me esperaba respuesta alguna. Os aseguro que la mayoría de veces que he intentado avisar a alguien de que tiene una brecha de seguridad he recibido como habitual el silencio por respuesta, cosa bastante frustrante, pero allá cada cual con sus instalaciones.

En este caso la respuesta fue totalmente diferente. La empresa responsable de la infraestructura informática de la planta hizo su trabajo buscándome por redes sociales hasta dar con la empresa donde trabajo y se puso en contacto conmigo, no sólo para que le facilitase la información completa de cómo los había encontrado, sino para agradecerme de parte de la industria cárnica que los avisase. Un sabotaje de éste sistema de automatización podía haber provocado la pérdida de productos cárnicos cuyo valor económico es una linda cifra de seis dígitos.

A día de hoy, he vuelto a comprobarlo y ésta gente ha hecho sus deberes, ya no tiene su PLC expuesto a cualquier desaprensivo con tiempo libre, además de haber cerrado algún otro puerto que tenían abierto. Es reconfortante, muy reconfortante ver que realmente sirve para algo este tiempo que dedicamos a buscar “problemas de otros”. He querido compartir esta experiencia porque, por cada una buena respuesta, sé que hay diez malas, pero aún así...¡no perdamos la esperanza!

Saludos,

Autor: Juan Luis Valverde Padilla
jl.valverde@jvalverde.es

PD: Ahora tendré que hablar con el dueño del servidor FTP para contarle cómo borrar las URLs indexadas en Google y recomendarle algún libro que le ayude aplicar la LOPD correctamente, aunque gracias a su fallo de seguridad, pude dar con la empresa y ayudarles a corregir su fallo de seguridad. Irónico. :)