Rogue Robots: Cómo volver maliciosos robots industriales (Parte 2 de 2)

Como habíamos terminado la parte anterior de este artículo dedicado a los Rogue Robtos, una vez descubierto el dispositivo podemos comenzar a buscar vulnerabilidades en la gestión del robot. En este caso práctico se encontraron fallos de acceso que permitían a un usuario (no administrador) leer la configuración y alguna que otra información sobre el dispositivo (este fallo de seguridad lo provocaba la versión del firmware  que no estaba actualizado).

Figura 1: Rogue Robots. Parte 2 de 2

Y por lo tanto, una vez conectado a través de la conexión GRPS del mismo, aprovecha otro tipo de vulnerabilidades. Estos son los problemas que se encontraron durante el análisis en este caso concreto.

Figura 10: Router por conexión móvil GPRS de la marca eWon (utilizado por ABB) conectado al robot

• Divulgación de la información y “huellas": es sencillo encontrar mucha información sobre el fabricante. Material técnico sensible (hardware y software) está disponible en Internet, incluido versiones de firmware. Por otro lado, los certificados se han reutilizado entre los diferentes productos e incluso alguno de ellos son autofirmados. Finalmente, las pantallas de acceso web (banners) ofrecen demasiada información como la dirección MAC, versión de firmware, modelo de CPU, etc.

• Componentes de software obsoletos: se encontraron muchos programas ejecutando versiones obsoletas. Esto es relativamente normal ya que, en algunos casos, los fabricantes crean parches exclusivos y así evitar problemas de compatibilidad con versiones antiguas. Por ejemplo, encontraron versiones 1.6 de Busybox, la cual ya ni siquiera está disponible para su descarga y que podrías intentar un tipo de ataque “Directory Trasversal” con inyección ZIP como explicamos en este blog hace unos días. También se localizaron compiladores GCC 3.3, Linux Kernel 2.4 o incluso librerías criptográficas obsoletas.

• Credenciales por defecto: se encontraron contraseñas en blanco por defecto, aunque parezca increible. También encontraron llaves privadas de cifrado OpenVPN en las imágenes de firmware disponible desde los sitios web de los fabricantes, así como funciones hash débiles que permitirían recuperar las credenciales de forma sencilla.

• Cifrado pobre de transporte (OWASP I4): por ejemplo, algunas páginas web no estaban utilizando el protocolo HTTPS.

• Interfaz web insegura (OWASP I1): se encontraron interfaces web que aceptaban peticiones GET directas sin ningún tipo de control.

• Por otro lado, algunas partes del código de dichas interfaces (casi todas en PHP) son Open Source que no se han actualizado.

• Protección insuficiente del software: debido a lo sencillo que es encontrar imágenes de firmware, es fácil encontrar versiones modificadas de dichos binarios con toda la información de dichos cambios (debug). Se utilizó la herramienta Binwalk para analizar las imágenes de firmware.

Figura 11: Binwalk en GitHub

El ordenador principal del robot es el punto más sensible de todos, ya que es el dispositivo que expone muchos servicios a la red. Un acceso no autorizado a este ordenador permitiría acceso total al controlador y de esa forma tomar control total del robot.

Figura 12: Conexión al robot para acceder a los logs de las conexiones vía el servicio de APN.

Estas son algunas de las vulnerabilidades que se encontraron en este dispositivo:

• Vulnerabilidad 1: Red no securizada e inyección de comandos (ABBVU-DMRO-124642): un atacante con acceso lectura y escritura a un sistema de ficheros FTP podría utilizar los servicios de red directamente para controlar las acciones del robot.

• Vulnerabilidad 2:  Autenticación débil (ABBVU-DMRO-124644): un atacante podría saltar el User Authentication System (UAS) debido a varios problemas de implementación como tener deshabilitada la autenticación durante el arranque del sistema, utilizar un usuario sin contraseña que no se puede cambiar o eliminar y la utilización de un usuario que viene con credenciales que no pueden cambiarse de ninguna manera.

• Vulnerabilidad 3: Criptografía débil: un atacante con acceso de sólo lectura a un sistema de ficheros podría cambiar la configuración UAS, cambiando los privilegios de las cuentas existentes y cambiar o incluso recuperar todas las contraseñas de usuario. 

• Vulnerabilidad 4: Corrupción de Memoria (ABBVU-DMRO-124645, ABBVU-DMRO-128238): se encontró un error de memoria que se podría explotar (con un buffer overflow) que afectaba al código RobAPI. También se encontró un error de memoria en el ejecuta TpsStart.exe el cual se ejecuta durante el arranque, el cual permitiría realizar un ataque buffer overflow si puede modificar el nombre de un fichero de más de 512 bytes.

• Vulnerabilidad 5: Código no firmado: la imagen de arranque que descarga el ordenador principal no está firmada y puede ser fácilmente modificada por un atacante (ingeniería inversa).

• Vulnerabilidad 6: Aislamiento del entorno de ejecución insuficiente: se encontraron problemas en el SDK que viene con el programa FlexPendant.

Rogue Robots: Fases de un ataque

Una vez ya hemos analizado todos los problemas encontrados, reuniendo todas estas vulnerabilidades, estos son los pasos del ataque realizado:

Figura 13: Pasos para acceder al controlador a través de un servidor FTP

Fase 1: Ataque al controlador

Se supone que el atacante puede alcanzar el servidor de RobAPI o FTP sin conocer ninguna de las credenciales. Esta es la secuencia de ataque:

1. Acceso al ordenador principal: Se utilizaron las credenciales estáticas (genéricas) para acceder al FTP (se podría haber explotado también los errores de memoria encontrados en la RobAPI). 

2. Saltar la autenticación: La UAS fue deshabilitada y se provocó un reinicio completo del sistema. Para conseguirlo se invocó el comando uas_disable desde la shell del FTP y luego una la vulnerabilidad de ejecución de código (Error de memoria en la RobAPI). 3. Carga del payload. Con acceso FTP total sin credenciales, se deshabilitó la UAS utilizando unas DLL .NET propias. 

4. Acceso persistente: Se forzó otro reinicio desde la shell del FTP, lo que provocó que se autojecutara el código malicioso (payload) en las librerías DLL .NET. 

Fase 2: Ataque al robot

Esta es la fase crítica donde se finalmente toma el control del robot comprometiendo la producción y afectando a la seguridad de los operarios.

• Reducción de la eficacia del producto, Ataque 1. Manipulando los PID de cada articulación modificando los parámetros correctos por otros imprecisos daría lugar por ejemplo a una pieza terminada de forma incorrecta. En el caso del ejemplo se añadió una imprecisión de 2mm a los parámetros que recibía el robot, lo cual es suficiente para dañar la pieza de salida. Los parámetros del PID se almacenaban en un fichero de configuración específico en el sistema de ficheros del ordenador principal.

• Violación de seguridad, Ataque 4, problema de seguridad físico para el empleado. Se modificó el estado que indicaba que el motor estaba apagado o en modo manual cuando realmente estaba activado y en modo automático para engañar al operador. Para conseguir este ataque se aprovecharon de un fallo en el código del firmware, utilizando ingeniería inversa para encontrar las rutinas que implementan la interface de usuario. Se modificaron las cadenas de texto para mostrar la información falsa y se volvió a empaquetar el firmware con los datos cambiados. Utilizando el problema del salto de la autenticación en el FTP, se subió el firmware malicioso y se esperó hasta el siguiente reinicio para activarlo. 

• Integridad del robot, Ataque 2. Este tipo de ataque tiene como objetivo dañar físicamente el robot. En el caso que estamos   estudiando se explotó un bug de ejecución de código remoto en el ordenador principal, para conseguir el fichero con los parámetros de calibración y modificarlos (no se llevó a la práctica). A pesar de todos los cambios a dichos parámetros añadiendo y modificando los valores, no se detectó ningún control significativo de integridad de los mismos.

Como habéis podido observar, resulta casi increíble que unos sistemas tan críticos como este tipo de robots industriales tengan exactamente los mismos problemas de seguridad que podemos encontrar en otro tipo de entornos. La seguridad en las infraestructuras críticas y los sistemas industriales son un objetivo muy llamativo ya que tienen consecuencias que afectan al mundo real, y como hemos indicado al principio, puede afectar a la integridad de los seres humanos.

Autor: Fran Ramirez (@cyberhadesblog) escritor de libro "Microhistorias: anécdotas y curiosidades de la historia de la informática" e investigador en ElevenPaths.