Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
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.
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.
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.
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.
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
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
6 comentarios:
Es todo correcto. Es que tiene que ser así.
Todo esto viene de como es el sector y como ha evolucionado. Por una parte el hardware (las marcas), por otro los clientes (empresas que emplean esta tecnología) y por otra (y la más importante) las empresas que programan PLC.
Cada uno ha evolucionado por su cuenta. La mayoría de los fabricantes de PLC están en el negocio porque venden tecnología industrial y sus clientes "les obligan" a tener en catálogo PLC. El que compra Siemens quiere todo de esa marca. Pero los fabricantes ni cortan ni pinchan absolutamente nada.
Los clientes cuando compran una máquina industrial le dicen al fabricante de la máquina la marca de PLC que quieren que se use y el soft se hace para esa marca en concreto. La máquina podría funcionar con casi cualquier fabricante de PLC pero cada empresa tiene una o varias marcas concretas y no quiere tener varias marcas desconocidas por optimización del mantenimiento. Por este motivo surgieron empresas de ingeniería dedicadas a programar PLC. Trabajaban para los clientes finales NO para los fabricantes de maquinaria ni PLC. Ni los fabricantes de PLC ni los fabricantes de maquinaria podían adaptarse y ofrecer programación.
Con los años los clientes finales empezaron a pedir a los fabricantes de los PLC soft que funcionase en ordenadores (hasta entonces se usaban maletas de programación y teclados)
Como esas empresas eran multinacionales prefierieron comprar el soft a ingenierías, o directamente comprar las ingenierías en sí y quedarse con el soft antes que estar años desarrollando su propio soft y gastando millones. Ese es el soft que estás utilizando. Las ingenierías no cobraban un céntimo por hacer más seguro el soft. Simplemente cobraban por programas que funcionasen. No iban a pasar horas de programación que no pagaría el cliente en sistemas de seguridad que luego veremos que eran innecesarias.
Los fabricantes de PLC tomaron otra precaución para mantener su negocio. Para programar había que estar conectado al PLC. Esto es, el hardware era la llave del soft que usaban en el ordenador. Así se garantizaban que pagabas por el programa que estabas utilizando y era legal. Podías copiar el soft de programación pero no podías usarlo si no tenías un PLC conectado al ordenador.
Por otra parte como el mantenimiento del programa lo hacía la ingeniería que lo hizo la contraseña de acceso era del programador. El PLC no tenía pantalla ni teclado, nadie podía hacer modificaciones sin el soft de programación.
Si fuese como tú dices (y ya fue así y por eso se cambió) La empresa que hacía la programación se negaba a dar los códigos de acceso al programa. Montaban la maquinaria y cuando había un fallo les decían a los clientes que llamasen a Italia cuando hubiese un problema. Conozco una empresa que lleva 20 años usando un programa que no sabe como funciona. Los italianos no cobraron por todo el trabajo, la empresa se negó a pagar. Pero tampoco saben como funciona el programa. Si falla no hay quien lo repare.
¿Lo entiendes ahora? Los piratas no son solo los de la $GAE.
Y si ya quieres ver el nivel del sector pásate por la página de Siemens y ves esto -> http://www.plm.automation.siemens.com/es_mx/about_us/piracy/index.shtml
Unas empresas que NO han gastado un céntimo en investigar. Que tienen soft comprado a terceros llaman piratas a los usuarios. A mí esto me suena.
Saludos
Muchas Gracias por la info!
Salu2!
Para que tapas las ips y dejas el paquete en hexadecimal sin tapar? Fail
Creo que deberías hablar con los organizadores de la RootedCON para dar una conferencia sobre esto en profundidad, he leído habitualmente tus artículos y son geniales, enhorabuena!!
Daniel Ferreira.
Felicidades por estos artículos tan interesantes, comentar que en los PLC Mitsubishi antiguos (año 2005) les sucedía lo mismo que con los Allen Bradley que describes, es más, en cierta ocasión tuve que recurrir a esta técnica para poder eliminar una parada oculta por fecha.
Soy especialista en PLC Allen Bradley y en mi opinión la seguridad se deja en mas de usuario final y de ellos depende que tan seguro quieren que su sistema sea en este caso que muetras los PLC estan conectados directamente a internet lo cual es un error grave, por otra parte si tienes una red empresarial y esta a su vez una red de control no podrías ver los dispositivos(PLC), puesto que primero debes de entrar a la red de la empresa y despues a la red de control.
saludos
Publicar un comentario