¿Podría ser el Apagón Eléctrico de España un ciberataque?

Esta es la pregunta que más me han hecho desde que comenzó el apagón eléctrico de la historia de España. La respuesta no la sabremos hasta que los equipos que están investigando el incidente hayan podido analizar "Root Cause" del incidente, y para ello van a necesitar tiempo. Y lo más importante es recuperar la energía lo antes posible, que hay muchos sitios críticos donde la existencia de la energía puede salvar vidas.

Figura 1: ¿Podría ser el Apagón Eléctrico de España un ciberataque? 

Esta claro que el sistema eléctrico está basado en la tecnología, y que como tal se debe diseñar y gestionar cuando hablamos de ciberseguridad. Y no es nuevo, porque a lo largo de los años hemos visto ataques a centrales eléctricas, y hace un par de semanas se alertaba de que había repuntado el número de ciberataques a estas infraestructuras críticas en la Unión Europea también.

Figura 2: Alerta del repunte de ciberataques a centrales electricas en la Unión Europea

¿Podría haber sido un ciberataque? Pues no lo sabemos aún, y no seré yo el que vaya a especular sobre esto, pero es una de las posibilidades que podrían ser, por supuesto. Pero también podrían ser otras las causas que han producido esto, así que lo mejor es no especular y esperar a ver lo que los forenses que estén en el CSIRT ahora nos digan cuando tengan los datos.

Figura 3: "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad

y fortificación (2ª Edición) por Juan Francisco Bolivar en 0xWord. 

Al final, en el pasado hemos visto caídas de sistemas de Internet, de energía, de llamadas, de gas, y de casi cualquier suministro crítico por causas que puedan interrumpir el sistema que distribuyen la luz, el gas, las redes de telefonía o datos. Y ahora no sabemos más que puede ser cualquier de ellos.

Las causas posibles, os las podéis imaginar:

• Accidente: Un incendio, una inundación, una nevada, un volcán. De todo esto hemos vivido en los años recientes con Filomena, la Dana, el Volcán de La Palma, o los Incendios que nos han asolado durante mucho años parte de nuestro territorio. Estos suelen producir cortes locales, o puntuales, porque destrozan partes del sistema, pero no han solido ser nacionales porque no han tocado el corazón del sistema, y cuando se diseña un sistema crítico es necesario redundar las partes core que pueden discontinuar el sistema.

Pero puede ser de gran intensidad o tocar un punto clave. Durante la Dana, hubo que hacer un trabajo especial para reforzar los centros de llamadas del 112 que estaban saturados, y que fue una de las prioridades durante la crisis, ya que no podían atender tantas llamadas. Que se pudieran atender todas las llamadas de emergencia lo antes posible, y para eso hubo que re-enrutar comunicaciones a centros de respaldo en otras ubicaciones.

• Error informático / humano: Tampoco es la primera vez que pasa, y yo viví muy de cerca un caso con la red de telecomunicaciones en UK, cuando el problema fue un certificado digital expirado que no había sido renovado a tiempo. Fue un error informático, sí, producido por un error en la gestión del proveedor, cuando se supo bien la causa raíz, los analistas publicaron sus conclusiones.

Figura 4: El problema fue un certificado digital expirado

• Ataque Informático: Pues podría ser también, claro. El sistema bancario SWIFT ha sido atacado muchas veces, y ha producido la caída y parada de transacciones bancarias en diferentes instituciones y regiones. En el caso de centrales de energía, el caso más importante fue STUXNET (nuclear), pero no ha sido el único, aunque sí el más importante por ser el primer APT Nation-State lanzando con un objetivo de una infraestructura crítica. Pero este mes se ha alertado del repunte de ciberataques a centrales electricas en todo el mundo usando ransomware.

Figura 5: Extorsión de documentos robados por ransomware

Pero los ha habido mucho más cercanos en el tiempo .En el año 2023 se alertó del ataque al sector eléctrico de Dinamarca, donde más de dos docenas de centrales fueron afectadas en tres oleadas, lo que deja claro que fue un ataque coordinado y organizado contra una infraestructura crítica de un país.

Figura 6: Ciberataque dirigido al sector energético de Dinamarca en 2023

Ahora mismo no sabemos nada. Serán los expertos que estén analizando el caso los que tengan que dar las informaciones, así que todo son especulaciones, por lo que hay que evitar caer en asegurar nada, porque solo los que tengan los datos tienen la información. Lo que sí que está claro es que algo ha pasado en el sistema y hay que saber qué es para que no vuelva a pasar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Infraestructuras críticas y sistemas industriales: Auditorias de seguridad y fortificación (2ª Edición)

Como siempre os digo, cuando tenemos un nuevo libro en 0xWord es un día feliz para nosotros. Cuesta mucho sacar adelante este proyecto por culpa de la piratería, y el poder contaros que tenemos a la venta la 2º Edición del libro de "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad y fortificación" escrito por Juan Francisco Bolivar, nos llena de alegría.

Figura 1: "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad

y fortificación (2ª Edición) por Juan Francisco Bolivar en 0xWord. 

El libro, como os he dicho, lo ha escrito Juan Francisco Bolivar, que es Cybersecurity Expert en Roche, y lleva años en el mundo de la ciberseguridad, el hacking, los sistemas SCADA y las infraestructuras críticas. Así que tiene un amplio bagaje en nuestra profesión.

Figura 2: Contactar con Francisco Bolivar

Este libro lo ha escrito con el objetivo de que sea fácil entender qué son las infraestructuras críticas, cuáles sus protocolos, sus componentes y sus configuraciones, ya que esto es básico para entender cómo funciona un sistema tan complejo y fundamental como son estas infraestructuras críticas. Hay que tener presente que estas infraestructuras controlan los servicios básicos para todos los ciudadanos y sin los que su bienestar se vería comprometido. 

En este texto se explica el uso de dispositivos que actúan sobre el medio físico, pudiendo crear incidentes que trasciendan las barreras lógicas y actúen sobre el mundo físico, como los usados en Centrales Nucleares, Centrales Eléctricas, Sistemas de Gestión de Agua, Conducciones de Gas, Sistemas industriales de Industria 4.0...

Figura 3: "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad

y fortificación (2ª Edición) por Juan Francisco Bolivar en 0xWord. 

El objetivo al que apunta el libro, tal y como pone en la sinopsis, es para que los auditores de seguridad, los equipos de QA de Seguridad o pentesters, entiendan bien estos entornos y tecnologías.

Aprender a detectar los puntos de ataque más débiles de estos sistemas, como realizar un pentesting contra dispositivos como PLC’s, HMI o SCADA será la principal misión de este libro. Ayudar a aquellos que se inician en los dispositivos industriales a realizar sus primeros ataques a estos sistemas, partiendo del conocimiento de ataques a las redes TI, aplicados a redes OT.

Para que tengas el contenido completo, he subido a mi canal de Slideshare el índice del libro de "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad y fortificación (2ª Edición)" que tienes aquí

Figura 4: Índice del libro"Infraestructuras críticas y sistemas industriales:Auditorias de seguridad y fortificación (2ª Edición)escrito por Juan Francisco Bolivar en 0xWord. 

Así que, si quieres un libro para formarte en técnicas de pentesting específica para las Infraestructuras Críticas ya tienes este texto disponible para que te lo puedas comprar. Además, puedes usar tus Tempos de  MyPublicInbox.

Usar tus Tempos de MyPublicInbox 0xWord para adquirir este libro

Para terminar, te recuerdo que tendrás también 100 Tempos de MyPublicInbox por la compra de este libro de "Infraestructuras críticas y sistemas industriales: Auditorias de seguridad y fortificación" y que además, puedes pagar completa o parcialmente este libro con Tempos de MyPublicInbox. Aquí te explico cómo se hace. La idea es muy sencilla, hemos creado un Buzón Público de 0xWord en MyPublicInbox y tenemos disponible el módulo de transferencias de Tempos entre cuentas siempre que el destinatario sea un Perfil Público de la plataforma. Para que se puedan hacer estas transferencias, primero debe estar el Perfil Público destinatario de la transferencia en la Agenda.

Figura 5: Perfil de 0xWord en MyPublicInbox. Opción de "Añadir a  la Agenda".
https://MyPublicInbox.com/0xWord

Para dar de alta un Perfil Público en tu agenda, solo debes iniciar sesión en MyPublicInbox, y con la sesión iniciada ir a la web del perfil. En este caso, a la URL del perfil público de 0xWord en MyPublicInbox, - https://MyPublicInbox.com/0xWord - donde te aparecerá la opción de "Añadir a la agenda". Cuando acabe este proceso, podrás ir a la opción Agenda de tu buzón de correo en MyPublicInbox y deberías tener el Perfil Público de 0xWord allí.

Figura 6: Cuando lo agregues estará en tu agenda

Una vez que lo tengas en la agenda, ya será tan fácil como irte a tu perfil - se accede haciendo clic en la imagen redonda con tu foto en la parte superior - y entrar en la Zona de Transferencias. Desde allí seleccionas el Buzón Público de 0xWord, el número de Tempos que quieres transferir, y en el concepto debes poner que es para recibir un código descuento para usar en la tienda de 0xWord.

Figura 7: Zona de Transferencias en el Perfil de MyPublicInbox

No te preocupes por el texto concreto, porque los procesamos manualmente como los pedidos de se hacen en la tienda. 

Canjear 500 Tempos por un código descuento de 5 €

La última opción es bastante sencilla. Solo debes irte a la sección de Canjear Tempos -> Vales para Tiendas, y "Comprar" por 500 Tempos y código de 5 €. Es lo mismo que enviar la transferencia pero en un paquete de 500 Tempos y de forma totalmente automatizada, así que solo con que le des a comprar recibirás el código descuento y lo podrás utilizar en la tienda de 0xWord.com

Figura 8: Canjear Tempos por Códigos para libros de 0xWord

Así que, si quieres conseguir nuestros libros de Seguridad Informática & Hacking aprovechando los Tempos de MyPublicInbox podrás hacerlo de forma muy sencilla y mucho, mucho, mucho más barato. Y así apoyas este proyecto tan bonito que es 0xWord.com.

Ser escritor de libros de 0xWord

Además, todos lo que queráis convertiros en escritores y hacer un proyecto de libro con nosotros. Podéis también enviarnos vuestra propuesta a través del buzón de 0xWord en MyPublicInbox, y si sois Perfiles Públicos de la plataforma, podéis entrar en la sección de Mi Perfil -> Servicios para ti y solicitar más información sobre el proceso de escribir un libro en 0xWord.

Figura 9: Si eres un Perfil Público de MyPublicInbox

puede solicitar info para escribir un libro en 0xWord

Nuestro equipo se pondrá en contacto contigo y evaluará tu proyecto de publicación de libro. Ya sabes que principalmente de Seguridad Informática & Hacking, y puede ser técnico, súper-técnico, o divulgación, y si es una novela... podemos estudiarlo también.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

T-Pot: Una colmena de Honeypots para atraparlos a todos

Los Honeypots son una gran herramienta para un IDS (Intrusion Detection System), ya que nos ayuda a detectar y estudiar con antelación posibles ataques a nuestra infraestructura real. Todos los que hemos sido administradores de sistemas o estamos en el mundo de la seguridad hemos tenido que trabajar alguna vez con ellos de alguna u otra forma. Existen multitud de honeypots adaptados a funcionar simulando todo tipo de entornos.

Figura 1: T-Pot: Una colmena de Honeypots para atraparlos a todos

Por ejemplo, si necesitas un honeypot para monitoriza tu red de ordenadores, puedes elegir por ejemplo Cowrie (un fork de Kippo y uno de los más utilizados) y si necesitas monitorizar los ataques a una infraestructura industrial (ICS) puedes elegir, por ejemplo, Compot (ICS/SCADA).

Cada instalación de un Honeypot requiere configurarlo y adaptarlo para que parezca lo máximo posible un entorno real (una de las claves del éxito del Honeypot). Además, una vez hemos obtenido y recopilado todos los datos de los posibles ataques, será necesario procesarlos y analizarlos para sacar conclusiones sobre los mismos. Existen muchas herramientas que ayudan a este proceso, como por ejemplo Kippo-Graph (que funciona perfectamente con Cowrie).

T-Pot: Una colmena de Honeypots para atraparlos a todos

Pero existe una solución magnífica que nos permite tener varios Honeypots (incluidos los diseñados para simular ICS) dentro de una sola máquina virtual (o física, según sea necesario) y también nos permite visualizar la información de forma espectacular utilizando ELK.

Figura 2: Dashboard de T-Pot

T-Pot es una plataforma de Honeypots que tiene como base una distribución Linux Ubuntu Server 14.04.4 LTS. Esta plataforma incluye una gran variedad de honeypots ya preparados, configurados y listos para entrar en funcionamiento. Algunos de estos honeypots y herramientas que incluye son:

• Conpot: es un honeypot para ICS el cual permite simular un entorno industrial completo, capaz de hacer ver al atacante de que está accediendo a un entorno industrial. 

• Cowrie: es un honeypot que simula un servidor con SSH y Telnet diseñado para monitorizar los ataques de acceso, así como la iteración con la Shell. 

• Dionaea: otro honeypot de caracter general diseñado para simular vulnerabilidades de red y servicios como SMB, http, FTP, MSSQL e incluso VoIP. 

• Elasticpot: es un honeypot basado en una versión simplificada de ElasticSearch. 

• EMobility: otro honeypot de infraestructuras ICS que simula un centro de carga eléctrica de vehículos (incluso simula usuarios que están cargando los vehículos).

Tiene una web central de gestión desde la cual el posible atacante tendría acceso a todos los nodos de carga de la falsa infraestructura.

• Glastopf: es un honeypot orietando a aplicaciones web como, por ejemplo, webmail, wikis, etc, cualquier aplicación en la que el cliente la ejecute desde su navegador web. 

• Honeytrap: este honeypot se centra especialmente en observar ataques contra servicios TCP y UDP. 

• Suricata: un monitor de seguridad de red para detectar intrusiones en tiempo real inspeccionando el tráfico de red. 

• ELK: son tres herramientas en una, Elasticsearch (servidor de búsquedas), Logstash (administración de logs) y Kibana (visualización y gestión de los datos almacenados).

La gran ventaja de esta distribución T-Pot es que los integra todo es una misma instalación (en el mismo servidor) y todos virtualizados con Docker. Esto permite tener en ejecución varios demonios actuando sobre la misma tarjeta de red sin problemas. Además, al tener cada Honeypot su entorno dockerizado, es muy sencillo su mantenimiento (actualizaciones, por ejemplo), gestión y personalización.

Figura 3: Arquitectura de T-Pot

Los puertos que serán utilizados por los Honeypot instalados en T-Pot tendremos que redireccionarlos hacia el Honeypot desde nuestro firewall o router si fuera necesario:

Figura 4: Lista de puertos a utilizar por los diferentes servicios

La instalación de T-Pot es bastante sencilla, simplemente se puede descargar la imagen ISO y montarla en un sistema virtual o uno físico. También crear la imagen ISO desde este enlace.

Figura 5: Arranque de la ISO de T-Pot

Las recomendaciones de hardware varían en función de si quieres activar todos los Honeypots y herramientas. En esta captura puedes ver las diferentes opciones que aparecerán durante el proceso de instalación. En nuestro caso hemos optado por la opción “E” (todo) en una máquina virtual:

Figura 6: Opciones para elegir tipo de instalación

Durante el proceso de instalación (el equipo se reiniciará dos veces) no se realizan apenas preguntas más allá de la configuración del teclado y el usuario y contraseña para el acceso vía web al panel del control (el usuario para acceder al servidor Linux con T-Pot es “tsec” y la contraseña “tsec”):

Figura 7: Datos de inicio de sesión en T-Pot con el usuario "tsec"

Para acceder al Honeypot de forma segura tendremos que hacerlo desde SSH. Desde Windows podemos utilizar OpenSSH y Putty como puedes ver en este video. Desde Linux o macOS podemos abrir un terminal y ejecutar:

ssh -p 64295 -l tsec -N -L8080:127.0.0.1:64296 192.168.56.100

Ya solo tenemos que abrir el navegador utilizando http://127.0.0.1:64296

Figura 8: Dashboard de T-Pot en la primera ejecución con todos los marcadores a cero

Para comprobar el estado de los contenedores Docker podemos utilizar el plugin ya instalado “UI-For-Docker” el cual nos permite de forma fácil, controlar todos los parámetros de los contenedores como reiniciarlos, pararlos, configuración de red, puertos, etcétera:

Figura 9: Control de todos los contenedores Docker desde T-Pot, "UI-For-Docker"

Para ver el funcionamiento de T-Pot y también como organiza y muestra los resultados, vamos a realizar simular algunos intentos de acceso desde la red interna donde hemos ubicado el Honeypot (no está conectado a Internet para esta demostración) utilizando Kali Linux 2. Antes de continuar es importante decir que toda la información contenida en los Honeypot (contenedores Docker) se pierde cada vez que la aplicación falla o se produce un reinicio del servidor. Es posible activar la persistencia de esta información accediendo a la carpeta /etc/systemd y ajustar los parámetros individualmente de cada servicio para que mantenga la información.

Figura 10: Ficheros con todos los servicios de cada Honeypot para su configuración individual

Vamos a realizar un ataque por fuerza bruta utilizando Metasploit, en concreto utilizaremos el módulo ssh_login. De esta forma veremos cómo es la estructura del Honeypot una vez se ha conseguido acceso (Cowrie). Posteriormente accederemos al dashboard de T-Pot para ver cómo ha registrado el ataque:

Figura 11: Metasploit utilizando el módulo ssh_login

Figura 12: Acceso por SSH al falso servidor para ver su estructura

En el siguiente vídeo muestra la información que ha recopilado T-Pot en su Dashboard después de nuestro acceso. Hemos omitido algunos paneles que no tienen información como por ejemplo la ubicación geográfica (en este enlace puedes ver cómo sería un ejemplo real de T-Pot):

Figura 13: Dashboard de T-Pot después del ataque y los datos registrados

Para probar los Honeypot orientados a ICS, vamos a realizar un acceso al Honeypot Conpot. Este Honeypot simula un contador de consumo eléctrico modelo Kamstrup 382 con conexión Telnet y sin contraseña de acceso.

Figura 14: Acceso al honeypot Conpot (simulando un Kamstrup 382) desde Telnet

Otro ejemplo sería la web del Honeypot eMobility, que simula centros de carga para vehículos eléctricos (sólo tendríamos que poner la IP del Honeypot con el puerto 8080):

Figura 15: Acceso al Honeypot eMobility

Los Honeypot en entornos ICS y IoT (hay que empezar a crear honeypots que simulen el hardware de los ordenadores de placa simple como Raspberry Pi por ejemplo) son una herramienta imprescindible para las instalaciones industriales. En este enlace encontraréis una estupenda selección de recursos para Honeypot que podríamos añadir añadir a T-Pot. Seguro que volveremos a hablar pronto de los Honeypot como parte de la Seguridad de los sistemas de control industriales y las infraestructuras críticas.

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

Qué fácil es ver las flaquezas de seguridad de algunos ICS (Sistemas de Control Industrial)

En los últimos años, la seguridad informática ha adquirido una gran relevancia, y no hace falta que lo jure, ¡por algo estáis en el lado del mal! Todos los sectores están haciendo lo que pueden para protegerse de los ciberataques; sin embargo, en algunas partes de los sectores industriales hay quién se está quedando por detrás, y para entender por qué hay que remontar al año 2000. En aquellos años Internet no traía grandes beneficios aún a muchos sectores, por lo que las redes de los Sistemas de Control Industrial (ICS, por sus siglas en inglés) eran locales, lo que hacía que fueran vulnerables solo ante un ataque realizado por alguien que estuviera físicamente en el entorno.

Figura 1: Qué fácil es ver las flaquezas de seguridad de algunos ICS (Sistemas de Control Industrial)

Con el auge de Internet estos últimos años, ha surgido la llamada Industria 4.0, que define un modelo híperconectado para ofrecer servicios de inmediato en cualquier parte del mundo, y son numerosas las empresas que se han sumado a esta innovadora tendencia. Pero la mayoría al conectarse, han mantenido sus ICS tal y como las tenían antes de conectarse por lo que se están descubriendo más y más vulnerabilidades cada año. Y eso era, y es, un problema.

Figura 2: Vulnerabilidades descubiertas en sistemas ICS del año 1997 al 2015

Tenemos la suerte, aunque en parte desgracia, y ahora explicaré por qué, de que en la Ley PIC (protección de infraestructuras críticas, 8/2011 de 28 de abril) se establecieran unas medidas de seguridad obligatorias para las infraestructuras críticas de España, las cuales están controladas por ICS, así que hay que protegerlas con todo lo que se pueda. Ahora bien, antes he dicho que en parte era una desgracia, y esto es porque infraestructuras críticas solo son aquellas que son indispensables para la población y que si se pararan no podríamos cubrir.

Figura 3: Ley de Protección de Infraestructuras Críticas en España

Pero la ley solo cubre a las infraestructuras críticas e Internet es un lugar muy vasto. Una vez que conectamos las industria a la red, cualquiera puede hacer un poco de Hacking con Buscadores utilizando el buscador de dispositivos de Shodan, y, ¿podéis adivinar qué se puede encontrar? Efectivamente, los ICS vulnerables. Y lo mejor es que son tan buscados que Shodan ya tiene un apartado para ellos.

Figura 4: Buscador de ICSs en Shodan

Lo curioso de Shodan es que además puedes buscar protocolos y puertos abiertos, que son una vía de entrada al sistema que está al otro lado. Y rebuscando un poco entre los protocolos más comunes de ICS, como Modbus o DNP3, podemos encontrar bastantes ICS vulnerables, y lo más preocupante es que no hay que tener mucho conocimiento previo para penetrar en una red en la que puedes provocar un desastre gordo como una inundación al abrir las compuertas de una presa o fastidiar la fabricación de algún producto que luego cause daños y pérdidas de dinero.

Figura 5: Contraseñas en los resultados de los productos

Además, como podéis observar en la Figura 5 tras buscar un poco se empiezan a encontrar las contraseñas de servidores a la vista sin protección alguna - ¿Será algún Honey Pot? -. Y no penséis que es un solo caso específico, hay por lo menos cientos de ICS que o tienen la contraseña a plena vista o usan las contraseñas por defecto (investigadores rusos de SCADA StrangeLove listaron más de 100 productos SCADA, los utilizados por los ICS, y sus contraseñas por defecto, que no son cambiadas en muchos casos), o, mucho más peligroso aún, no requieren de credenciales para entrar.

Figura 6: SCADAPASS

En la Figura 7, por ejemplo, se ha entrado sin que pidieran credenciales, y nosotros que somos aficionados a la seguridad no hacemos nada con ello, solo informamos, pero la posibilidad de que un ciberdelincuente entre es muy alta, y estando sin credenciales, establecer unas nuevas y dejar fuera a los verdaderos dueños es un paso muy sencillo, tan solo hay que navegar un poco por el portal.

Figura 7: Sistemas de control ICS sin passwords publicados en Internet

Que los sistemas SCADA de los que dependen nuestras industrias sean tan vulnerables parece una situación de ficción; y lo que parece más ficción todavía es que su seguridad no sea obligatoria por ley. Ya va siendo hora de que los gobiernos tomen medidas, y que posiblemente hagan que la ley PIC no abarque solo a infraestructuras críticas, porque, como ya habéis visto, entrar en ICS y hacer estropicios gordos es tan sencillo como mirar y rebuscar un poco en Shodan. Os recomiendo la lectura del libro de Infraestructuas Críticas & Sistemas de Control Industrial: Auditorías de Seguridad y Fortificación para conocer mucho más de este tema.

Autor: Jorge "Junior" de la Morena (Intership at ElevenPaths)

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.

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

Ahora que todo el mundo está hablando de los robots y el impacto (negativo o positivo, según se mire) que tendrán en nuestra sociedad, y viendo su crecimiento expansivo, tanto ayer, como hoy, es un buen momento para comenzar a analizar la seguridad de estos Sistemas de Control Industrial (ICS).

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

No es necesario explicar la tremenda gravedad de no asegurar correctamente estos sistemas los cuales pueden afectar al proceso de fabricación de elementos críticos (aparatos médicos o componentes de coches como los frenos, por ejemplo) o incluso a la seguridad física de las personas que trabajan en la misma fábrica (¿será ya la hora de aplicar las Tres leyes de Asimov? Aunque ya sabemos que tienen fallos). Esto sin contar que las fábricas son instalaciones críticas para cualquier nación, convirtiendo este sector en otro objetivo en una situación de ciberguerra. 

Figura 2: Las famosas "Tres leyes de la robótica" de Asimov

Aunque las vulnerabilidades en robots industriales son conocidas, no existen muchos estudios que analicen en profundidad esta temática. Un primer paso para comenzar a tener una visión más amplia de esta problemática lo han dado investigadores de la Universidad Politécnica de Milán y la empresa de Trend Micro, realizando una investigación exhaustiva sobre la seguridad de los robots industriales y los resultados no son nada alentadores. En el siguiente vídeo explican qué se podría hacer con un "Rogue Robot" que hubiera sido comprometido y  convertido en malicioso.

Figura 3: "Rogue Robots"

Básicamente han estado haciendo "Hacking con buscadores" utilizando Shodan, ZoomEye y Censys buscando robots de las marcas más conocidas del sector. Al igual que ocurre con muchos otros sistemas industriales - en el libro “Infraestructuras Críticas y Sistemas Industriales: Auditorías de Seguridad y Fortificación” encontrarás mucha información sobre la seguridad de este tipo de sistemas -, han localizado robots utilizando direcciones IP públicas, contraseñas de acceso por defecto, software obsoleto - por ejemplo versiones Linux 2.6 ó .NET SDK 3.5 con vulnerabilidades conocidas - o incluso han llegado a acceder sin que el sistema solicitara contraseña alguna. Y estamos hablando de robots de marcas tan conocidas como Mitsubishi o Kawasaki. 

Para comprender el impacto real de los problemas de seguridad en este tipo de instalaciones, es necesario tener clara la arquitectura industrial de los ICS:

• Robot: este componente es el más fácil de reconocer ya que habitualmente tiene forma de brazo humano y es capaz de moverse en tres o más ejes. Puede estar fijo en una posición o también puede desplazarse (móvil). Puede realizar mucho tipo de tareas desde coger objetos, doblar materiales o incluso manipular otros dispositivos como por ejemplo un láser.

• Controlador: está compuesto de múltiples subsistemas informáticos complejos interconectados entre sí para recibir información del exterior y de esa forma tomar decisiones. Es básicamente el cerebro del robot y puede operar de forma automática (tarea programada) o manual (es el operador quien controla el robot habitualmente usando un joystick). 

• Interface Robot-Humano: generalmente existe un dispositivo llamado “teach pendant” el cual se conecta directamente utilizando un cable o vía wireless. En esta consola de mandos está el teclado o incluso el joystick mencionado antes para controlar el robot. Se utiliza tanto para programar el robot como para su monitorización.

• Programación del robot: los programas suelen estar escritos en un entorno desarrollado por el propio fabricante. Se puede programar utilizando el joystick o utilizando secuencias de comandos desde un simulador interno. Estos programas se almacenarán en la memoria del controlador.

Figura 4: Arquitectura de un robot industrial

Es importante destacar también que todos estos robots suelen estar conectados a Internet a través de routers industriales de marcas como: Robustel, inHand o Digi. La conexión entre dichos robots se realiza básicamente para tareas de mantenimiento y monitorización. Esta conexión se lleva a cabo utilizando directamente Internet, una conexión VPN o incluso por GPRS usando APNs propias de los fabricantes.  

Figura 5: Ejemplos de routers industriales de las marcas Robustel, InHad y Digi

Una vez tenemos una visión de la arquitectura y el entorno de estos sistemas, podemos comenzar a estudiar algunos ejemplos de ataques. El primer paso será necesario entender un poco funcionamiento de estos robots. Es bastante fácil encontrar por Internet documentación, manuales e incluso ficheros ejecutables del controlador (podríamos aplicar técnicas de ingeniería inversa) o también ficheros de firmware o actualizaciones.

Ataques a Robots Industriales

Por otro lado, es importante distinguir entre ataques de red y ataques físicos. En el ataque de red sólo puede haber comunicación con el robot a través de una conexión de red. Aunque el robot no esté conectado directamente a Internet, suelen estar conectados a una LAN la cual puede a su vez tener fallos de configuración o incluso vulnerabilidades - por ejemplo, atacando un ordenador de algún usuario en esa misma LAN pero con conexión a Internet -.

En cambio, el atacante físico suele ser alguien con acceso directo al robot, como por ejemplo el mismo operador, pero también puede ser personal externo como técnicos de mantenimiento. El acceso físico es más peligroso ya que garantiza un acceso total al controlador del robot utilizando cualquier de los puertos de I/O habituales (aunque algunas conexiones son propias de los mismos fabricantes).

Figura 6: Rogue Robots: Testing the limits of an Industrial Robot´s Security (PDF)

Los diferentes ataques que se pueden realizar a estos sistemas son los siguientes (aquí están resumidos, en el paper original puedes verlos más en detalle):

• Ataque 1: alterar los parámetros de control de movimiento. Este es quizás el ataque más llamativo ya que puede violar todas las normas de seguridad física al alterar de forma aleatoria e incluso violenta los movimientos del brazo robot, pudiendo dañar material, al mismo robot o incluso a personas. Este ataque podría ser utilizado en caso de tener como objetivo dañar o modificar el producto que se está fabricando.

• Ataque 2: manipulación de los parámetros de calibración. Este ataque es parecido al anterior, pero se centra específicamente en modificar los datos de calibración almacenados en el equipo. Estos datos son utilizados por el controlador para corregir posibles errores de medida cuando los servomotores están funcionando. Una mínima variación de estos valores podría destruir el objeto que se está fabricando o dejarlo inservible. Los efectos de este tipo de ataque son los mismos que en el tipo de ataque número 1.

• Ataque 3: manipulación de la lógica interna del producto. En este caso el atacante manipula el programa que se está ejecutando en el robot cambiando internamente su funcionamiento. El objetivo es dañar, modificar o alterar el producto que se está fabricando en la línea de montaje.

• Ataque 4: alteración de los interfaces de estado del robot. El robot tiene que informar continuamente sobre el estado de, por ejemplo, sus motores. Esta información es visualizada en interfaces las cuales podrían ser vulnerables a ataques que modificaran la forma en la que muestran dicha información. Aunque un testigo o un panel indicara que los motores están parados, estos podrían seguir en funcionamiento.

• Ataque 5: alteración de los estados del robot. En este tipo de ataque el objetivo son directamente los estados en vez de las interfaces. Por ejemplo, un atacante podría cambiar el modo manual a automático y viceversa, ya que normalmente el cambio de este estado se realiza por software en vez de utilizar un interruptor mecánico.

Ahora que ya tenemos algunos tipos de ataques posibles, pasamos a describir una demostración real de ataque.

PoC: Análisis de seguridad de un brazo robot

El objetivo será el brazo robot ABB de seis ejes IRB140, capaz de manipular hasta 6kg de peso. Viene equipado con un controlador bastante común modelo IRC5 y ejecuta el software RobotWare 5.13.10371 y FlexPendant (sistema basado en Windows CE). Este robot debería operar dentro de una jaula para evitar posibles accidentes con otros trabajadores humanos.

Figura 7: Brazo Robot ABB IRB140

Y ahora viene una de las partes que más nos interesa, los puntos de entrada. Para localizar en Internet modelos como el ABB IRB140, se ha utilizado en concreto Shodan - el cual ya hemos visto varias veces en otras pruebas de sistemas industriales -. En el caso práctico de este estudio, se realizado una búsqueda con estos parámetros “Server: eWON¨.

Figura 8: Ejemplo de búsqueda en Shodan de dispositivos eWon

eWON corresponde a la etiqueta que aparece en los servidores web embebidos correspondientes a la marca ABB. Para hacer una búsqueda más precisa podríamos poner el nombre de la empresa fabricante dentro del campo “Basic realm” para comprobar la cabecera de la respuesta HTTP. Una vez descubierto el dispositivo podemos comenzar a buscar vulnerabilidades, pero esto queda para la siguiente parte de este artículo. Vamos, que hacemos un Cliffhanger en toda regla.

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