Las importantes filtraciones de datos en la plataforma de venta de entradas en línea Ticketmaster y el banco de consumo Santander parecen estar relacionadas con el abuso de cuentas no seguras mantenidas en la plataforma de gestión de datos en la nube Snowflake, según se ha revelado en los últimos días.
En la infracción de Ticketmaster, confirmada el viernes 31 de mayo por la organización matriz Live Nation, se robaron los datos personales de más de 550 millones de clientes, incluidos nombres, direcciones, números de teléfono y algunos datos de tarjetas de crédito.
En el actual incidente en Santander se han robado datos de clientes en España y América Latina, así como información personal de algunos empleados anteriores y actuales del banco, que suman 200.000 personas en todo el mundo y unas 20.000 en el Reino Unido.
Ambos incidentes han sido reivindicados por un grupo conocido como ShinyHunters, que también operaba el sitio BreachForums que recientemente fue cerrado por la policía pero que parece seguir operando con impunidad. Los ciberdelincuentes exigen un rescate de medio millón de dólares a Ticketmaster y dos millones de dólares a Santander.
Aunque ninguna de las organizaciones nombró explícitamente a Snowflake, la empresa confirmó que estaba investigando una “campaña de amenazas dirigida” contra las cuentas de los clientes, con la ayuda de CrowdStrike y Mandiant.
En un comunicado, Snowflake dijo: “No hemos identificado evidencia que sugiera que esta actividad fue causada por una vulnerabilidad, mala configuración o violación de la plataforma de Snowflake. No hemos identificado evidencia que sugiera que esta actividad fue causada por credenciales comprometidas del personal actual o anterior de Snowflake.
“Esta parece ser una campaña dirigida a usuarios con autenticación de un solo factor. Como parte de esta campaña, los actores de amenazas han aprovechado credenciales previamente compradas u obtenidas mediante malware de robo de información”.
Credenciales personales
Además, confirmó que había encontrado alguna evidencia de que un actor de amenazas había obtenido credenciales personales y accedido a cuentas de demostración pertenecientes a un ex empleado de Snowflake, que no estaban protegidas por sus servicios Okta o de autenticación multifactor (MFA), pero que estas cuentas no estaban protegidas por sus servicios Okta o de autenticación multifactor (MFA). conectado a sus sistemas de producción o corporativos y no contenía ninguna información sensible.
Snowflake recomienda a sus clientes implementar MFA de inmediato, establecer reglas de política de red para permitir solo usuarios autorizados o tráfico desde ubicaciones confiables y restablecer y rotar sus credenciales. Más información, incluidos indicadores de compromiso, está disponible aquí.
Reclamaciones en disputa
Según el testimonio de Snowflake, los problemas parecen haber sido causados por fallas de seguridad cibernética de sus clientes. Sin embargo, su versión de los hechos está muy en desacuerdo con otra información que ha estado saliendo a la luz en los últimos días, gran parte de ella contenida en un blog ya eliminado, que está archivado en su totalidad aquí, publicado por investigadores de Hudson. Roca.
Basado en una conversación con alguien que decía ser un miembro de ShinyHunters, Hudson Rock dijo que a sus investigadores se les dijo que, contrariamente a la versión de Snowflake, los atacantes en realidad habían accedido a la cuenta ServiceNow de un empleado de Snowflake usando credenciales robadas, evitando las protecciones de Okta y generando tokens de sesión que les permitieron para robar los datos de sus clientes directamente de los sistemas de Snowflake.
El actor de amenazas compartió información que sugería que al menos 400 clientes se habían visto comprometidos a través de su acceso, y parecía sugerir que habían estado buscando una recompensa de Snowflake en lugar de sus clientes, aunque es importante recordar que nunca es prudente confiar en la palabra de un ciberdelincuente o tomar sus afirmaciones al pie de la letra.
Identidad del vector
Aunque no es un ejemplo clásico de un ataque a la cadena de suministro (según la lectura de eventos de Snowflake), los incidentes en Ticketmaster y Santander tienen mucho en común con otros ataques a la cadena de suministro, incluido el uso de compromisos de identidad como vector de acceso.
“Este año, hemos visto una secuencia de infracciones que han afectado a importantes empresas de software como servicio. [SaaS] proveedores, como Microsoft, Okta y ahora Snowflake”, dijo Glenn Chisholm, cofundador y director de producto de Obsidian Security.
“Lo que tienen en común estas violaciones es la identidad; los atacantes no entran por la fuerza, sino que inician sesión”, dijo. “En los compromisos de respuesta a incidentes que hemos visto a través de socios como CrowdStrike, vemos que las infracciones de SaaS a menudo comienzan con compromisos de identidad; de hecho, el 82% de las infracciones de SaaS se derivan de compromisos de identidad como el phishing, el robo y la reutilización de tokens, la ingeniería social del servicio de asistencia técnica, etc. . Esto incluye identidades de usuarios así como identidades no humanas (de aplicaciones)”.
Las lecciones para los usuarios son claras, afirmó Chisholm. SaaS es un espacio muy específico con múltiples ataques que ocurren en todo el espectro, desde atacantes de estados nacionales hasta piratas informáticos con motivación financiera como ShinyHunters. Como tal, toda empresa que utilice productos SaaS debe implementar un programa de seguridad SaaS o revisar los existentes.
“Asegure la postura correcta de las aplicaciones para minimizar el riesgo, proteja sus identidades que forman el perímetro de sus aplicaciones SaaS y asegure su movimiento de datos”, dijo Chisholm. “Estos deben ser un programa continuo ya que sus aplicaciones evolucionan, las configuraciones cambian, se introducen identidades y los atacantes cambian sus patrones. En otras palabras, necesita automatización para escalar esto en todas sus aplicaciones SaaS”.
Toby Lewis, jefe de análisis de amenazas de Darktrace, dijo que incluso si ningún sistema Snowflake se hubiera visto directamente comprometido, el proveedor aún podría haber hecho más para prevenir los ataques a sus clientes.
“Los proveedores de la nube deberían fomentar mejores prácticas de seguridad, como la MFA obligatoria, incluso sin requisitos explícitos para que lo hagan bajo el modelo de responsabilidad compartida”, dijo Lewis.
“En esencia, se convierte en un diferenciador al sopesar diferentes proveedores de nube: elija el que tenga prácticas seguras por defecto para mejorar la seguridad general”.