Por Milton Quiroga, gerente general de Cyte

Se estima en más de 18.000 las organizaciones afectadas por este mega-ataque cibernético, entre las cuales se encuentran Microsoft, Intel, Cisco, Nvidia, VMware, Belkin, FireEye, Deloitte, Mount Sinai Hospital, Ciena, NCR, SAP y Digital Sense. Así como los departamentos de Commerce, Defense, Energy, Homeland Security, State, Treasury y Health (https://www.datacenterknowledge.com/security/list-known-solarwinds-breach-victims-grows-do-attack-vectors). Sin embargo, el número final de víctimas sigue creciendo día a día y es posible que el número final pueda llegar a ser mucho más grande.

Sin embargo, debido a las festividades de fin de año y las perspectivas sombrías del COVID 19, este ataque, que tiene todos los ingredientes de un episodio de guerra cibernética y de espionaje a gran escala, pasó de agache en los medios de comunicación.

En efecto, desde el 12 de diciembre fue evidente que la compañía Norteamericana SolarWinds® había sido víctima de un ataque <supply chain>, orquestado desde Rusia. Por eso el propósito de este breve artículo es describir lo que se sabe del ataque hasta este momento y aventurar algunas reflexiones para la gestión de la ciberseguridad de las organizaciones en el mundo.

Cronología

El 12 de diciembre de 2020, se encontró evidencia que una pieza de malware llamada <Sunburst/Sunspot> había sido inyectada en la plataforma Orion® de SolarWinds®, presumiblemente por un grupo de hacking (Turla APT) vinculado con el gobierno ruso. Dado que la tecnología de monitoreo y gestión remota de software de SolarWinds® es ampliamente usada por grandes compañías y el mismo gobierno federal, este incidente de hacking rápidamente escaló a conflicto de espionaje y ciberguerra (https://www.wsj.com/articles/solarwinds-discloses-earlier-evidence-of-hack-11610473937).

Sin embargo, la cronología del ataque parece empezar en septiembre del 2019, con un primer ataque indetectado que consiguió vulnerar la infraestructura de desarrollo y distribución de software de SolarWinds®. Al parecer el ataque se concentró en los servicios de autenticación de Microsoft®365 y el directorio de Azure® para substraer algunas credenciales de usuarios. Con estas credenciales tomadas, un mes después consiguieron inyectar código en el producto estrella de SolarWinds® (Orion®), en una especie de ‘prueba de concepto’ que pasó sin ser detectada, ni por el área de infosec de SolarWinds®, ni por las sofisticadas herramientas ‘Einstein’ de detección de ciberamenazas del gobierno federal.

Una vez pudo el atacante incluir subrepticiamente código en la distribución de Orion®, al parecer estuvo hasta febrero de 2020 instalando un servicio de comando y control, con servidores en Europa y USA que imitaban bastante bien el tráfico normal de usuarios legítimos de SolarWinds®. Con las credenciales robadas del servicio de autenticación de Microsoft®, los atacantes no solo incluyeron código malicioso en el código base del producto Orion®, sino que también lograron suplantar usuarios de las compañías clientes de SolarWinds® en una seguidilla de ataques cuyo alcance y profundidad todavía está pendiente de determinar y que -es vox populi en el medio- afectó a decenas de organizaciones en Latinoamérica.

Un <supply chain attack>

Dado que este ataque se realizó vulnerando la tecnología de fabricación y distribución del software de SolarWinds® (i.e equivalente a la ‘cadena de distribución’ de una empresa comercial, aplicando a empresas fabricantes de software), se ha dado en llamar por sus similaridades un <supply chain attack>. De acuerdo con algunos de los análisis forenses publicados (véase https://www.helpnetsecurity.com/2021/01/12/solarwinds-sunspot/), cuando el malware SunSpot detectaba en el proceso de compilación e integración de Orion® la invocación del proceso MsBuild.exe, de las herramientas de desarrollo de VisualStudio® de Microsoft®, inyectaba antes de la compilación en el código fuente de Orion® herramientas de hacking como Cobald Strike, que terminaban instaladas en los sistemas de información de los clientes de SolarWinds®. Estas herramientas pasaban una temporada de letargo de un par de semanas, antes de empezar a catapultar información sensible de los usuarios que luego pasaban a randomware o a servidores de la dark-web.

Dadas las características de sigilo de operación del ataque, este permaneció más o menos indetectado durante una buena parte del 2020, hasta que uno de los empleados de la empresa de seguridad FireEye, víctima del ataque, notó un comportamiento extraño en los servidores y en un trabajo de cooperación entre las áreas de seguridad de la información, seguridad informática y tecnología y gracias a una revisión cuidadosa de los logs de acceso, FireEye detectó indicios del ataque. Solo hasta el 7 de diciembre del 2020, el Centro de Atención de Incidentes de Estados Unidos emitió una alerta, quizás tardío (https://us-cert.cisa.gov/ncas/alerts/aa20-352a).

Precisamente una de las primeras ‘ordenes ejecutivas’ firmadas por el Presidente Joe Biden tiene que ver con el manejo como nación el hack de SolarWinds® (https://www.cnet.com/news/biden-reportedly-gathers-cybersecurity-experts-in-wake-of-solarwinds-hack/?ftag=CAD090e536&bhid=19885658988148128355713903297861&mid=13243358&cid=643612568).

Reflexiones

Aún sin saber el impacto final de ataque, es posible aventurar algunas reflexiones y moralejas provisionales que pueden ser útiles. La primera reflexión que podamos obtener tiene que ver con la misma naturaleza de los ataques <supply chain >. Durante mucho tiempo en seguridad de la información se creyó que la fuente de los ataques eran los usuarios negligentes y su actitud descuidada hacía los procedimientos definidos por infosec.

Se decía que la fuente de los problemas era el usuario que descuidadamente instalaba malware o hacía click en enlaces a sitios problemáticos o era vulnerable a correos fishing. El ataque de SolarWinds® y en general cualquier ataque <supply chain> no apunta a los usuarios, apunta a la infraestructura de back-end y sus procesos de actualización de software. Quizás es el momento de ya no culpar más al usuario final e insistir en campañas de sensibilización, descuidando la infraestructura automática de actualización de la plataforma IT.

Una segunda reflexión tiene que ver con la forma en que el ataque se detectó. Nótese que el ataque no fue detectado con los procedimientos usuales de monitoreo que disparan una alarma ante el comportamiento sospechoso de algún usuario o ante la descarga de un malware o actividad inusual en la red. Ante estos ataques <supply chain> simplemente estos procedimientos permanecerián silentes. Finalmente el ataque fue detectado por un acucioso empleado de FireEye que se dio en el trabajo de revisar bitácoras históricas juntos con empleados de área de TI.

Y esta es una moraleja muy importante: las áreas infosec más que ser áreas ‘rectoras’ que emiten directrices de seguridad de la información, deben buscar participar activamente en la revisión de bitácoras de auditoría y en la elaboración de líneas de base de detección de anomalías.

Esta recomendación de ‘visibilidad’ de la infraestructura de TI por parte del área infosec y el trabajo coordinado de las áreas de TI de software, de gestión de data centers, infosec y seguridad informática, es un tema todavía pendiente para muchas de las organizaciones en America Latina.

Finalmente, la cuarta y última reflexión tiene que ver on el nivel de sofisticación del ataque. Claramente es un ataque de ciberguerra que vulneró la <supply chain> de un fabricante de software (SolarWinds®)y que a través de este proveedor tuvo alcance en miles de organizaciones que incluían la tecnología de SolarWinds® en sus procesos de negocio. Quizás algunas de las organizaciones víctimas de este hack despertaron un día viéndose víctimas colaterales del fuego cruzado de un escenario de ciberguerra, del cuál quizás no se sintieron nunca invitados.