Sin lugar dudas este ha sido un Incidente que llamó mucho la atención en todo el mundo. Dentro de la comunidad de aquellos que nos dedicamos a la CiberSeguridad Industrial sabemos que en Ukrania dedican gran cantidad de recursos a la protección de la Infraestructura Crítica, y especialmente en el sector de Energía, quizas porque ya han sido noticia en otros episodios del pasado. Desde el mes de diciembre del año pasado, habrían sido sorprendidos en un gran incidente. Todos nos preguntamos ¿Qué paso? ¿Cómo pudo haber sucedido cosa semejante en un pais en el cual se dedica una gran cantidad de recursos a la protección de la infraestructura Crítica?

Las estadísticas de incidencias y ataques a los Sistemas de Control (IACS, Industrial Automation Control Systems) van aumentando año tras año, y en todas partes del mundo, como en América, Europa, Asia, etc. Tanto en su cantidad, como en la técnica de penetración y el daño que estos incidentes van ocasionando a sus víctimas. Esto solo será motivo de análisis en uno de nuestros próximos artículos.

En general los ataques a la Infraestructura Crítica generados en las Redes de IT o más bien redes TCP/IP, muy dificilmente ocasionen daños significativos o tengan consecuencias sobre el mundo físico y sobre la población. El pasado 23 de diciembre de 2015, en la Zona oeste de Ukrania incluyendo la ciudad capital de Ivano-Frankivsk, más de 700.00 residentes y 200.000 industrias, sufrieron un prologado corte de energía como consecuencia de un CiberAtaque.

El análisis de este caso es especialmente valioso, para comprender cuál fue el impacto de este incidente que involucró a los Sistemas de Control y a la CiberSeguridad Industrial en su conjunto. La zona Oeste de Ukrania es operada por varias empresas privadas de transporte y distribución de energía. En este territorio las fuentes de Energía provienen principalmente de Centrales de Generación Térmica. Ukrania también tiene Centrales Nucleares pero no en esta región del pais. Hasta quizás se podría pensar que el golpe vino por el lado menos esperado.

El sistema interconectado eléctrico de uno de los países, con supuestamente la infraestructura crítica bien protegida, fue seriamente afectado.

El Gran Glope

El pasado 23 de diciembre de 2015, un día normal de trabajo en el crudo invierno, a las 16:00 hs una gran cantidad de usuarios e industrias ya no contaban con el suministro de energía eléctrica. La situación se comenzó a recuperar desde las 19:00 hs. Sabemos que esto es mucho tiempo, especialmente para los habitantes e industriales. No solamente por la cantidad de horas pero también por la inmensa cantidad de usuarios y una amplia región afectada. Los daños económicos fueron enormes. Sin embargo desde el punto de vista del tiempo de respuesta, y debido a la magnitud del incidente, el equipo de respuesta respondió de forma rápida. La mayoría de las compañías de energía en todas partes del mundo no habrían estado en condiciones de responder de la misma forma en tan poco tiempo. Cuando la gran mayoría se habría quedado totalmente  desconcertada, el equipo de respuesta supo cómo manejar la situación con efectividad.

La noticia del incidente comenzó a propagarse en todos los medios del mundo. Antes de fin de año ya era el incidente de CiberSeguridad Industrial más resonante del año. Las agencias de investigación de CiberSeguridad Industrial se mostraron sorprendidas y al a vez interesadas en colaborar con la investigación. ¿Qué sucedió? y ¿Cómo sucedió? Mientras el análisis y las pericias continuan, aún al día de hoy, varias cuestiones ya están muy claras.

1. BlackEnergy malware infectó varias computadoras de la Red de IT.

BlackEnergy (también conocido como DarkEnergy) es un malware que existe desde el año 2008 y cada uno de sus módulos ha ido mutando con el tiempo. En este incidente, la tercera variante de BlackEnergy fue utilizada como vector de ataque y ha brindado a los atacantes acceso a las computadoras de las empresas de distribución de energía, y la habilidad para comunicarse de forma remota a ellas. No se ha detectado que este malware haya llegado a las estaciones de operación de los Sistemas de Control. Sin embargo si es seguro que los intrusos han conseguido obtener y robar información del Sistema Interconectado Eléctrico. Uno de los módulos de BlackEnergy, conocido como KillDisk, fue utilizado para denegar el acceso de las computadoras corporativas como una de varias medidas de distracción y demora el mismo día del incidente. Informes previos, revelaron, que en el mes de Marzo se habrían detectado intentos de ingresos a las compañías eléctricas con la segunda versión de BlackEnergy. En el mes de Julio habría sesado el alerta de estos ataques. El mismo debió haber sido tomado como una advertencia y no como una acción que ya estaba controlada.

2. Un ataque afectó al mismo tiempo al sistema de Telefonía de varias de las empresas.

Otro ataque en simultáneo afectó al sistema de comunicaciones y telefonía de varias empresas de energía, posiblemente una denegación de servicio (DoS), evitó que la mesa de ayuda de las empresas de transporte de energía pudieran recibir los reclamos de los usuarios afectados. Esta situación ya está dando una clara evidencia que el Incidente fue absolutamente planeado. Los cortes de energía comenzaron bastante tiempo antes de que las empresas tomaran conciencia de lo que estaba sucediendo realmente. Una de las prestadoras llegó a colocar mensajes en sus paginas Web informado a sus visitantes que la empresa estaba teniendo problemas con el suministro de energía en varias localidades, pero no podrían precisar una hora de restablecimiento. La situación era crítica y No sabían lo que estaba sucediendo. Los golpes venian por todos lados.

3. Varios de los Sistemas de Control de las Sub-estaciones fueron comprometidos.

Cuando los equipos de respuesta fueron a re-establecer los sistemas de control de cada una de las sub-estaciones de energía tomaron cuenta que los Sistemas de Control en campo, PLCs y RTUs, también habían sido comprometidos. Con posterioridad se encontró que el firmware de los dispositivos estaban corruptos o modificados, y sus configuraciones habían sido alteradas. Los sistemas de control de 16 sub-estaciones se encontraron en estas condiciones. Otra clara evidencia que el incidente ocurrido No fue ninguna casualidad. Las empresas de distribución de energía eléctrica del oeste de Ukrania habían sido víctimas de un ataque intencionado, con una alta motivación y conocimiento técnico avanzado de los Sistemas de Control.

4. Las Estaciones de Operación de algunos Sistemas SCADA fueron accedidas de forma remota.

Un operador, minutos antes de realizar su cambio de turno, relató como repentinamente una fantasma tomó control de sus estación de trabajo, y comenzó a actuar sobre las sub-estaciones. En apenas unos pocos segundos fue testigo cómo el supuesto fantasma acabada de dejar sin energía a una gran cantidad de usuarios e industrias. Este fantasma fue capaz de sortear procesos de verificación y confirmación de las acciones del operador. El Operador No tuvo tiempo ni posibilidad de hacer nada para evitarlo. No se trataba de un fatasma! Los accesos remotos a través de los enlaces VPN, habían sido vulnerados. Estaban operando el SCADA desde el exteriory los Hackers tenían el control del sistema. Los operados ya No podían ver lo que estaba sucediendo. Sus Claves de acceso No funcionaban. Las mismas medidas de seguridad del propio sistema habían bloqueado a los Operadores de poder acceder.

Un operador del Sistema de Control ubicado en Prykarpattyaoblenergo, mientras estaba realizando su papeleo para finalizar su turno de trabajo, observó repentinamente como el cursor de su Estación de Operación del sistema, se desplazo repentinamente hacia una esquina de la pantalla. Rápidamente el cursor comenzó a realizar una serie de acciones sobre la pantalla y maniobras en las sub-estaciones. El operador fatasma seleccionó una subestación, fue directamente a ella sin perder tiempo, sabiendo exactamente dónde debía picar, seleccionó la subestación, dio la orden de apagar. El Sistema SCADA tiene una secuencia de confirmación, como es típico para los sistemas SCADA del tipo Eléctricos (Select Before Operate, y otras), dio la orden de apagar, confirmó la secuencia, como todo un experto y asi sucesivamente con las 30 sub-estaciones de esa operadora. Los diagramas unifilares y diferentes pantallas No son fáciles de comprender, y se debe tener un conocimiento de las Redes Eléctricas. El operador intentó detener este proceso, pero nada pudo hacer. Lo peor ya había comenzado, inclusive antes de este incidente. Cantidades de usuarios estaban sufriendo las consecuencias de los cortes de energía aún antes del incidente del operador. Esto no fue todo. Al mismo tiempo incidentes similares estaban sucediendo en otros centros de control de otras empresas de energía. La cantidad de Sub-estaciones que estaban siendo puestas fuera de servicio se multiplicaban rápidamente.

A poco más de tres meses de ocurrido el incidente y luego de conocer solamente algunos de los resultados de las investigaciones que se fueron conociendo, a través de las diferentes agencias de investigación, no cabe ninguna duda que se trató de un CiberAtaque … planeado, elaborado y ejecutado con una gran efectividad. Quizás los responsables pensarían que el daño que ocasionarían seria mucho mayor. La eficiente respuesta en el Recupero del Incidente por parte del equipo de Respuesta hizo que las pérdidas No fueran aún muchísimo mayores. ¿Qué habría sucedido si el incidente continuaba durante toda la noche?

Los responsables no fueron oportunistas. Sabían perfectamente lo que estaban haciendo y lo tenían absolutamente premeditado. Fueron estratégicos, detallistas y lo estuvieron planeado durante meses. Múltiples ataques orquestrados con sincronismo como una auténtica coreografía. Cuando la mayoría de las personas responsabilizan al malware, está claro que detrás de este incidente existió una importante logística y motivación. Ante estos hechos el malware pudo haber sido una distracción para ocultar los vectores reales del ataque. De hecho no fue encontrado ningún malware en los sistemas de control ni en las Estaciones de Operación de SCADA. Las protecciones instaladas en los sistemas para evitar el ingreso desde la red corporativa han demostrado ser efectivos. No obstante el grupo activista ante esta situación No se rindió y buscaron otras formas de ingresar a los sistemas de control.

Las diferentes perspectivas de los ataques. Cuando algunos creen que todos estos daños fueron causado por un hacker o un grupo de hackers desde las Redes de IT, sabemos que llegar al nivel bajo del control, esto No es posible. Los cambios de firmware y en la configuración y programación de los Sistemas de Control no es posible de realizar simplemente accediendo a las Sala de operación del SCADA Room, como relató uno de los operadores, o a través del BlackEnergy Malware encontrado en las Redes de IT. Especialmente en un SCADA Eléctrico con redes de varios años, donde para acceder al firmware de los dispositivos de campo, realizar modificaciones sin que esto despierte sospechas sin generar eventos, No es posible. Es indudable que hubo una tarea de inteligencia, hubo una planificación, y más aún, hubo un conocimiento No solamente de la Red Eléctrica de la región sino también del SCADA, PLCs, RTUs, comunicaciones y de sus vulnerabilidades. Se sabe además que la pérdida del sistema SCADA, en un sistema bien concebido, no genera la caída del suministro de la energía. Para ello se debería llegar a los PLCs y RTUs.

La causa Real

Si bien es técnicamente factible en condiciones de laboratorio, es muy improbable por no decir imposible que los sistemas de control en las subestaciones hayan sido alterados por el uso del BlackEnergy Malware. Para realizar los cambios encontrados en los PLCs y RTUs de campo en las Sub-estaciones se requiere de acceso directo y en muchos casos de un conocimiento muy específico, y software específico. Más aún estos cambios No son posibles de realizar en pocos minutos, se requiere de muchas horas para conseguir alterar los Sistemas de Control de forma semejante y más aún pasar inadvertido. Cambios en el firmware y en la configuración no es igual a realizar cambios en el nivel de supervision y de operación del SCADA que en el nivel del Control.

Creemos que otros incidentes y eventos aún No revelados tuvieron lugar. Es razonable que se genere la confusión por falta de conocimiento de la comunidad global. De hecho en la mayoría de los incidentes que han causado daños reales a las infraestructura física se ha subestimado la capacidad de los atacantes, como fue el caso de la Siderurgia Alemana, suponiendo que el acceso se realizó desde la Red Corporativa o desde Internet, lo cual ha sido falso en el 90% de los incidentes, o simplemente desde un acceso VPN. La intervención en el Sistema de Telefonía tampoco fue la causante de los apagones masivos. Esto sirvió para demorar al equipo de respuesta en detectar y tomar conocimiento del problema. Esto fue también una distracción.

Un informe del Energy Industry Research Center, describe a los sistemas SCADA de Ukrania como desactualizados tecnológicamente y que estos deberían ser renovados. Por lo tanto que se consiga tener acceso remoto de los PLCs y RTUs lo hacen todavía más improbable, por no decir imposible. Más aún cuando No fueron encontradas evidencias de BlackEnergy 3 en los sistemas de Control. Si fue el caso de Shamoon y Dragonfly en otros incidentes que sucedieron en el pasado. Sin embargo en esta oportunidad estamos frente a un hecho único. Se ingresó a los PLCs y RTUs y se realizaron modificaciones en ellos. Hasta inclusive cambios de firmware.

¿Cómo es posible que una “potencia” en CiberSeguridad sea victima de semejante ataque? ¿Cómo es posible que haya sido tan vulnerable? ¿Qué han estado haciendo durante todo este tiempo para proteger sus sistemas de control? Desde Ukrania rápidamente señalaron a los Rusos como responsables por el ataque. Sin embargo por el tipo y nivel de sofisticación de los trabajos realizados, el incidente debió ser causado por varios actores y/o participantes. Inclusive pudieron haber conseguido la colaborzación de partes completamente desconectadas o desinteresadas que por unos dólares son capaces de hacer cualquier cosa, sin medir las consecuencias. Desde Estados Unidos de América se reconoce que los Sistemas de Control de Ukrania son más seguros que los propios. Sin embargo para los atacantes pareció un trabajo fácil. Fallas en las medidas de seguridad. El acceso remoto VPN de los Sistemas SCADA tenía una único factor de autenticación, cuando debería tener un mínimo de dos.

El apagón llevó un total de 6 horas. Sin embargo aún después de tres meses de lo sucedido los sistemas de control no están totalmente operativos. Varias de las sub-estaciones continúan siendo operadas manualmente. Restablecer los sistemas de control donde ya nada se puede subestimar no es sencillo. Es necesario recuperar, probar y verificar el sistema en un nivel de detalle lleva semanas. Ni siquiera pueden confiar en las copias de respaldo. Aún así No pueden volver a dejar a los sistemas tal y como estaban antes del incidente. Se quiere modificar todo!!! De lo contrario, lo mismo volverá a suceder.

Un Plan Brillante

Primera Fase: Durante los relevamientos no fueron encontradas evidencias de que el Malware BlackEnergy3 haya alcanzado los sistemas de control. Por el contrario todo parece indicar que las medidas de protección para evitar intrusiones desde el área corporativa hacia los sistemas de control fueron efectivos. Los ataques habrían comenzado varios meses antes en las Redes de IT. Los atacantes No se dieron por vencidos y buscaron otras vias de ingreso a los sistemas de control. Estos ataques en las áreas de IT fueron ejecutados a través del envío de correos electrónicos, con documentos de Word que pedían permiso para ejecutar macros. Estas macros tendrían el malware. Aún ganando acceso a las computadoras de los perfiles de administrador, no consiguieron llegar a los sistemas de control. Los diferentes cortafuegos y logs evidenciaron que todos los intentos de ingreso fueron bloqueados. Lo que si faltó fue un análisis adecuado a tiempo. Los atacantes tenían dos opciones. Buscar vulnerabilidades en los cortafuegos y barreras de ingreso a los sistemas de control desde la redes de IT, o buscar vias alternativas de ingreso. Los atacantes finalmente optaron por la segunda opción. Deberían conseguir uno o más accesos directos a los sistemas de control de las múltiples empresas de distribución de energía.

Segunda Fase: Los atacantes comenzaron a buscar formas de ingreso alternativas. Consiguieron ingresar al servidor de dominio y robaron las credenciales de ingreso a través de las VPN de varios SCADA. Una vez que consiguieron ingresar a la Red del Sistema SCADA comenzaron a tejer su estrategia. Reconfiguraron las UPS en dos de los Sistemas de Control. Además de dejar sin energía a los habitantes consiguieron dejar ciegos a los operadores, pero No consiguieron realizar esta movida en los demás sistemas. En algunos sistemas simplemente consiguieron freezar las pantallas de los operadores. Fue suficiente para que no pudieron ver lo que pasaba en campo. Las diferencias tecnológicas de los diferentes sistemas de control, fue brindando diferentes oportunidades de ingreso. Las compañías utilizaban diferentes DMS (Distribution Management Systems). Consiguieron modificar el firmware en diversos equipos y dispositivos de comunicaciones de red. Además llegaron a cambiar el firmware en varios Sistemas de Control, por lo menos en un mínimo de 16 sub-estaciones. Es la primera vez que se detecta un caso semejante, donde los actores consiguen realizar un cambio de firmware en los Sistemas de Control. Desde la perspectiva de un ataque fue toda una ingeniería. Una vez conseguidos todos estos cambios, ya estaban listos para ejecutar su ataque.

Tercera Fase: una vez desplegadas una suficiente cantidad de vectores de ataques, y caballos de troya, lo que debían de hacer para que el ataque sea efectivo y tuviera un gran impacto, fue actuar de forma coordinada. Y así lo hicieron.

El servicio de suministro de energía eléctrica fue restituido casi en su totalidad de forma manual. El equipo de respuesta observó que era la única forma que tenían para recuperar el servicio de energía. (No se sabía lo que estaba pasando hasta después de varias semanas y meses de analizar los sistemas.) Debían hacerlo de forma manual sin contar con la ayuda de los sistemas de control. En este caso fue posible, sin embargo, en las redes eléctricas más modernas esto no sería posible y para restablecer el servicio deberían recuperar a los sistemas de control primero.

¿Cómo protegerse?

Sabemos que en Ukrania invierten una gran cantidad de recursos para proteger su infraestructura Crítica. No obstante aún siendo un pais preparado en materia de CiberSeguridad han sido víctimas de uno de los ataques más temidos. Esto también pone en evidencia que la estrategia de defensa debe ser implementada en múltiples capas. No basta con proteger una sola entrada. Esto es como pretender proteger a nuestro hogar vigilando únicamente la puerta de servicio. Para que un sistema de CiberDefensa Industrial sea efectivo, se debe implementar tanto una Detección Comprensiva como una Protección Comprensiva. Se deben vigilar y proteger todas las puertas, todas las ventanas, hasta la entrada del perro o del gato, la chimenea y la cochera. No basta con proteger las Redes de Datos TCP/IP, como se está realizando en la mayoría de los casos. Se debe implementar un sistema de CiberDefensa que sea comprensivo. De lo contrario todo el esfuerzo puede ser en vano.

Una mirada cauta del incidente

Estemos alertas en la medida que más informaciones va siendo revelada. Al igual que con el caso de Stuxnet llevó un bien tiempo conocer todo lo que sucedió realmente. Esta no sera una excepción.

Lección #1: Los atacantes precisaron de un mínmo de 6 meses de reconocimiento, investigación y orquestración para perpetrar su ataque. Con las herramientas adecuadas, y las hay de uso libre, las actividades de este grupo habrían sido detectadas.

Lección #2: Las conexiones remotas de los Sistemas SCADA y/o Sistemas de Control deben tener por lo menos dos factores de autenticación.

Lección #3: Las Fuentes de Alimentación y UPS de los Sistemas de Control son tan críticas como el propio Sistema de Control. Estas deben ser seguras y confiables.

Lección #4: Las Actualizaciones de firmware de los Sistemas de Control también son un vector de ataque válido y muy crítico, que la mayoría de los actores de la comunidad aún no lo tienen tran presente.

Lección #5: Se debe implementar un Sistema de Detección Comprensiva como así también de Protección Comprensiva. No basta con proteger solamente algunos de los puntos de ingreso.

Lección #6: Se debe conducir un estudio comprensivo de identificación de vulnerabilidades y evaluación de riesgos a la CiberSeguridad Industrial antes de implementar las medidas de protección. Al no hacerlo se corre un alto riesgo de subestimar a los atacantes. Ya sean intencionados o no intencionados.

Lección #7: Toda la información, documentación y detalles que describen el funcionamiento de la Red Eléctrica como de la arquitectura de los Sistemas de Control debe ser asegurada. Esta puede brindar a los interesados atacantes la información necesaria para identificar las vulnerabilidades en los Sistemas de Control.

¿Cuándo fue la última vez que Ud. efectuó en su compañía una revisión de su Plan de Respuesta a Incidentes en su planta o procesos? ¿Acaso tiene un plan de respuesta? ¿Está su gente mental y psicológica preparada para responder a este tipo de incidentes? ¿O le agarrarían totalmente por sorpresa con los pantalones bajos? ¿Podría su organización responder ante algo similar? ¿Tiene Ud. realizada una Evaluación de Riesgos a la CiberSeguridad Industrial? ¿Está al tanto de lo que puede llegar a pasar en sus procesos? ¿Cuál es el estado actual de sus CiberDefensas? ¿Está siguiendo alguna metodología? ¿Cuál? ¿Es la correcta?

En resumen, aún si Ud. no está en la industria eléctrica, este incidente es una muy buena oportunidad para observar, aprender y analizar cuál es su situación actual. Para todos aquellos proveedores de Sistemas y Servicios de procesos críticos, es vital aprender de estos casos.

¿Le gustaría dejar sus opiniones y comentarios acá abajo en este lugar? Escríbanos a support@wiseplant.com