EKANS, SNAKE; new Ransomware targeting ICS environments

Few weeks ago, a new ransomware sample was detected and announced to the community. Here you can find some interesting information that will be updated in the future.

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.

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.

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.

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:

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.

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

Por ejemplo si buscásemos relacionado con «Phoenix Contact» tenemos lo siguiente:

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.

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

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

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:

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!!