jueves, 1 de mayo de 2014

Heartbleed puede desangrarte. Tómatelo en serio.

Aunque últimamente ando bastante falto de tiempo libre debido a la cantidad de proyectos que intento llevar en paralelo pero mi carácter curioso e impulsivo me la ha vuelto a jugar y me ha hecho perder un poco de tiempo jugando con un servidor. Por motivos que no vienen al caso, estaba yo echando un vistazo a la página web de alguien relacionado con mi trabajo, el de experto en sistemas de automatización industrial concretamente, que ya sabéis que es de lo que me gusta hablar a mí en mis artículos, pero me topé con un bug de HeartBleed en un puerto menos habitual y he querido hacer este artículo para enfatizar estas cosas:
1.- HeartBleed puede estar en cualquier parte
2.- Es muy fácil de explotar
3.- Cambia las passwords
4.- Pon un segundo factor de autenticación a tus cuentas.
Fase 1: Descubriendo la Vulnerabilidad de HeartBleed

Mientras leía la web y me interesaba por lo que allí había hice lo que cualquier persona normal -, lancé un nmap al servidor donde se aloja - vale, supongo que esto de normal encajaría solo dentro de los que estamos por estas comunidades y que no será tan normal en otros lares -. De entre todos los servicios y puertos que salieron en los resultados hubo uno de todos ellos que me llamó la atención.


Figura 1: Lanzando nmap contra el servidor


Era un servidor de Plesk 11.0.9, algo que no es que sea inhabitual, pero que abre siempre las puertas de poder encontrar algo interesante especialmente al estar alojado en un puerto menos habitual al escaneo, especialmente esos días que la vulnerabilidad de Heartbleed estaba en todo su esplendor.

Figura 2: Plugin de HeartBleed para FOCA


Como aún no había sacado Eleven Paths su plugin de HeartBleed para FOCA que puedes ver en la imagen superior, me fui a buscar cualquiera funcional en exploit-db, y use este en concreto. Lo lancé y esperé el resultado.


Continuar leyendo ...



domingo, 9 de marzo de 2014

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.


930 resultados en Shodan con PLCs conectados a Internet

jueves, 27 de febrero de 2014

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.

Continuar leyendo...


Protección contra escritura mediante comandos FINS en CS/CJ de Omron


Cada día son más habituales los escenarios donde la red corporativa de la empresa tiene como nodos algún que otro PLC. Personalmente no soy partidario de mezclar las redes de producción y de control, pero en ciertas ocasiones esto puede que sea inevitable.

Cuando nos vemos obligados a tener PLCs en la misma red lógica que otros equipos debemos de tomar todas las medidas posibles para evitar accesos no autorizados.

En el caso de PLCs Omron, una de una de las medidas a tomar es configurar la “Protección de escritura de comandos FINS”.

Tal como vemos en la imagen extraída directamente del manual, en los modelos CS/CJ cuya versión sea 2.0 o superior, podemos prohibir la operación de escritura y otras operaciones de edición enviadas a las CPU como comandos FINS a través de una red (Incluyendo operaciones de escritura de CX-Programmer, CX-Protocol,….).

También podemos observar que en las versiones de CPU anteriores a la 2.0 no existe esta funcionalidad.





Tal como podemos ver, se prohíben solamente los accesos de escritura, quedando permitidos los accesos de lectura, tanto de memoria como de programa. Esto puede ser interesante si nos interesa centralizar la recogida de datos de varios PLCs de la red, pero queremos evitar que los equipos encargados de recolectar los datos tengan permiso de escritura sobre los PLC.

La lista de comandos FINS que son restringidos por esta configuración es la siguiente según el manual de Omron.

Continuar leyendo...



viernes, 14 de febrero de 2014

Situación actual de la ciberseguridad en el mundo de la automatización industrial.


Si eres alguien relacionado con el mundo de la electricidad y electrónica seguramente conozcas el portal infoPlc. Es probablemente el portal mas importante del país dedicado a la automatización industrial.

Recientemente han publicado un artículo donde analizan el estado actual de la ciberseguridad en el ámbito de la automatización industrial y me han permitido opinar al respecto.








miércoles, 15 de enero de 2014

Ataque de fuerza bruta contra CX-Programmer.

Hace unas semanas tuve una intervención un tanto particular. Un cliente había adquirido una envolvedora para palets de segunda mano parecida a la de la imagen.



La envolvedora en cuestión estaba controlada mediante un PLC de la marca Omron, modelo CQM1-CPU43. Este PLC se estuvo comercializando en España desde 1992 hasta 1998 aproximadamente. Os podéis hacer una idea de la antigüedad de la máquina.

La intervención no encerraba mayor dificultad que la de hacer una puesta en marcha y posterior modificación de una máquina sin documentación alguna, y sin soporte porque el fabricante al parecer ya no existe. Todo apuntaba a que sería algo muy divertido, y lo fue.

Una vez realizadas acometidas eléctrica y neumática se solucionan algunos problemas de conexionado y un par de fugas de aire.
Me conecto al PLC y sorpresa, el PLC tiene contraseña. Contraseña que debió poner un fabricante que ya no existe.

Esto me hizo recordar mis primeros pasos en el mundo de la automatización industrial. En aquellos años este modelo de CPU ya estaba descatalogado, de echo era el momento de transición entre el CQM1H y el CJ1. Para este modelo de PLCs había software que realizaba un ataque de fuerza bruta... continuar leyendo.

sábado, 28 de diciembre de 2013

Cracking Almacén: Un keygen para un sistema de control.


Hoy os voy a contar la historia por la que la curiosidad, en lugar de matar al gato, me acabó llevando a terminar haciendo algo de ingeniería inversa al software de control de un almacén. La aventura comenzó cuando me topé con un sistema similar al que puede verse en la imagen siguiente:
Como se puede apreciar, se trata de un almacén automatizado compuesto por una serie de bandejas para guardar elementos varios, junto con un sistema de traslación que nos acerca la plataforma de trabajo a la zona deseada del almacén. La idea es que por medio de una buena catalogación de los elementos, el sistema los localiza de forma automática.

El manejo del sistema de almacenaje automatizado se hace completamente desde un terminal táctil que además está conectado a un software de gestión de almacén que permite controlar las entradas y salidas de elementos. Algo fundamental en almacenes de grandes empresas que tienen que controlar dónde está lo que guardan. El terminal táctil en cuestión es un equipo PC con una versión de Microsoft Windows CE como sistema operativo.

Para cambiar algunos de los parámetros de la configuración del sistema, el software de control tiene un sistema de seguridad que no deja entrar en el modo " Support " y remite directamente al servicio técnico del fabricante para solicitar un código temporal de acceso. Cuando se llama por teléfono al servicio técnico es necesario que indicar el código que aparece en pantalla, además de... continuar leyendo.