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!

Buscando ICS en la red, ZoomEye

En el día de hoy voy a hablar de una herramienta que si bien el grupo a las que pertenece ya es conocido y reconocido por muchos profesionales del ámbito IT, quizás no lo sea tanto para otros como ingenieros y técnicos de sistemas de control y automatización. Éstos, hasta hace no demasiado mucho tiempo, han estado ajenos a todo lo relacionado con la Ciberseguridad, cosa que ha tenido que cambiar, y cambiará aún, más con la llegada de la tán nombrada Industria. 4.0.

El tipo de herramienta a la que me refiero no es ni más ni menos, que los motores de búsqueda de dispositvos en Internet. Éstos, son buscadores no de páginas o contenido web, que es a lo que estamos acustumbrados, sino equipos como pueden ser servidores, routers, cámaras, y todo aquello que pueda estar expuesto en Internet. Y como no, autómatas, RTUs, HMIs, y cualquier otros sistemas que deban ser accesibles remotamente. A priori muchos podrían pensar que esto es un disparate, y que a nadie se le ocurriría dejar visibles sus equipos así tan alegremente, sin embargo esto es más común de lo que pensamos.

La herramienta por excelencia en este ámbito es Shodan el cual fue creada en el año 2009 por John Matherly quien concibió la idea de buscar sistemas en lugar de páginas en Internet. Si bien uno puede crearse un usuario de froma gratuita, también existe una opción de pago con las que se consiguien mayor cantidad de posibilidades.

Por ejemplo, si efectuamos una búsqueda de equipos con el puerto TCP 102 abierto, tendríamos un resultado como sigue:

shodan_01

Destacar por ejemplo cómo aparte de autómatas también nos identifica dispositivos “Conpot”, el Honeypot del que hablaba en estas dos entradas Parte I y Parte II.

shodan_02

Otro ejemplo es Censys. Misma idea, con misma funcionalidad.

censys_01

Por ejemplo si buscásemos relacionado con “Phoenix Contact” tenemos lo siguiente:

censys_02

Resulta preocupante no tanto que esta información esté disponible,  sino el uso que se le pueda dar,  y sobre todo quién lo haga. Es decir, si estos datos son accesibles, quizás existan otros que no lo sean y quien esté detrás del sitio disponga de ellos, reservándose el hecho de hacerlos públicos. Si vemos lo que vemos es porque “alguien”, nos deja,  alguien tiene el control y la capacidad de decidir “esto si,  esto no”. A partir de ahi,  según sus intereses,  dejarnos hacer tal o cual cosa  bien gratis o “pasando por caja”.

Tras esta reflexión,  llegamos a la herramienta en cuestión, ZoomEye. La misma tiene origen chino, y esto casi siempre asusta un poco. Aunque, en mi opinión, aqui todos se “miran” se “sonríen” entre ellos. La utilidad es la misma que las anteriores y, al igual que en Shodan, encontramos un apartado específico a ICS desde dónde hacer de una manera predefinida búsquedas relacionadas con protocolos o productos específicos de algunos fabricantes.

zoomeye_01

En la siguiente imagen se puede ver seleccionando el producto S7-300 (PLC) de Siemens.

zoomeye_02

También dispone de una vista (“Vision”) donde podremos la ubicación geográfica de los equipos localizados.

zoomeye_03

De igual modo se cuenta con un apartado “Docs” donde podremos ver el significado de mensajes, filtros, errores y demás información. Aqui dejo, por ejemplo, los filtros de búsqueda:

zoomeye_04

A esto habría que sumar un último punto. Como estamos acostumbrados los sistemas poseen contraseñas por defecto o “hardcodeadas” que muchos responsables o adminsitradores pensando en viejas ideas de “Quién tendrá interés”, “A mi no me va a pasar”, “que probabilidad hay de que eso me pase a mi” y bla bla bla.; no las cambian o no puedan hacerlo. Lo cierto es que investigadores del grupo “SCADA StrangeLove” hace unos meses publicaron una lista con las contraseñas por defecto de muchos fabricantes y que puede ser accedida y descargada desde Github en el siguiente enlace. Por tanto dada la capacidad de estas herramientas y la información ya disponible para autenticación en sistemas; obliga necesariamente a tomar medidas ya que puede quién lo utilice no con buenas intenciones. Y cuando digo “quien” hablo de grupos terroristas, Agencias de Inteligencia, delincuentes, inconscientes, o cualquier otro que pueda no ir con buenas intenciones.

En cualquier caso resulta necesario que cualqueir equipo de esta naturaleza que deba ser accedido desde el exterior, cuente con un sistemas que eviten la exposición directa, y a su vez, establezcan unos controles de acceso, autenticacióin y cifrado de las comunicaciones. La solución más adecuada reside son las VPN, disponiendo ya de productos concretos para entornos industriales. Os dejo unos ejemplos:

Fortinet

Endian

Netgate

Como decía, los Sistemas de Control Industrial en muchas ocasiones deben ser accesibles remotamente para tareas de soporte, mantenimiento o incluso el propio funcionamiento.  Imaginar por ejemplo un parque de aerogeneradores eólicos sobre los cuales se desee monitorizar los MWatts producidos. Como compenderéis no puede ir un técnci con un Range Rover e ir apuntando uno por uno… Sin embargo, éstos pueden ser no sólo detectados sino además accedidos si no se han tomado medidas tán básicas como cambiar las contraseñas por defecto. siempre que se pueda. No obstante, esta medida no puede tomarse del todo efectiva ya que éstos pueden implementar versiones de protocolos vulnerables y que junto con la condición de una difícil actualización, continúan de una forma u otra, en la misma sitación. Esto es, vulnerables y además expuestos. Es por ello que deben establecerse otro tipo controles como la creación de VPNs mediante NGFW, con motores AV, IDS/IPS, Control de Aplicación, capacidad de hacer DPI junto con los procolos industriales utilizados y declinar en ellos el acceso controlado y con unas medidas de seguridad aceptables.

Esto esto es todo, 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

Amenazas sobre ICS (Parte II)

Hace unos días hablaba de las amenazas que afectan a los Sistemas de Automatización y Control Industrial, tratando en concreto las de carácter no intencionado. En la entrada de hoy abordaremos las restantes, esto es, las que van dirigidas expresamente hacia ellos, las intencionadas.

A diferencia de las anteriores éstas tienen un origen humano, bien directa o indirectamente por medio de la creación de código o software.

Para ellas podemos definir 6 grandes grupos, como son:

  1. Empleados descontentos
  2. Individuos / Pequeños grupos / Hacktivistas
  3. Competencia
  4. Grupos Criminales
  5. Terroristas
  6. Servicios de Inteligencia / Gobiernos

EMPLEADOS DESCONTENTOS

Los empleados descontentos, o también llamados en la lengua de Shakespeare “Insiders”, son la fuente de amenazas más importante, y común, para los sistemas de control y automatización. El personal interno dispone de toda la información sobre ellos y en consecuencia el conocimiento sobre su operación, configuración, funcionamiento, criticidad, componentes, debilidades, etc.

No obstante, también se debe tener presente a los antiguos empleados que, aunque ya no disponen de acceso a las instalaciones y dispositivos, sí pueden tener conocimiento de la operativa, infraestructuras, accesibilidad remota si la hubiera, etc. Debido a este hecho, podrían en un momento dado, llevar a cabo acciones desde fuera de la organización que sean ejecutadas de forma exitosa como por ejemplo un DoS. Enlace.

INDIVIDUOS / PEQUEÑOS GRUPOS / HACKTIVISMO 

Dentro de este grupo incluímos a personas que actúan de forma individual o conjunto reducido de ellas movidos principalmente por un afán de notoriedad o protagonismo. Su fin último no es poner en peligro al proceso industrial y la organización que está detrás, sino su propia publicidad y reconocimiento. También podremos encontrarnos a los denominados “Script Kiddies” que iniciándose en el manejo de herramientas de libre distribución pueden producir algunos daños.

Por otro lado tendríamos grupos tales como Anonymous, LulzSec, GhostSecurity que llevan a cabo ataques o acciones contra objetivos concretos. Generalmente se trata de ataques del tipo DoS o DDoS, sin embargo también podremos encontrarnos con la publicación de información, previa intrusión en sistemas.

COMPETENCIA 

Las compañías rivales si algo desean saber son los movimientos de la competencia para poder tomar las medidas necesarias y alcanzar una ventaja frente a otras empresas del sector. Toda información sobre funcionamiento, políticas, estrategias, inversiones, es bien recibida. Incluso pueden llegar a recurrir a grupos criminales que lleven a cabo sabotajes contra intereses o infraestructuras con tal de perjudicar su imagen. No podemos eludir el denominado espionaje industrial que nada tiene que ver con este punto pero que puede ayudar en lo que a la recolección de información se refiere. Enlace. Enlace.

GRUPOS CRIMINALES 

Los grupos criminales atacan los sistemas de control para chantajear a la industria y pedir dinero a cambio de no revelar información sensible. Otra de los movimientos consiste amenazar con dejar sin control a los operarios legítimos o exigir un monto económico a cambio de devolver el control sobre los sistemas. Hay que tener en cuenta que dependiendo de las instalaciones las consecuencias pueden llegar a ser bastante graves, no sólo a la población civil sino a la ecología.

TERRORISTAS 

Hasta hace no hace mucho se consideraba a los grupos terroristas no suponían una amenaza a nivel lógico, pero sí a nivel físico. Las amenazas de esta índole se basan en la destrucción de las infraestructuras, principalmente las críticas, con el objetivo de desestabilizar el funcionamiento de un país por motivos políticos, religiosos, o sociales. Sin embargo grupos como Estado Islámico ya disponen de fieles dedicados a llevar su guerra por medio de acciones a través de Internet (Link) (Link). Tal es el caso del denominado Cybercalifato.

SERVICIOS DE INTELIGENCIA EXTRANJEROS / GOBIERNOS 

No es ninguna novedad, ni ningún secreto que los servicios de inteligencia de distintos países realizan actividades de espionaje y captura de información dentro y fuera de sus fronteras.  ¿Qué se puede decir a estas alturas de la NSA, verdad?. No sólo poseen recursos tecnológicos, económicos y legislativos, sino también la inmunidad y protección de otros estados aliados que persigan el mismo objetivo. Link.

En fin, como podemos comprobar son varios los principales focos de amenazas a las que todo Sistema de Control y Automatización puede llegar a enfrentarse, lo cual no quiere decir que vayan a darse necesariamente. Pero haberlas, las hay. Todos somos conscientes que la seguridad al 100 % no existe y de lo que se trata es reducir los riesgos, minimizando nuestra exposición y debilidades.

Podemos representar que:

Riesgo = Amenaza x Vulnerabilidad x Impacto

Con la entrada XXXXXXXXX y la de hoy hemos abordado la primera de las variables, tanto en su origen no intencionado como intencionado.

El impacto dependerá en gran medida de la actividad a la que se dedique la instalación ya que, no será lo mismo si hablamos de una estación eléctrica que deje sin luz “sólo” a una población de 250.000 personas; una refinería que provoque un desastre ecológico por derrame de combustible o una fábrica que deba de para su producción por ejemplo por 24 horas.

Sin embargo en lo referente a las vulnerabilidades ya hay que considerar algún punto más que lo dejaremos para futuras entradas así como los distintos vectores de ataque.

Espero que haya sido de vuestro agrado, nos vemos en la siguiente.

Un saludo!

Amenazas sobre ICS (Parte I)

Como hemos podido comprobar en estos últimos años el número de ataques a Infraestructuras Críticas e Instalaciones Industriales ha ido en aumento. Aquellos buses de campo que hace tiempo atrás quedaban aislados de las redes empresariales poco a poco han ido incorporándose a ellas gracias a la implementación de protocolos de basados en TCP/IP. Si bien las funcionalidades y posibilidades han crecido esto ha generado a su vez que queden expuestas a actividades hostiles por parte de personas físicas o malware concreto para IACS. Así pues, esta visibilidad hace que debamos tomar más precauciones.

Inicialmente se hablaba del “air-gap” como medida de protección. Si bien puede resultar efectiva en algunos entornos, la implementación de ciertos servicios como monitorización y recolección de datos de los equipos de Automatización y Control obliga que éstos estén accesibles desde los sistemas SCADA y a su vez por los agentes y personal encargado de visualizar los datos en ellos representados. De esta manera, ha habido que adaptarse e implementar el concepto de “Defensa en Profundidad” como medida que más puede reducir los riesgos de que un ataque pueda ser satisfactorio.

En cualquier caso al margen de la estrategia de protección empleada cuanto más, expuestos estén nuestros sistemas de control, la amenza es mayor. Entendiendo por amenaza la posibilidad de que un evento o una acción determinada ocurra produciendo un daño material o inmaterial sobre los componentes de un sistema o un conjunto de ellos. Esto es, daños a nivel físico como lógico.

A modo general podríamos catalogar a estas amenazas en dos grandes grupos, intencionadas y no intencionadas. Si bien la mayor parte de ellas son de carácter no intencionado, aunque existe una claro aumento de las intencionadas.

Amenazas no intencionadas.

Las amenazas no intencionadas, podemos decir son todas aquellas que no son dirigidas deliberadamente contra el  sistema de control y automatización, pero que, por una u otra causa aún y así pueden ser un peligro para éstos. Normalmente, las amenazas no intencionadas están relacionadas con fenómenos que están fuera de nuestra capacidad de gestión.

Así pues es posible marcar una división entre aquellas que tienen un origen humano y las que no, estableciéndose entre todas, cuatro grandes grupos:

  1. Safety
  2. Fallos de equipamiento
  3. Desastres Naturales
  4. Humanos

FALLOS DE “SAFETY”

Por “safety” entendemos todas aquellas medidas que ayudan a evitar de un accidente, relacionándolo con términos como prevención, seguridad en el proceso, figuras de ingenieros industriales. Al tratarse de instrumentación mecánica y/o electrónica debido al uso, fatiga o deterioro de materiales, pueden provocarse daños en los sistema de control y automatización y por tanto, en el propio proceso industrial.

Estos fallos de los sistemas de “safety” no sólo incluyen los problemas que pueden tener los sistemas de protección tanto del equipamiento físico controlado (por ejemplo: interruptores,  dispositivos de emergencia, detectores de posición, etc.) sino también el personal que lo manipula (por ejemplo: técnicos de mantenimiento, retenes, etc.). Aquí os dejo un artículo publicado por INCIBE donde lo explica muy bien, picha aquí.

FALLOS DE EQUIPAMIENTO

Al igual que sucede con los sistemas de safety, los dispositivos de automatización y control son elementos hardware con muchos componentes electrónicos. Si bien se caracterizan por una gran robustez y durabilidad no están exentos de sufrir fallos como pueden ser avería de la fuente de alimentación, módulos de comunicaciones, agotamiento de recursos de memoria, etc. Sea cual sea la causa, la operatividad y disponibilidad de las instalaciones puede verse afectada hasta el punto de quedar inutilizable total o parcialmente.

DESASTRES NATURALES

Aquí quedan recogidos todos aquellos sucesos medioambientales con consecuencias graves o incluso fatales y cuyo origen difícilmente se puede predecir. Por citar alguno podríamos hablar de inundaciones, terremotos, incendios, o condiciones climatológicas fuera de lo habitual. Todos recordaremos el tsunami que azotó la costa oriental de Japón en el año 2011 en la que la central nuclear Fukushima se vio dañada con las consecuencias que aparejó. También en esa ocasión un gran número de servicios de Telecomunicaciones, presas hidroeléctricas, aeropuertos, y demás Infraestructuras Críticas se vieron gravemente afectadas o destruidas.

ERROR HUMANO

Suelen decir que la fortaleza de una cadena radica en el eslabón más débil.  Dentro de la estrategia de protección el ser humano juega un papel determinante y muchas veces con nuestras confianzas, descuidos o desidia, podemos comprometer toda la seguridad de nuestra protección. Ese USB que nos pasan y lo pinchamos sin haberlo pasado primero un antivirus o ese software descargado que viene con el “crack” y aparte de la licencia nos trae otro “regalito”. Así pues, dentro de este grupo hemos de considerar los fallos producidos por descuidos o negligencias. Hablamos de memorias, pero no nos olvidemos de la existencia de otro tipo de dispositivos como los teléfonos móviles… Ya el error no es esa nota autoadhesiva con el usuario y contraseña debajo del teclado. Pero todo no son imprudencias, también puede ocurrir que sin, quererlo, nos podamos equivocar en la parametrización de un elemento  o en la carga de un fichero que no corresponde con el dispositivo en cuestión, y como es de esperar no funcione como se espere.

Como hemos podido ver, no siempre las amenazas vienen de la mano de personas o sistemas con ánimo de provocar un daño sobre nuestra organización. Muchas veces sin desearlo podemos sufrir accidentes, que cuyas consecuencias pueden ser mayores que un ataque dirigido y estudiado durante meses.

Como era de esperar próximamente hablaré de esas otras amenazas, las intencionadas, donde hablaremos esas sí que sí están hechas con premeditación, alevosía y “nocturnidad”.

Un saludo nos vemos en la próxima!

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