IDC Frontier vincula ransomware a falla en código abierto

IDC Frontier, la subsidiaria en la nube de SoftBank, publicó el martes (27) su séptimo informe sobre el ataque de ransomware que afectó a parte de IDCF Cloud el 7 de octubre y que impactó a 495 empresas y gobiernos locales en Japón. Según el documento, la puerta de entrada fue una vulnerabilidad en un software de código abierto utilizado por el sistema de autenticación del portal de clientes, el IDCF Cloud Portal. La empresa no reveló el nombre del componente ni un identificador CVE.

La secuencia descrita por el proveedor, según la cobertura de ITmedia, Business+IT y la agencia Jiji, fue la siguiente: el invasor ingresó al sistema de autenticación, llegó al consola de gestión, obtuvo privilegios de administrador de la plataforma de virtualización y, a partir de allí, apagó y cifró máquinas virtuales de clientes. El ataque comenzó alrededor de las 3:40 a.m., hora de Tokio.

Qué fue expuesto y qué no

IDC Frontier afirma no haber encontrado indicios de que datos dentro de los servidores virtuales de los clientes hayan sido copiados. Sin embargo, el registro de clientes en el portal fue consultado indebidamente en hasta 71 cuentas, frente a 48 en el informe anterior, del 14 de octubre. En hasta 31 de ellas había nombres o direcciones de correo electrónico. Las contraseñas de inicio de sesión fueron alteradas por el invasor en hasta cuatro casos, y esos clientes fueron contactados individualmente.

El proveedor declaró que no ha pagado rescate ni negociado con los atacantes. En el informe del 14 de octubre, había indicado que las copias de los snapshots podían ser recuperadas para 194 de los 495 clientes afectados, quienes habían contratado esta función.

Entre las medidas anunciadas están la creación de una unidad independiente dedicada a la seguridad, la inclusión de software de código abierto en el alcance de las pruebas de vulnerabilidad, la adopción de inventario de componentes de software (SBOM) y la migración de la autenticación a un proveedor de identidad externo.

El efecto en cadena

El alcance del incidente va más allá de la lista de clientes directos. JR East y su operadora de tarjetas View Card informaron que alrededor de 6,09 millones de registros de cuentas, en su mayoría direcciones de correo electrónico, podrían haber sido expuestos en servicios alojados en la plataforma. Sitios del gobierno de la provincia de Ibaraki y de la policía provincial quedaron fuera de servicio, según SoftBank, en un reporte de la agencia Kyodo.

El caso se suma al de GMO Internet, que suspendió el 21 de octubre el servicio Onamae.com Desktop Cloud tras identificar un programa malicioso en los servidores de clientes, con hasta 26,739 servidores potencialmente afectados, según la empresa. Esta secuencia llevó a la primera ministra Sanae Takaichi a determinar, el 26 de octubre, que el gabinete preparara en aproximadamente una semana un paquete emergente de ciberseguridad.

Por qué la falla del portal importa fuera de Japón

El punto técnico del informe es menos exótico que el tamaño del daño. El invasor no quebró el hipervisor. Ingresó a través de una biblioteca de autenticación de código abierto en el portal de autoservicio, la capa que casi todo proveedor regional de nube construye sobre componentes públicos. La inclusión del código abierto en el alcance de las pruebas de vulnerabilidad, listada entre las correcciones, muestra que estaba fuera de ese alcance hasta el ataque.

Hay quien ve el episodio como un argumento en contra de proveedores regionales y a favor de las tres grandes nubes americanas. El argumento tiene un límite: AWS, Microsoft y Google también dependen de componentes abiertos, y Microsoft tuvo en 2023 una clave de firma robada por el grupo Storm-0558, que la usó para acceder a correos electrónicos de clientes. La distinción relevante es otra: el tamaño del equipo que inventa y prueba estas dependencias, y si la consola de gestión está separada de la autenticación del cliente.

En la Unión Europea, la directiva NIS2 ya obliga a los proveedores de nube a gestionar riesgos de la cadena de suministro de software y a enviar alerta inicial a las autoridades en un plazo de hasta 24 horas tras tener conocimiento de un incidente significativo. Un caso como el de IDCF Cloud caería en este régimen desde el primer día.

En Brasil, la Resolución CD/ANPD nº 15, de 2024, otorga a los controladores tres días hábiles para comunicar incidentes con datos personales. La obligación recae sobre cada cliente, no sobre el proveedor de nube. Un ataque con cientos de clientes afectados, como el de IDCF Cloud, obligaría a cientos de empresas a notificar a la ANPD al mismo tiempo, todas dependiendo de información que solo el proveedor tiene.

El informe de IDC Frontier tardó tres semanas en nombrar la causa y aún no identifica el componente. Para quienes contratan nube regional, la pregunta que hacer al proveedor dejó de ser si tiene respaldo. Pasó a ser quién prueba el código abierto del portal de inicio de sesión y con qué frecuencia.