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 Ucrania dedican gran cantidad de recursos a la protección de la Infraestructura Crítica, y especialmente en el sector de Energía, quizás 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 país 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 difícilmente 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 Ucrania, 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 Ucrania 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. Ucrania también tiene Centrales Nucleares, pero no en esta región del país. 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 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 manera 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 a la vez interesadas en colaborar con la investigación. ¿Qué sucedió? Y ¿Cómo sucedió? Mientras el análisis y las pericias continúan, 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 usado 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 cesado 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 páginas Web informando 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 venían 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 Ucrania 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 un fantasma tomó control de su estación de trabajo, y comenzó a actuar sobre las sub-estaciones. En apenas unos pocos segundos fue testigo cómo el supuesto fantasma acabó 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 fantasma! Los accesos remotos a través de los enlaces VPN, habían sido vulnerados. Estaban operando el SCADA desde el exterior 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 desplazó repentinamente hacia una esquina de la pantalla. Rápidamente, el cursor comenzó a ejecutar una serie de acciones sobre la pantalla y maniobras en las sub-estaciones. El operador fantasma 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 así 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 sería 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 planeados durante meses. Múltiples ataques orquestados 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 causados 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 la 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.
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 ejecutar 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 efectuar cambios en el nivel de supervisión 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 la 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 Ucrania 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 víctima 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 Ucrania 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 ejecutados, el incidente debió ser causado por varios actores y/o participantes. Inclusive pudieron haber conseguido la colaboració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 Ucrania 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 un ú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. Aun 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.
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 vías 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 red de IT, o buscar vías 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 congelar 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 efectuar 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 trolla, 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 manera manual. El equipo de respuesta observó que era la única manera 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 manera 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.
Sabemos que en Ucrania invierten una gran cantidad de recursos para proteger su infraestructura Crítica. No obstante, aún siendo un país 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.
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 será una excepción.
Lección #1: Los atacantes precisaron de un mínimo de 6 meses de reconocimiento, investigación y orquestació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 tan 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, aun 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
Get Involved & Participate!
Comments