LogicLocker, un ransomware para ICS

Coincidiendo con la celebración de la RSA Security Conference en San Francisco, el pasado 14 de febrero los investigadores Raheem Beyah y David Fromby del Instituto de Tecnología de Georgia (GIT, Georgia Institute of Technology) anunciaron los resultados de una Prueba de Concepto (PoC, Proof of Concept) con la que demostraban cómo se podría llegar a actuar sobre un autómata de la misma manera que lo hace un ransomware tradicional. O dicho de otra manera, podríamos estar ante la primera señal de vida de ransomware para ICS.

captura_02

Las conclusiones de su investigación han quedado reflejadas en un documento que puede ser accedido públicamente desde aquí. Tras su lectura, en el día de hoy voy a hacer un repaso del mismo, haciendo un resumen de aquellos puntos e ideas más significativas con algún que otro aporte propio. Aunque, como veréis en algunos aspectos se repite “la misma canción”.

Los autores comienzan hablando de cómo los ICS (ICS, Industrial Control Systems) están presentes en aquellas infraestructuras que regulan nuestra vida diaria como puede ser el agua, la luz o la maquinaria en empresas manufactureras. Desde la aparición de Stuxnet o la caída de suministro eléctrico en Ucrania, los ataques contra este tipo de instalaciones estaban relacionadas con el sabotaje. No han sido objetivo de organizaciones criminales con una actividad orientada al chantaje o beneficio económico ilícito. ¿Por qué? No porque los Sistemas de Control Industrial sean más seguros, sino que no se había encontrado la manera de rentabilizar de modo alguno este tipo de actividades. En un entorno corporativo (IT) el mayor valor que tiene la organización es la información. La información se convierte en el objetivo. Sin embargo, esto no es así en entornos OT. El mayor valor que tiene los sistemas ICS no es la información que tienen de la compañía. El verdadero valor radica en garantizar la disponibilidad y seguridad (safety) de las instalaciones. Los programas de los autómatas, en sí mismos, no almacenan información tan relevante para la organización como lo pueden ser las Bases de Datos, Correos Electrónicos, ficheros con planes estratégicos de la compañía, etc. Sin embargo, si se compromete, bien por cifrado o alteración el programa del PLC, la instalación no funcionará tal y como ha sido diseñada afectando claramente a la actividad de la empresa. Y esto sí tiene un impacto económico. Sin olvidarnos además de que dicha modificación puede menoscabar la seguridad de las personas (Safety) y, dependiendo de la actividad, incluso daños ecológicos.

sick-safety-switches-800x500-2-770x450

Dispositivos y mecanismo Safety. Imagen extraída de: http://www.advantageind.com/portfolio/safety-switches-controllers-and-protection/

Según esto último, por su impacto en la economía de cualquier organización, las redes industriales serán, probablemente, el próximo objetivo de este tipo de malware. Mediante este documento, los autores afirman haber desarrollado el primer ransomware conocido para PLCs, el cual ha recibido el nombre de LogicLocker. En la PoC, LogicLocker emplea las comunicaciones nativas de la API de un equipo Schneider Modicom M241 para escanear los objetivos vulnerables, en este caso PLCs Allen Bradley Micrologix 1400 y Schneider Modicom M221. Pasada esta fase, los infecta saltando los débiles mecanismos de autenticación, impidiendo a usuarios legítimos la recuperación del dispositivo. Finalmente, se plantea reemplazar el programa original con una “bomba lógica” que provoque acciones sobre los equipos físicos, daños a personas, modificación de las salidas de los autómatas, o cualquier otra si no se realiza el pago en tiempo y forma.

Aquí, conviene resaltar el perfil del atacante. Se concluye que la sofisticación de un ataque es inversamente proporcional a la frecuencia de los ataques. Esto es, los ataques de personas sin conocimientos o perfiles técnicos que reutilizan un exploit conocido, superará a los llevados a cabo por criminales profesionales con unos niveles de preparación mucho mayor y con más probabilidades de éxito, daño y alcance.

Como es sabido, el ransomware busca una rentabilidad económica de la acción, siendo el rescate mayor cuanto mayor sea la indisposición de la información o,  en el caso que nos ocupa, el impacto económico que tiene la pérdida de disponibilidad de las instalaciones.

Beneficio  = Alcance * Valor – Coste de desarrollo

Por tanto, para que un ataque dirigido a ICS sea rentable y dado que un PLC en sí mismo no almacena una información relevante, la meta es  provocar el mayor impacto sobre la operativa de las instalaciones. En esta línea, el ransomware para ICS busca afectar sobre:

Inactividad

Dependiendo de la actividad empresarial de la víctima una caída de sus sistemas de control puede tener un mayor o menor impacto. Imaginemos un fábrica de automóviles donde cada 2 – 3 minutos puede estar finalizado uno o incluso la elaboración de productos de alimenticios donde la materia prima es perecedera y que pueda darse el caso que los sistemas de refrigeración o mezcla de compuestos dejen de funcionar.

Equipamiento

Una de las características de las redes de control es la interacción con elementos físicos, con lo que cualquier manipulación o daño, como norma general, será claramente visible. Cobra especial importancia que la sustitución de estos equipos puede llegar a ser muy complicada, tanto por el reemplazo en sí como por el suministro. Pensemos en un grupo electrógeno para dar servicio en caso de caída de una línea eléctrica, y pasar a  generarla mediante combustible. Pueden pasar meses hasta que se reciba uno si el fabricante no tiene uno en stock.

Personas

En este caso el objetivo son las personas y no los dispositivos. Cuando lo que está en juego son vidas humanas, el interés y la cuantía a pagar siempre será mucho mayor. Esta es una de las lecciones aprendidas de las campañas de ransomware tradicional dirigido sobre Hospitales y Centros de salud.

portada_estudio_01

Para poder ver el efecto de LogicLocker, en cuanto a equipos se refiere, se establecieron dos líneas de trabajo. Por un lado se realizaron búsquedas con Shodan para localizar equipos vulnerables (miles según afirman) y por otro los equipos sobre los cuales se hizo la prueba de concepto. Los equipos en cuestión fueron un Schneider Modicom M221, un Allen Bradley Micrologix 1400 and Schneider Modicom M241. Para tener una idea del beneficio que pudiera darse, mediante Shodan se localizaron un total de 1400 unidades del equipo Micrologix 1400. Si éstas estuvieran en entornos donde se vieran afectadas vidas humanas (siendo más que asegurado el pago), y se solicitaría un rescate de 15.000 € por unidad, el atacante podría obtener un beneficio de 21 millones de euros en un sola operación.

En lo que se refiere a la simluación y anatomía del ataque, el mismo estaría comprendido en 4 fases:

  1. Infección inicial
  2. Movimiento lateral (opcional)
  3. Bloqueo
  4. Cifrado
  5. Negociación del rescate.

La infección inicial puede llevarse a cabo mediante el acceso remoto si el equipo está expuesto en internet o bien mediante el compromiso de otro sistema dentro de la organización y una vez dentro, lanzar el ataque contra alguno de los PLCs. Para comprometerlos, es ampliamente conocido que muchos de éstos no proporcionan medios de autenticación robusto para la carga de nuevos programas. En el mejor de los casos puede deshabilitarse la administración remota, en ese aspecto.

En lo referente al movimiento lateral, el objetivo es comprometer tantos equipos como sea posible. De esta manera el atacante aseguraría un mayor éxito no sólo por la cuantía sino por la certeza del pago. Si solamente se comprometiese uno, sería fácil su sustitución siempre y cuando se tenga el programa correspondiente. Si el compromiso es de varios, ya la posibilidad se ve reducida con lo que al estudiar el impacto que pudiera tener, se optaría por el pago y restaurar la disponibilidad tan pronto como sea posible.

En cuanto al bloqueo del PLC, existen varias opciones. La más sencilla, si dispone de ella, es la configuración de una contraseña de acceso lo más compleja posible. Sin embargo la contraseña de autenticación de muchos PLCs solamente es comprobada en el software del entorno de programación, no en el PLC. Así pues, este mecanismo destinado a la protección el PLC “victima” en realidad impide la recuperación por usuario legítimo no siendo una verdadera protección contra el atacante una vez haya sido comprometido. Sin embargo, como decíamos al principio, si la autenticación se produce del lado del PLC (es éste quién la solicita y no el software al abrir el proyecto) y quisiéramos encontrarla mediante un proceso de autenticación online por fuerza bruta, resultaría inviable debido a la gran cantidad de tiempo necesario aun cuando posea una longitud, de tan sólo, 6 dígitos. Ya por último, se plantea la idea del bloqueo mediante el número de conexiones TCP activas. Algunos PLC tienen un número máximo de ellas, por tanto, el atacante podría hacer uso de todas ellas según el medio elegido.

Incluso si la víctima pudiera recuperar el acceso para reprogramar el PLC, saltandose así las técnicas de bloqueo llevadas a cabo por el atacante, éste podría llevar a cabo otras teniendo en cuenta el cifrado el programa. La más sencilla es cifrar el original por parte del atacante y enviárselo al usuario legítimo. Una vez efectuado el pago, el atacante le facilitaría la herramienta con la que descifrar el programa y poderlo carga de nuevo sobre el PLC. Una segunda que se plantea es, nuevamente el cifrado del programa, pero esta vez almacenarlo en una zona de memoria del PLC. Sin embargo, esto puede no ser viable debido a que algunos PLCs no poseen cantidad suficiente como para ser guardado allí. Finalmente se plantea el tercero de los casos, en lo que estudia la posibilidad de codificar el propio programa en el PLC estableciendo una llave secreta de tal manera que de forma aleatoria se fuera cambiando el contenido del programa. La idea es llevar a cabo una serie de acciones sobre el programa original teniendo como variable dicha “llave secreta” para luego, una vez efectuado el pago, poder revertir el proceso en sentido contrario. No obstante, se corre el riesgo de poder desencadenar un funcionamiento impredecible, así como la nula capacidad para recuperar el programa original.

Como último paso nos quedaría la negociación para el pago del rescate. La forma más sencilla es el envío de un correo electrónico solicitando a la víctima el pago correspondiente aunque, también puede hacerse uso de los clientes de correo electrónico que tienen algunos dispositivos para el envío de alertas a los operadores, dando así una sensación de fortaleza y control mayor. Para reforzar esta idea, pueden verterse amenazas de destrucción del equipamiento conectado mediante la alteración de las instrucciones, a partir de una identificación previa.

Dicho lo cual, llega la hora de explicar cómo se ha llevado a cabo dicha prueba de concepto. Se parte de la idea en la que un atacante ha sido capaz de obtener la contraseña de acceso del equipo Modicon M241, bien por fuerza bruta o por el robo de las credenciales. Con ellas, LogicLocker procede a escanear la red para localizar más equipos vulnerables e infectarlos más adelante. En esa acción procede al bloqueo de Modicom M221 y Micrologix 1400 reprogramándolos con nuevas contraseñas impidiendo el acceso a usuarios legítimos con el software de programación. Para la fase de cifrado se procede a cifrar el programa original y notificar a la víctima mediante el envío de un correo electrónico. Una vez realizado el pago, el atacante enviará un software con el que podrá obtener el programa original, pero en caso contrario, modificará el comportamiento de los PLC para verter cantidad excesivas de cloro dentro del suministro de agua.

Ya en la parte final se establecen las medidas para defenderse y prevenir este tipo de ataques. Obviamente una estrategia “Air-gap” ya no es sinónimo de seguridad sino que se debe apostar por una basada en “Defensa en Profundidad”. Aquí es donde me refería con mi apunte que se repite “la misma canción”.

En el documento se cita a 3 líneas:

  1. Seguridad de Endpoint
  2. Seguridad de red
  3. Políticas

En cuanto a la primera de ellas se habla de medidas tales como cambiar contraseñas por defecto, deshabilitar servicios que no están en uso, emplear ACLs, y otras tantas a las que ya estamos acostumbrados. Pero sobre todo considerar característica de seguridad en lo nuevos productos que se adquieran. Algunos artículos escritos al respecto:

La seguridad en la red resulta indispensable. Se hace hincapié en la separación de los entornos tanto IT como OT realizando un control de los protocolos en el firewall que los separa. Puesto que cualquier cambio en entornos de control ha de realizarse de forma programada y son poco habituales, dicha monitorización facilitará la detección de anomalías en la red. Al margen de ello resulta indispensable disponer de un sistema de backups para restaurar las configuraciones y no tener pagar rescate alguno.

Por último, llegamos a las Políticas. Aquí el objetivo son los usuarios finales, quienes deben estar formados sobre los riesgos que pueden acarrear sus acciones. Además, los entornos de control y automatización no sólo deben disponer de un plan de contingencia ante posibles incidentes sino llevar a cabo también tareas de recuperación en un entorno controlado. Ni qué hablar sobre la implicación de la directiva, equipos de trabajo multidisciplinares y creación de nuevos Roles dentro de la organización.

Así llegamos a un apartado donde se detallan las conclusiones finales. Las redes industriales no han sido objeto de ataques de ransomware ya que los cibercriminales no han encontrado el modelo para obtener un beneficio económico de sus acciones. Con la llegada de este malware que afecta, no a equipos con una arquitectura basada en PC sino a dispositivos de control, se abre una nueva línea; la extorsión. Los recientes ataques a hospitales demuestran lo rentable que puede llegar a ser este malware cuando lo que está en juego son vidas o consecuencias sobre personas. A esto hay que sumar lo débiles, o poco prácticas, que pueden llegar a ser las medidas de autenticación existentes frente a este tipo de ataques. Por tanto resulta inevitable el despliegue de una estrategia de “Defensa en Profundidad” que contemple a la seguridad desde el inicio, y en aquellas ya existentes la toma de medidas que prevengan cualquier actuación hostil que ponga en peligro la disponibilidad de las instalaciones y las vidas humanas.

En cualquier caso, para ataques o accidentes, la creación de un sistema de copias de respaldo tanto de configuraciones, software o firmware debe ocupar un lugar indispensable dentro de las políticas de seguridad de la empresa. Y es que: “Garantizar la disponibilidad no sólo es reducir los riesgos de sufrir un ataque, sino que si lo tenemos poder recuperarnos en el menor tiempo posible”. Y si es gratis, mejor.

Un saludo.

Nos vemos en la próxima!

Irongate, al descubierto un nuevo malware para ICS.

El pasado 2 de junio, desde FireEye nos anunciaban los resultados del informe elaborado por  su “FireEye Labs Advanced Reverse Engineering (FLARE)”.

FireEye 01

Según nos cuentan, este grupo de trabajo a finales de 2015 identificó varias versiones de un malware dirigido a Sistemas de Control Industrial, ICS; con la capacidad de manipular procesos específicos dentro de un entorno simulado con dispositivos del fabricante Siemens. Decidieron llamarlos, IRONGATE.

La gente de FLARE encontró las muestras en Virustotal mientras investigaban ejemplares compilados con PyInstaller, algo empleado en otras ocasiones. Éstas destacaban por sus referencias a los sistemas SCADA y funcionalidades asociadas. Dos de ellas, contenían un payload subido desde distintos orígenes en 2014 pero ninguno de los antivirus lo detectó como malicioso.

Por otro lado, el CERT de productos de Siemens (Siemens Product Computer Emergency Readiness Team, ProductCERT), confirmó que IRONGATE no es viable contra sistemas, de control de Siemens, ni tampoco explotar ninguna vulnerabilidad en productos de este fabricante. No se puede hablar entonces de que exista una campaña de infección ni que suponga una amenaza, por lo que la conclusión más probable es que se trate de una prueba de concepto o una investigación sobre técnicas de ataque contra ICS.

El análisis concluye que IRONGATE aplica conceptos ya vistos en Stuxnet pero en un entorno simulado. Así pues, dado que la información sobre malware dirigido a sistemas ICS y SCADA es menor en comparación con otros ámbitos, es que han decidido compartir los detalles con la comunidad.

Vayamos con los aspectos técnicos.

Una de las características de IRONGATE es la de llevar a cabo un MiTM contra los procesos de entrada y salida I/O del PLC y el software del equipo que interactúa con el ICS dentro del proceso simulado. El malware reemplaza una DLL (Dynamic Link Library) con otra maliciosa convirtiéndose en intermediario entre la estación de monitorización y el PLC. Esta DLL registra cinco segundos de tráfico “normal” desde el PLC a la interfaz de usuario para reproducirla mientras manda de vuelta tráfico distinto al PLC. Esto podría permitir a un atacante alterar un proceso sin que el operador lo sepa.

La segunda característica a destacar es la capacidad para la evasión de Sandboxes. Algunas muestras del malware no se ejecutaban si se corrían sobre entornos VMWare o Cuckoo Sandbox. El malware usas estas técnicas para evitar la detección y resistir al análisis. La implementación de estas técnicas denota que el autor quería evitar su detección y por tanto estamos ante una aplicación maliciosa en contra de una aplicación legítima.

Cuckoo Sandbox

Finalmente, se averiguó que las distintas muestras estaban compiladas con PyInstaller, algo similar a lo empleado en otras ocasiones. Además se localizaron strings que contenían el término “payload”, también bastante común y asociado a otras piezas de malware.

IRONGATE no es comparable con Stuxnet en términos de complejidad, capacidad de propagación o implicaciones geopolíticas, sin embargo sí que comparten ciertas características y técnicas empleadas por éste como pueden ser:

  1. Ambos buscan un propósito específico.
  2. Ambos reemplazan DLLs para alcanzar manipulación de los procesos.
  3. IRONGATE detecta la observación/detección de malware mediante Sandoboxes o entornos virtuales, mientras que Stuxnet buscó la presencia de software Antivirus.
  4. IRONGATE graba y devuelve datos de proceso con el fin de ocultar las manipulaciones que introduce, mientras que Stuxnet si bien no intentaba esconderse de igual forma, si afectaba al funcionamiento de los autómatas S7-315 si ciertos valores representados en el HMI eran de carácter estático.

Por otro lado, no se ha identificado la forma de propagación, y probablemente no exista ya que se considera dicho malware aparenta ser parte de un proyecto de investigación, herramienta de pentesting o un desarrollo para testear un producto de Sistemas de Control Industrial. Esto puede interpretarse que estamos ante un suceso aislado, lo cual no significa que en un futuro pueda sofisticarse y representar una amenaza.

SANS 01

La parte principal de código ha sido escrito en Python e identificado en VirusTotal. Al parecer se hizo llegar a la citada plataforma de forma manual por medio de la interfaz Web. Esto, junto con la idea de que está dirigido a un entorno simulado, subido a un recurso público y que el malware no haya sido liberado, afirma la idea que se trate efectivamente de una prueba de concepto o una demo para algún producto concreto. Es difícil creer que alguien quiera llevar a cabo una APT contra ICS suba de forma manual a la citada Web algo tan sofisticado y más con los antecedentes de Stuxnet.

Aunque no suponga una amenaza, no podemos quitar importancia al hallazgo. Este hecho pone de relevancia que atacantes o personas con conocimientos específicos, están cada vez más preparados y con mayores capacidades para desarrollar código más elaborado, inteligente y posiblemente más destructivo de lo que fueron Stuxnet, HAVEX o BlackEnergy2. Lo cierto es que según afirman varias fuentes, las muestras de IRONGATE no fueron detectadas por ninguno de los motores antivirus, con lo que pone en evidencia la capacidad de éstos para detectar malware dirigido contra Sistemas de Control Industrial. En parte, claro está, porque se trata de una novedad frente a los ya conocidos.

SANS 02

Muchos responsables se estarán preguntando cómo protegerse de algo que muchas herramientas no han sido capaces de hacerlo por nosotros. Esto pone de relevancia que no podemos delegar en nuestras herramientas toda la responsabilidad de la protección. Obviamente debemos contar con ellas para securizar nuestras instalaciones, aparte de tener implementar unas políticas y estrategias debidamente establecidas, asentadas y sobre todo que se cumplan a rajatabla, pero no depositar confianza ciega. Las organizaciones deben contar con profesionales especializados en la materia, que entiendan las características de la Industria y la protección de Infraestructuras Críticas, muy distinto al tradicional mundo IT. Expertos que entiendan las nuevas necesidades, tiempos, tendencias, vectores y amenazas que están por llegar y que según indican las estadísticas van al alza.

En cualquiera de los casos todos debemos estar atentos con lo que está por venir, que como ya sabemos, va a seguir dando de qué hablar.

Un saludo!

Mas Información:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5

Why IRONGATE is a big ICS security Security Story?

Vectores de ataque sobre ICS

Siguiendo con el tema de las Amenazas sobre Sistemas de Control y Automatización Industrial que podéis encontrar en “Amenazas sobre ICS (Parte I)” y “Amenazas sobre ICS (Parte II)” en esta ocasión voy a hablar sobre los vectores de ataque. Éstos se sitúan dentro de las intencionadas ya que tiene un origen humano y además requieren de una mayor o menor planificación.

Comencemos:

  • Manipulación de las comunicaciones

Se basa principalmente en la captura de tráfico, inyección de paquetes, tramas, modificación de la información, etc. Existen varias formas entre ellas el ya tan clásico Man in the Middle (MITM). Algunos de los protocolos de comunicación industrial no disponen de controles de autenticación o integridad de mensajes por lo que es posible alterarlos y modificar sus contenidos. Dependiendo de qué modifiquemos podremos cambiar parámetros en los equipos finales, interferir en su funcionamiento y con ello sufrir consecuencias más o menos graves.

  • Destrucción física

La destrucción física puede incluir tanto de infraestructuras como los dispositivos que las componen. Lo que se busca básicamente es el sabotaje, bien de forma directa mediante la rotura o por un medio que permita la re programación y alterar su funcionamiento.

Destrucción fisica

  • Phishing

Este es un viejo amigo bastante conocido. Por recordar, lo definiremos como la técnica de ingeniería social que busca hacerse con información relevante o sensible  suplantando la identidad de una persona u organización de confianza para el individuo a atacar. El interés que busca puede ser muy diverso, desde hacerse con información de algún proyecto o prototipo hasta credenciales de administradores o ingenieros de proceso pasando por detalles sobre equipamiento.

  • Malware

El malware en cualquiera de sus versiones (troyanos, gusanos, rootkits, etc.) pueden tener una gran variedad de propósitos desde la denegación de servicio, pivoting, escalada de privilegios, sabotaje, y un larguísimo etcétera. Obviamente los resultados podrán ser igualmente diversos. Por ejemplo, la inundación de la red con tráfico broadcast, captura de tráfico o actividad del equipo, escaneo de host y servicios, cambio de parámetros y configuraciones, etc. A su vez, esta información puede ser enviada a lo que conocemos como “Comand and Control, C&C” para su explotación y llevar a cabo distintas opciones. Estas comunicaciones muchas veces son cifradas bajo protocolos y servicios normalmente abiertos según entornos como TCP 80, 8080, 443, 21 o UDP 53, 123, entre otros posibles.

Los ejemplos más claros en entornos industriales los más conocidos son Stuxnet y Duqu, aunque también podemos tener otros como Havex, BlackEnergy 2, Conficker, NightDragon entre otros afines.

Kaspersky_Lab_infographics_stuxnet_5_victims_eng_final-10-254008

  • Robo

Mediante este vector, como es lógico, nos encontramos con la sustracción de información. La que más suele interesar son las relacionadas con la actividad de las instalaciones, o la propia empresa. Podemos hablar de ficheros de configuración que contengan datos sobre dispositivos, sistemas, parámetros, referencia sobre los propios equipos y actividad.

Pero no todo se refiere al ámbito lógico, también está lo físico. El hurto del propio equipamiento existe, por ejemplo elementos de recogida de datos, PCs de monitorización, cableado y otras tantas cosas que puedan ser atrayentes para los amigos de lo  ajeno.

  • Spam

No hablamos que desde un sistema dentro de una instalación o entorno industrial deba poderse acceder al correo electrónico de los empleados, que obviamente no debe permitirse. Sino del uso incorrecto del mismo.

Hablamos que un usuario emplee la cuenta de correo corporativa para darse de alta en páginas web que a posteriori le hagan llegar mensajes no solicitados conteniendo publicidad y referencia a sitios web con contenido malicioso. Si accede, podría instalársele algún tipo de malware y a partir de ahí, pues… También puede contemplarse el recabado de información como otras cuentas de correo para luego enviarles más correos de este tipo y proseguir con la campaña.

  • Escalado de privilegios

Aprovechando un “bug”, error, o adjetivo similar de una aplicación o sistema operativo, un atacante podría llevar a cabo tareas que inicialmente un usuario no está autorizado o bien heredar los permisos de otro.

Un ejemplo lo tenemos en siguiente enlace, aquí. Parece que Siemens siempre está en boca de todos, pero hay otros muchos como estos:

Enlace 1

Enlace 2

Enlace 3

Acceso

  • Repetición

Este tipo de ataques consisten en el reenvío de tráfico que ha sido capturado con anterioridad o generado intencionadamente mediante software. Además, aprovechando la falta de métodos de seguridad implementados en distintos protocolos como Modbus, los paquetes pueden ser modificados para provocar comportamientos distintos a la operativa normal, con los daños que eso pueda acarrear. Este vector está relacionado, como es lógico, con el punto “Manipulación de las comunicaciones”.

  • Spoofing

El spoofing consiste en suplantar la identidad de los actores que pueden intervenir en una comunicación. Existen varias técnicas, dependiendo del nivel en el que hagamos la suplantación, por ejemplo ARP spoofing, direcciones MAC; IP spoofing, direcciones IP; DNS spoofing, dominios; email spoofing, direcciones de correo electrónico; en fin todo aquello que pueda ser sustituido por otro distinto al original. Si bien éstas provienen del mundo IT, en el OT también podernos encontrarnos con algunas de ellas. Como hemos mencionado en el punto anterior, algunos protocolos de comunicación industrial no poseen medidas de seguridad que eviten o detecten este tipo de ataques.

  • Inyección de código

La inyección de código consiste en aprovechar esos “bugs” de programación presentes en las aplicaciones o sistemas operativos con para poder llevar a cabo distintos tipo de acciones. Alguna de ellas puede ser la obtención de información, la denegación de servicio, la apertura de una sesión contra un equipo concreto, pero dependiendo del código inyectado y la vulnerabilidad los resultados pueden ser muchos otros.

Dentro de los entornos industriales, es común la existencia de elementos HMI en los cuales se instalan distintas aplicaciones para el control de los autómatas, u otros elementos. Éstas pueden presentar fallos de programación y por tanto permitir estos ataques. De ahí que resulte elemental instalar sólo el software estrictamente necesario.

  • Denegación de servicio

Si bien ya lo hemos nombrado anteriormente, una denegación de servicio consiste en impedir que un sistema pueda ofrecer un determinado servicio para el que está destinado. Como origen podemos hablar tanto de las debilidades que puedan afectar a aplicaciones que prestan dicho servicio y por otro aquellas relacionadas con las comunicaciones. Por poner un ejemplo, en el primero de ellos podríamos hablar de que esa aplicación pueda “bloquearse” bajo unas determinadas condiciones de procesamiento y por otro que un PLC no pueda procesar varias comunicaciones simultáneas ya que los recursos hardware de los que dispone no sean suficientes y por tanto pueda bloquearse. Por experiencia, esto último, puede resultar muy común cuando lanzamos ciertos escaneos de vulnerabilidades sobre dispositivos de campo.

dos-attack-acunetix

  • Ingeniería Social

Básicamente lo podríamos resumir como la técnica de no sólo obtener información de un individuo sino además conseguir que haga aquello que de otra manera no haría. Según diría Kevin Mitnick Se basa en 4 principios básicos:

  1. Todos queremos ayudar.
  2. El primer movimiento es siempre de confianza hacia el otro.
  3. No nos gusta decir No.
  4. A todos nos gusta que nos alaben

Las  técnicas empleadas pueden comprender desde plantear un problema o una necesidad para que, dentro de ese ánimo colaborativo, revelar o dar pistas sobre nuestras infraestructuras o componentes en ellas instaladas.

De esta manera hemos enumerado los posibles vectores de ataques que pueden de los que pueden ser objeto los Sistemas de Control y Automatización Industrial, siempre desde un punto de vista intencionado. Para ello deberemos de implementar distintas medidas técnicas y cumplir con unas políticas de seguridad previamente establecidas y de obligado cumplimiento. Pero sobre todo, concienciar a las personas que tengan contacto con la operativa, mantenimiento y despliegue de estas instalaciones sobre las amenazas y el creciente aumento de éstas . No podremos estar seguros al 100% pero sí reducir los riesgos hasta unos niveles aceptables.

No quisiera finalizar sin hacer referencia a dos frases que bien pueden encajar con la idea que aquí se busca:

“Una cadena es tan fuerte como su eslabón más débil” 

“Sólo se salva del peligro quién vigila incluso cuando está seguro”

Un saludo a todos, nos vemos en la siguiente y no te olvides que puedes seguirnos también en @enredandoconred .

Corte de suministro eléctrico en Ucrania por ataque con malware

El pasado 23 de diciembre los habitantes registraron un corte en el suministro eléctrico en la región ucraniana Ivano-Frankivsk. Tras investigar lo sucedido se comprobó que no se trataba de un corte accidental sino que resultaba ser algo más sofisticado. El mismo fue provocado por la actividad de un malware dirigido contra los sistemas de diversas centrales eléctricas lo cual no se convertía en un hecho aislado sino un ataque dirigido hacia este tipo de infraestructuras.

central-electrica2

Este día, aproximadamente la mitad de esta población (más o menos 1,4 millones de habitantes según algunas fuentes) se quedaron sin electricidad durante varias horas. Pero ¿qué lo originó? Dichas centrales estaban siendo atacadas por cibercriminales empleando los troyanos BlackEnergy y KillDisk. ¿Dos troyanos? Pues sí, dos a falta de uno.

El método de infección venía de la mano de envío de correos electrónicos con un fichero adjunto malicioso para ser abierto por la suite Microsoft Office. Para darle más credibilidad suplantaron al remitente para que pareciese que provenía del Parlamento ucraniano. No nos confundamos,   no se trata de una vulnerabilidad de este software ofimático, sino de las macros albergadas dentro de dichos ficheros que, mediante un texto, persuadía al usuario a ejecutarlas.

BlackEnergy

Si el usuario era engañado, el sistema, quedaba infectado por el troyano BlackEnergy Lite. Este malware modular utiliza varios componentes descargables para llevar a cabo tareas específicas. Una de estas tareas era la descarga del otro troyano, el KillDisk.

Éste una vez ejecutado en los sistemas previamente infectados por BlackEnergy, puede destruir distintos tipos de ficheros. La variante en cuestión incluía funcionalidades extras que permitían al troyano, no sólo borrar archivos importantes del sistema para evitar cualquier posibilidad de reinicio (común en los troyanos más destructivos), sino que contenía códigos concretos para sabotear sistemas industriales, como la sobre escritura de ciertos ejecutables de software empleado ampliamente en este tipo de entornos.

Por si fuera poco, según algunas fuentes, BlackEnergy permitiría acceso remoto a los atacantes pudiendo éstos, en teoría, apagar el equipo. Esto sumado a la acción de KillDisk descrita en el párrafo anterior, como la sobreescritura de  archivos ejecutables en el disco duro con datos aleatorios, dificultaba o imposibilitaba la restauración del sistema.

Así pues este incidente refuerza la necesidad de implementar medidas humano-técnicas para proteger este tipo de infraestructuras críticas en especial los sistemas SCADA (Supervisory Control And Data Acquisition), o aquellos que sirvan para la administración de instalaciones de control y automatización industrial.

Recientemente hablaba en otra entrada que el ICS-CERT publicó una recomendación sobre las 7 estrategias a seguir para la securización de entornos industriales, apuntando como primera medida el “Whitelisting”. El “Whitelisting” o “Listas Blancas” en el idioma de Cervantes, consiste en la definición de una serie de aplicaciones o procesos que se consideren legítimos y deban ser ejecutados ya que forman parte de la operativa normal del sistema. Todo lo que no quede recogido dentro de la política del “Whitelisting” se bloqueará. En el caso que nos atañe la primera de las preguntas es ¿es necesario tener instalado un software que permita abrir ficheros de entornos ofimáticos en sistemas de entorno industrial? Si la respuesta es “necesariamente sí” (lo cual lo dudo y no lo creo así) podríamos emplear un software que permita llevar a cabo dicha estrategia de seguridad. Pero si no lo es, la respuesta es clara, ¡desinstalación inmediata de ese software!

En fin, como vemos no importa el sector al que nos refiramos, pero lo que si es cierto es que la previsión de este tipo de ataques y vectores, va en aumento en cantidad, sofisticación y “oscura” calidad.

Más información:

Enlace 1

Enlace 2

Enlace 3

Enlace 4

Enlace 5

Enlace 6

Enlace 7

Enlace 8