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 
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.
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.
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.
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.
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.
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
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: 80Se 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.
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
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
5 comentarios:
Muy buena la entrada, hasta los grandes meten la pata en temas de seguridad.
Gracias por la crítica.
Lo cierto es que es hasta ahora parece que los fabricantes de sistemas de automatización industrial no se han tomado esto muy en serio.
Un gran articulo Juan. Enhorabuena
Me parece que hay gente que no conoce el sector industrial y está valorando erróneamente la situación. Omron NO es (ni mucho menos) la principal empresa de tecnología industrial. Es una empresa japonesa pero que está en el sector porque tiene buenos precios y eso le da una competitiva relación calidad-precio.
Su soft es cierto que comparado con la competencia es fácil de usar, pero ni es el más potente ni mucho menos el más utlizado.
En PLC cada empresa tiene su propio soft que es incompatible con las demás marcas y adaptado a normas internacionales de programación y cada cliente elige la marca que quiere usar y la maquinaria se programa para esos controladores. Así las mismas máquinas funcionan con diferentes marcas.
Habría que hacer esas pruebas de seguridad con soft de Modicon (inventor de los autómatas), Siemens (uno de los líderes en el sector), Ovation (el número uno mundial con diferencia, filial de Emerson), o quizá marcas como Telemecanique (líderes en Europa)
Se están sacando conclusiones con una marca que viene a ser como juzgar la informática por los equipos de Dell. Saludos
Nemigo estoy de acuerdo contigo.
Es cierto que sería muy interesante realizar pruebas con todos los fabricantes, solo se necesita tiempo y medios...
Por otro lado, las conclusiones son cuestión de cada uno. Yo personalmente creo que hoy por hoy los fabricantes no se preocupan demasiado, aunque la responsabilidad es tanto de ellos como de los profesionales que los utilizan.
Publicar un comentario