Device Whitelisting

Today I would like to start by apologizing because this is my first post in English. English is not my mother tongue so be sure that I can make some grammar, vocabulary or expression mistakes. Last year I finished with more than 52000 visitors and I decided for this 2018 try to write some articles in this language, in particular to come to English-speaking people. Having said this, let’s make a start!

A lot has been written about if USB ports have to be turned on in industrial environments and the threat that they might suppose for them. In particular, pen drives and other storage devices. Obviously, this is true and somebody may think “Ok, block them and the problem will disappear”. Yes, but depending on the scenarios it cannot be possible to do. The theory crashes with the reality, once again. Why? Few questions…

  1. How do you access to data stored in systems located on isolated facilities?
  2. What do you do if recover a system without network connection is needed?
  3. How do you install a new software version if the network is not routed and cannot access to other like DMZ?
  4. What happens if the software requires a license USB device?
  5. If you have a backup system, what do you do if you have to recover a system and the network connection is not available? And if this is possible, are you going to download several gigabytes from that server across the OT network?
  6. If you have a software distribution system, how do you deploy software that cannot be packetized?
  7. Are you going to trust totally on these backup systems and do not have an Emergency Plan to storage configurations, programs, software or firmware in an external USB Hard Disc Drive?

For these and further questions are that the USB devices have, can and must be used at industrial environments with multiple purposes. However, we must take measures to prevent any incorrect use and be the source of incidents by negligence, spread up malware, steal information, infect a system, and so on. In consequence, the USB port in the majority of cases have to be switched on.

Obviously, the first step should be raise awareness to all the personnel involved, or related, with OT tasks, but everybody knows that this is not enough. We need technical tools.

Consequently, as we must live with our “enemy” because we need him, we have to decide how to control him, and reduce the risk that somebody, or something, cause damages in our facilities.

One measure is to decide which USB device we will use for maintenance, operational, recovery or any other justified reason to be plugged on to own systems. For example, HMI, engineering workstations, programming laptops, etc. Others, or any similar as mobile phones, pen drives, are forbidden. Then, either via software or endpoint security solution, permit or deny mount them on these systems.

Today I will talk about how to do this using Symantec Embeeded Security : Critical System Solution” in 7.1 version. In other posts, I mentioned how USB Control and Application Whitelisting works.

On this occasion I have created the following scenario.

USB Whitelisting Scenario v1

As you can see, we have “Management Console” installed on a PC with Windows XP OS. From there, we connect to the SES:CSP Server to set up Application Whitelistng Policies. Finally, a Programming Laptop used to connect to PLCs and other devices located in OT environments.

We connect to the server from XP PC and open the selected policy named “AUTH_USB_win_whitelisting_sbp v7.1.0 r136 – Whitelisitng”

USB_POLICY_01

Open “Device Control Rules” we are able to block, or not.

USB_POLICY_02

If we check “Block USB devices” a new window is opened.

USB_POLICY_03

From there we can “whitelist” the devices. Clicking on “Add” we can choose between those we have connected or if we want to specify them manually.

USB_POLICY_04

In this case our device appears as follow:

USB_POLICY_05

Now we are ready to save changes and apply onto the programming station.

USB_POLICY_06

As you can see the device can be mounted and the files be accessed in function on the application policies.

USB_POLICY_07

But if other USB stored devices are plugged, they will not be mounted and visible on the explorer. A log will be created as follow.

USB_POLICY_08

The green “information” logs are related to the right device.

The use of USB devices as pen or hard disc drives sometimes are not only useful, are necessary. All depends on the activity, the context or the criticality of the systems. They give us the flexibility to transfer files, configurations or any information, especially in those moments when we cannot do it across the network. For example, have a second repository to storage a copy of everything we need to recover an equipment, something important in the context of Emergency or Disaster Recovery Plans. Furthermore, the data transfer using USB can be higher than network interface cards, probably 10/100 Mbps, so we can do our tasks faster than if we wait to download everything from a server.

In any case, we must control the USB ports because they can be our allied or our enemy. We must do not forget that in case of unauthorized USB is plugged, the execution, read or write can be submitted to application whitelist policies.

That´s all, Thanks a lot, see you again!

Edorta

Terminamos 2017, empezamos 2018

Por estas fechas, hace un año, veía cómo las expectativas acerca del número a visitas para 2016 se había superado con creces. Había alcanzado las 32.379. Como era lógico para este 2017 el planteamiento era aumentar esa cifra lo que supondría haber llegado a una mayor cantidad de público. Decidí invertir algo de dinero en mejorar el plan de hosting e incluir mejoras que repercutieran en el posicionamiento, plantillas editables para un aspecto más atractivo, nuevos apartados, entre otros. Aparte claro está, la publicación de nuevo contenido.

El 2017 ha llegado a su fin y toca mirar los números finales para ver cuáles han sido los resultados. Si bien, ya veía que iban a ser buenos por el seguimiento semanal, no han podido ser mejores. Cuesta creerlo, la verdad, pero hemos alcanzado….

 ¡¡¡ 52.169 !!!

Cuando empecé 5 años atrás no pensé que esto pudiera suceder. Pero sí, ha sucedido. El sitio parece que tiene el suficiente interés tanto para ser visitado como referenciado Y claro, como no podía ser de otra manera, me llena de orgullo. Sólo hay que ver la tendencia anual.

Captura de pantalla 2018-01-01 a las 11.51.59

En este camino quisiera agradecer a todos los que han accedido, encontrado o leído algunos de los artículos y dedicarle parte de su tiempo. Sin ellos, estas cifras no serían posibles. También, dar las gracias a las personas y empresas que han colaborado y ayudado de una forma u otra.

Por un lado, a Fortinet España por tener acceso a sus productos y descubrir las funcionalidades que ofrecen para OT,  pudiéndose hacer frente desde un solo fabricante las muchas de las necesidades que tanto entornos industriales como infraestructuras críticas requieren sea el que sea su sector. Sin olvidarnos, además, de su integración con otros distintos de terceros para aportar unos mejores niveles de seguridad sobre distintos escenarios. A Jose Luis Laguna y Antonio Navarrete, muchas gracias.

Fortinet-01

Al Centro de Ciberseguridad Industrial, por no sólo darme la oportunidad y confianza de ser su Coordinador del País Vasco, sino de incluirme en muchos de sus boletines semanales haciendo referencia a los artículos publicados. A José Valiente, Miguel García-Menéndez y Susana Asensio, muchas gracias.

Coordinadores

XI Jornadas CCN-CERT, de derecha a izquierda, Oscar Bou (Coordinador Valencia), J. Valiente (Director CCI); M. Pulpillo (Coordinador Andalucía); J. Figueras (Coordinador Cataluña) y yo, Edorta Echave (Coordinador País Vasco)

A mis compañeros de profesión, de trabajo, y amigos por darme su opinión sincera sobre su visión tanto del blog, del contenido, ideas o recomendaciones en redes sociales. Saber de sus comentarios, ayuda a mejorar, seguir en la misma línea o corregir errores. A Jon Bueno, Unai Gomez, Borja Lanseros, Jose Luis Flores, Aaron Flecha, Jose Luis Jimenez, Ana González, Joan Figueras, Guido Nahuel Ygounet, Belén Pérez Rodriguez, David Marco Freire, Enrique Dominguez, Jose Manuel Sacristán, Edgard Capdevielle, Luis Ochoa, Carlos Navares, Walter Heffel, Elyoenai Egozcue, David Imizcoz, Mikel Diaz de Arcaya, Diego Gil, Alvaro Rivas ZuazoAdriel Regueira, entre muchos otros más. Disculparme si alguno no está en la lista.

Con todo ello, ponemos rumbo a 2018. Con nuevas ideas, con nuevos propósitos. Lo malo va a ser que el día sólo seguirá teniendo 24 horas… pero creo que esto es algo que los que estamos metidos en muchos “fregaos”, “historias”, “compromisos” y otras tantas responsabilidades. Y es que ¡hay que ver lo fácil que nos liamos… 😉

Espero pues en los próximos 365 días que se nos presentan pueda seguir manteniendo este blog los suficientemente interesante como para que dentro de unos meses pueda deciros de nuevo que hemos superado los objetivos.

Un abrazo!

Triton/Trisis/Hatman; un malware para SIS.

Hace pocos días atrás saltaba la noticia acerca de la aparición de un nuevo malware para Sistemas de Control Industrial bajo el nombre TRITON, TRISIS o HATMAN. Un malware que a diferencia de otros como Stuxnet, Havex, Blackenergy2, CrashOverride tiene como objetivo sistemas SIS.

Los sistemas SIS (Safety Instrumented Systems) son los encargados de mantener bajo condiciones “seguras” instalaciones, procesos y equipos en caso de producirse alguna anomalía o mal funcionamiento. Así como en inglés podemos diferenciar entre “Security” y “Safety”, en español, empleamos únicamente la palabra “Seguridad” introduciendo cierta confusión. Es por ello es que muchas veces debamos especificar el ámbito al que hacemos referencia. Esto es, “Security”, seguridad de la información y “Safety”, seguridad de personas o instalaciones.

Estos sistemas operan al margen del propio proceso productivo, monitorizándolo y siendo independientes de los equipos que participan en él. No obstante, pueden estar integrados dentro de éstos. Aunque, en general, el equipamiento industrial es robusto y confiable, los SIS lo son aún más incorporando técnicas de corrección de errores, autodiagnóstico, componentes redundantes, aparte de una implementación específica acorde a la instalación o infraestructura de la que van a formar parte. Los requisitos están regulados según el estándar bajo el estándar IEC-61508, habiendo otros como el IEC-61511 que lo complementa en cuanto a uso de los mismos.

Cuando un sistema SIS detecta una condición que supera, o va en contra, de lo programado, actúa llevando el proceso a un estado seguro o deteniendo la actividad. Por ejemplo, son los encargados de parar el brazo de un robot en caso de que la puerta de la jaula donde se ubique, se abra evitando que éste pueda golpear a un técnico o dañar las instalaciones. O bien, parar una cadena de montaje si alguno de los sensores infrarrojos que delimitan su perímetro, detectan la presencia de una persona mientras está en movimiento evitando algún tipo de golpe, lesión o atrapamiento.

Como decía al principio, en esta ocasión, el malware detectado no afecta a sistemas de control tradicionales sino SIS, lo que supone un cambio a lo que podríamos estar acostumbrados y una evolución en los ataques a elementos OT.

TRITON/TRISIS/HATMAN, según sea la fuente en la que nos basemos, permite realizar cambios en los controladores SIS del fabricante Schneider Electric modelo Triconex. Entre sus características destacamos la capacidad para leer programas, lectura y escritura de funciones, consultas del estado del controlador y otras adicionales que pueden ser implementadas por medio de payloads específicos.

Durante el incidente que supuso la posterior investigación y detección de este malware, algunos controladores entraron en un estado de “seguridad” provocado por un supuesto fallo y que automáticamente pararon el proceso.

El malware se compone de dos piezas fundamentales. Por un lado, un componente que reside en un equipo tipo PC que posee el software legítimo para la comunicación de los controladores y por otro, dos binarios que se descargan en el propio controlador para actuar sobre él.

Todo comienza con el compromiso de la estación de trabajo encargada de la comunicación contra estos controladores SIS y que emplea sistema operativo Windows. El malware es nombrado como si fuera la aplicación Triconex Trilog, cuya función es el análisis de logs de las estaciones Triconex y que se encuentra dentro de la suite TriStation. El malware es distribuido dentro de un ejecutable denominado “trilog.exe”. Se trata de un script escrito en Python empleando el compilador “py2exe”, el cual es entregado junto con un fichero “library.zip”. Éste, contiene las librerías necesarias para poder operar así como dos binarios necesarios “inject.bin” (código de función maliciosa) e “imain.bin” (control lógico malicioso) que serán enviadas al controlador para la interacción con él. FireEye lo resume así en la siguiente imagen:

Triton Trisis Hatman

Una vez iniciado “trilog.exe” se crea una instancia que comprueba el estado del controlador mediante al protocolo TriStation empleado por el software legítimo TriStation TS1131 para la configuración de los mismo a través del puerto UDP 1502. Si éste se encuentra operativo, conecta con él y pasa los binarios “inject.bin” e “imain.bin” a las librerías de comunicación para enviarlas y almacenarlas en la memoria del controlador.

Una vez allí, el script realiza comprobaciones periódicas para conocer el estado del controlador. Si éste presenta algún error intenta resetearlo a un estado previo mediante el protocolo TriStation. Si esto fracasa, intenta escribir datos falsos en esa misma memoria para borrar cualquier rastro y obstaculizar cualquier tarea forense para determina la causa que ha provocado el fallo.

Dicho protocolo, que no implementa medidas de autenticación y cifrado aunque pueden configurarse ACLs en los equipos que lo dispongan, no está documentado públicamente,. Por tanto hace entender que el autor debió realizar labores de ingeniería inversa para poder llevar a su implementación. El descubrimiento de controladores SIS puede ser realizado mediante el envío de paquetes broadcast usando UDP 1502.

Es importante señalar que los controladores Triconex disponen de un “switch” físico que permite conmutar entre los distintos estados en los que puede operar el equipo. Las configuraciones y cambios deben realizarse en modo “Program”, posición bajo la que podría actuar TRISIS. Sin embargo, si lo está en modo “Run” o “Remote” las modificaciones no están permitidas, con lo que reduciríamos la probabilidad de que pueda ser comprometido.

Así pues, se presentan, a priori, distintos escenarios con las consecuencias que podrían tener sus efectos. Estos podrían ser:

  1. Parada del proceso. Se provocan distintos cambios no autorizados que hagan que los equipos detengan su funcionamiento en previsión de consecuencias mayores.
  2. Programación errónea de dispositivos SIS. Introducir variables o parámetros que permitiesen la operación de las instalaciones bajo condiciones que entrañen peligro para personas y elementos físicos.
  3. Parada o alteración de planta. Dependiendo del impacto afectar a la actividad de la compañía.
  4. Daños físicos. Sin la capacidad de regularizar o parar la actividad en caso necesario, la maquinaria o sistemas no interrumpirían su funcionamiento y por consiguiente el correspondiente daño.

Al parecer, se tiene constancia de que al menos existe una víctima localizada en la zona de Oriente Medio, no trascendiendo su identidad. Dada la naturaleza, propósito, grado de conocimiento tanto tecnológico como de proceso que se requiere, hace pensar que una nación pudiera estar detrás de la autoría. No se aprecian objetivos ni intereses económicos lo que se podría descartar delincuencia organizada.

Sin bien debemos ser conscientes de este nuevo y preocupante escenario, hemos de contextualizar y valorar todas las pruebas existentes, evitando sensacionalismos y alarmas innecesarias. La Ciberseguridad Industrial es un tema álgido dentro de los profesionales del sector, por lo que debemos analizar las circunstancias, condiciones, requerimientos y tecnologías para que estos ataques tengan efecto. Algunos de ellos podrían ser:

  1. Aplica a equipos concretos de un determinado fabricante, no a todos.
  2. Debe darse la condición de que un conmutador físico debe estar en cierta posición.
  3. Alto conocimiento de esta tecnología.
  4. Conocimiento del proceso que se gestiona para poder actuar de forma dirigida y provocar el mayor daño o impacto posible.
  5. No seguir las principales recomendaciones o estándares en materia de Ciberseguridad Industrial. Dependiendo del tipo de compañía, infraestructura o sector esto pudiera ser más o menos probable. No podemos considerar una empresa del sector petroquímico que una manufacturera del sector automoción.

Por último, mencionar algunas recomendaciones que pueden evitar tanto la infección, como la propagación y posterior ejecución.

  1. Establecer una red físicamente independiente para los sistemas SIS.
  2. Implementar NGFW que filtren el tráfico de gestión hacia ellos.
  3. Aplicar Control de Aplicación, Antivirus e IDS/IPS a nivel de red en NGFW.
  4. Sobre la Workstation para sistemas SIS aplicar soluciones de Control de acceso, usuarios con permisos específicos, integración a posible Directorio Activo; Whitelisting de Aplicación [1], [2]; Control de dispositivos USB [1]
  5. Aplicar controles de acceso físico a dichos sistemas; cabinas, armarios, etc.
  6. Registro de logs o envío de eventos cada vez que se lleve a cabo alguna intervención sobre SIS.
  7. Verificar la posición correcta de conmutadores físicos, en este caso, modo “Run” o “Remote”.

Así pues, por esta y otras, amenazas, vectores de ataque e intereses de distinto tipo, resulta necesario tomar medidas y controles sobre nuestros entornos OT. Obviamente, cada infraestructura, organización o compañía será objeto de unas u otras dependiendo de la importancia estratégica, criticidad o actividad, despertando los intereses de agencias, gobiernos, competencia o delincuencia. No podemos tratar a todos por igual. Hemos de contextualizar y analizar de la manera que merece, con la inteligencia que requiere.

Un saludo, nos vemos en la próxima.

Referencias:

¡ Estrenamos cuenta en Twitter !

Con el objetivo cumplido para este 2017 y con ánimo de seguir llegando a más y más público, a partir de hoy está disponible bajo @enredandoconred nuestra cuenta en Twitter.

Diariamente se producen una buena cantidad de noticias, artículos, eventos, informes,  o textos relacionados con la Ciberseguridad en sistemas ICS/SCADA, Infraestructuras Críticas y demás Tecnologías de Operación. Por ello hemos visto que una buena iniciativa es redistribuir de forma rápida cualquier contenido interesante.

Así pues, os animamos a que nos sigáis y comencéis a recibir los tweets que vayamos publicando.

¡Un abrazo!

Edorta

¡Objetivo cumplido, muchas gracias!

No pensaba que a esta altura del año iba a escribir una entrada como la de hoy, pero para mi alegría así es. Y es que estoy de celebración.

Allá por el mes de diciembre del 2016 os contaba cómo, no sólo había superado las 30.000 visitas, sino que se había alcanzado la cifra de 32.378. A partir de ahí, el deseo de superar esa cifra para 2017.  Y con esa idea arrancamos el año.

Pues bien, hoy a punto de comenzar setiembre… ¡ya la hemos alcanzado!

Estadísiticas agosto 2017_01

Esto supone una gran alegría y estímulo ya que revela cómo año tras año este número crece, poniendo de manifiesto la cantidad de internautas, profesionales, investigadores y demás público, buscan, requieren o interesa el contenido relacionado con la Ciberseguridad Industrial.

Y como no podía ser de otra manera, me gustaría dar las gracias. Gracias a todos aquellos contactos y miembros de redes sociales como LinkedIn o Twitter por haber “recomendado”, “compartido” o “retuiteado” alguno de los artículos que por esas vías he ido anunciando. Por supuesto, también a los visitantes que a través de sus búsquedas han dado con el blog parándose a leer lo que allí había. A todos aquellos que de una manera u otra lo han hecho posible, ¡GRACIAS!

Representación 2017_01

Por otro lado también quisiera, además de agradecer, reconocer. Por un lado al Centro de Ciberseguridad Industrial por contribuir a la difusión de artículos haciendo referencias en su Boletín Semanal de todos los lunes. A José Valiente y Miguel García-Menéndez, muchas gracias.  Por otro, al blog Fortixpert, por incluir en su web posts donde se hablaba de funcionalidades de equipos Fortinet para cubrir las necesidades de protección en entornos industriales.  A Jose Luis Laguna, muchas gracias. A mi compañero Antonio Navarrete por abrirme las puertas a eventos y profesionales que han contribuido la difusión del blog. Como no, a Jon Bueno por las oportunidad de trabajar y aprender con él y de él, en el desarrollo del proyecto de Ciberseguridad Industrial en la fábrica de Mercedes-Benz sita en Vitoria-Gasteiz. Por último a Unai Gómez, quien con sus comentarios y aportes me han hecho ver algunos aspectos del blog en los que no había parado. A todos, ¡MUCHAS GRACIAS!

Con esta meta alcanzada, ahora queda ir pensado en los objetivos para el 2018. Quizás sea un poco pronto, pero ya estamos poniendo a echar a andar la maquinaria de cómo introducir novedades y otros apartados de interés.

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

¡Un abrazo!

Edorta

EuskalHack Security Congress II

Allá por junio del año pasado escribí una crónica de lo que fue el primer Congreso de Seguridad del País Vasco, el “EuskalHack Security Congress”. Este año, la asociación se ha puesto manos a la obra para no sólo organizar el segundo sino además, traer consigo algunas novedades para consolidarse como un evento obligado para investigadores, profesionales, amantes o interesados en estos temas.

Logo EuskalHack

Si bien algunos de los ponentes del 2016 repiten en esta edición, habrá muchos nuevos tanto a  nivel nacional como internacional y que seguro van a hacer las delicias de todos los que estemos allí. Los primeros en confirmarse fueron Halvar Flake, Alex Ionescu, Steve Lord y Joxean Koret, a los que han seguido Javier Marcos, Pedro Candel, Andoni Valverde, David Sancho, Pedro Sánches, Félix Brezo, Yaiza Rubio, Mikel Iturbe, Borja Martínez, Josep Albors, Eloi Sanfelix y Cristofaro Mune. 

Si bien la mayoría de ellos se desempeñan como profesionales en empresas como CounterCraft, Telefónica, TrendMicro, ESET, Riscure, Innotec, entre otros, también hay profesores e investigadores como por ejemplo de la Universidad de Mondragón.

Agenda_Día_1

Como miembro de la Asociación, puedo decir con conocimiento de causa que la elección de los ponentes ha sido muy dura, dejándonos con mal sabor de boca  dejar fuera de agenda otros con excelentes propuestas a la par que interesantes. A los que no podrán estar, cualquier agradecimiento es poco por querer compartir con nosotros sus trabajos y hacer crecer este evento.

Otras de las novedades será la impartición de 3 “Trainings” para los días previos. Los mismos serán:

  1. Hacking IPv6 Networks v4.0
  2. Bug hunting bootcamp Discovering 0day
  3. OSINT Tools and Techniques: A Practical Approach

Sin duda una gran oportunidad para formarse y ampliar conocimientos en estas materias.

Agenda_Día_2

El evento además cuenta con descuentos para los asistentes tanto en alojamiento como en transporte. Gesto que es de agradecer teniendo en cuenta aquellos que vienen de lejos  y que, como muchos, no se quieren perder la oportunidad de ver a estos “cracks” dando a conocer el resultado de la inversión de tantas horas de lecturas, práctica e investigación.

Todo esto, y más, lo podéis encontrar en la Web del Congreso . De más está decir que el aforo es limitado y que el precio de las entradas incrementará a medida que estemos más sobre la fecha. Dicho sea de paso, incluyen la comida para ambos días.

Por último agradecer a patrocinadores y colaboradores que con sus aportaciones económicas y contribuciones, hacen posible que este proyecto salga adelante. Sin duda se ha hecho mucho trabajo, pero queda otro tanto por hacer. Sin embargo estamos seguros que la recompensa será el mismo nivel de satisfacción y gratitud en todos los asistentes que se animen a venir y comprobarlo por ellos mismos. No te quedes con las ganas y disfruta con nosotros de Hacking, Pentesting, Reversing, Ciberseguridad Industrial, Exploiting en un lugar de excepción. Y es que, aunque San Sebastián sea nuestro “Centro de Operaciones”, Euskadi también está deseando darte la bienvenida.

Nos vemos el 23 y 24 de junio!

Un saludo.

Edorta

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!