Filtración de datos de Snowflake: hacker confirma acceso mediante infección con infostealer

• El 31 de mayo de 2024, la empresa de nube Snowflake sufrió una filtración masiva de datos
• El hacker confirmó a Hudson Rock que obtuvo acceso mediante una infección con infostealer
• El hacker vendió datos de varias grandes empresas, incluidas Ticketmaster y el banco Santander, en foros rusos de ciberdelincuencia

Método del hackeo

• El hacker inició sesión en la cuenta de ServiceNow de un empleado de Snowflake usando credenciales robadas.
• Eludió OKTA para generar un token de sesión y exfiltrar grandes volúmenes de datos.
• El hacker afirma que unas 400 empresas se vieron afectadas.

Evidencia adicional

• El hacker compartió con investigadores de Hudson Rock un archivo CSV que muestra acceso a servidores de Snowflake.
• Este archivo documenta más de 2,000 instancias de clientes relacionadas con los servidores europeos de Snowflake.

Objetivo del hacker

• El hacker exigió 20 millones de dólares a Snowflake a cambio de recuperar los datos.
• La empresa no respondió.

Aumento de las infecciones con infostealer

• Las infecciones con infostealer aumentaron 6000% desde 2018, consolidándose como un vector principal de ataque inicial.
• Se usan para ejecutar ciberataques que incluyen ransomware, filtración de datos, toma de cuentas y espionaje corporativo.

Opinión de GN⁺

• Importancia de la ciberseguridad: Este incidente muestra que las empresas deben prestar aún más atención a la ciberseguridad. En especial, es clave la gestión de credenciales de los empleados.
• La amenaza de los infostealers: Los infostealers se están propagando muy rápido, y las empresas deben preparar medidas de defensa ante esta amenaza.
• Estrategia de respuesta: Cuando ocurre un incidente de hackeo, se necesita una respuesta rápida y una estrategia para minimizar daños. La respuesta tardía de Snowflake amplió el impacto.
• Capacitación en seguridad: Es importante reforzar la capacitación en seguridad para que los empleados mejoren la gestión de credenciales y la conciencia frente a ataques de phishing.
• Soluciones alternativas: Se pueden considerar otras soluciones de almacenamiento en la nube con funciones similares a Snowflake, por ejemplo AWS S3 o Google Cloud Storage.

[GN⁺]

Comentarios de Hacker News

• La URL enlazada actualmente hace redirección 302 a /. @dang, parece mejor reemplazarla por el enlace de archivo de abajo
  https://web.archive.org/web/20240531140540/https://www.hudso...

  • Llamar a @dang no surte ningún efecto, así que sería mejor contactarlo al correo del pie de página
    Aun así, que Hudson Rock haya bajado la publicación del blog también es una señal interesante, así que no deberíamos simplemente cambiarlo por el enlace archivado y seguir adelante. ¿Qué cambió?
    Actualización: la respuesta oficial de Snowflake parece negar de hecho casi todas las afirmaciones clave del artículo original. También podría ser que Hudson Rock haya sido engañado por una fuente poco confiable y, al darse cuenta del error, haya retirado la publicación
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

• Soy Felipe de Snowflake. La postura más reciente de Snowflake sobre este tema está aquí: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  Seguiré actualizando esta URL si hay novedades

  • El enlace está demasiado lleno de lenguaje corporativo, así que quiero confirmar algo con claridad. La publicación de Hudson Rock afirma explícitamente que las brechas de Ticketmaster y Santander Bank ocurrieron por credenciales robadas de empleados de Snowflake
    Sin embargo, la frase de Snowflake: “Similar a las cuentas de clientes afectadas, encontramos evidencia de que el actor de amenaza obtuvo credenciales personales y accedió a una cuenta demo propiedad de un ex empleado de Snowflake. No había datos sensibles”, se lee como que Snowflake considera falsa la explicación de Hudson Rock. ¿Es correcta esa interpretación?
  • El texto original de Hudson Rock se entiende no como que simplemente se comprometieron las credenciales de un cliente, sino que se robaron credenciales de empleados y, como no había autenticación de dos factores, se entró a otras cuentas de clientes con los permisos de ese ingeniero
    En cambio, la publicación de Snowflake da la impresión de que se filtraron credenciales de cuentas de clientes y ahí terminó todo, sin acceso a una cuenta central ni a otras cuentas. Tampoco dice nada sobre el uso de información de una cuenta de empleado sin autenticación de dos factores
    Está claro que Snowflake querría autenticación de dos factores en todas las credenciales de acceso interno de sus empleados. Antes, si el cliente quería, podía crear solo nombre de usuario y contraseña para iniciar sesión en sus propios datos y acceder sin autenticación de dos factores
  • ¿Habrá algún comentario directo sobre este artículo?
  • Solo me aparece un mensaje de que el servidor de salesforce.com temporalmente no puede responder a la solicitud, disculpándose por las molestias y pidiendo intentar más tarde

• La captura del registro del chat es realmente impactante. Esta empresa afirma estar en comunicación con criminales reales, y ese criminal dice que si esta empresa hubiera sido usada, habría ayudado a evitar la brecha
  Así que actualicé mi evaluación sobre la credibilidad de esta empresa

  • Es pura especulación, pero parece que el hacker, al ser ignorado por Snowflake, contactó a Hudson Rock y le ofreció una oportunidad de relaciones públicas para lanzar esta historia, con el objetivo de vengarse de Snowflake por no pagar el rescate
    Hudson Rock parece haber aprovechado eso para inflar la historia y hacerla parecer una brecha más grande de lo que realmente fue. También me pregunto si el hacker acudió primero a Hudson Rock, o si Hudson Rock fue simplemente la primera empresa que le hizo caso
  • Esa conversación es extraña, casi caricaturesca. No sé cómo tomarla
    “Deberías haber comprado la protección de Hudson Rock, y eso podría haber evitado esto”
    “Sí, sin duda habría ayudado”
  • Es un eufemismo común en ransomware o extorsión tipo cobro de protección. Uno de mis mensajes favoritos que deja el grupo Akira en máquinas infectadas dice más o menos así
    “Felicidades. Su empresa aprobó una auditoría sorpresa de seguridad de la información y se convirtió en víctima de ransomware.”
    [...]
    Incluye: 1) soporte completo de descifrado 2) prueba de eliminación de datos 3) informe de seguridad sobre las vulnerabilidades encontradas 4) garantía de no publicar ni vender los datos 5) garantía de no volver a atacar en el futuro
    Al final no es más que una empresa de consultoría en seguridad que no sabías que habías puesto en nómina
    Por cierto, al ver qué daban como prueba de eliminación de datos, era literalmente solo la salida estándar de rm -vrf data. Entiendo que es imposible aportar evidencia de ausencia y que la víctima no tiene poder de negociación, pero esta puesta en escena me gusta bastante
  • Viendo la captura, esto parece completamente fabricado o, si no, totalmente con fines de marketing
    Incluso si fuera real, lo sensato habría sido quitar los mensajes de Hudson Rock. Puse a esta empresa en mi lista negra mental
  • Suena a extorsión implícita

• Si uno se guía solo por cómo lo expresa el atacante, parecería que Snowflake diseñó el sistema de forma que una sola cuenta de administrador tuviera control total sobre todo.
  Que Snowflake dijera en su comunicado del 31 de mayo que estaba investigando “ataques basados en identidad a nivel de toda la industria que afectaron a algunos clientes” también le da más credibilidad a lo de Ticketmaster y Santander.
  https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  Si el actor de amenazas hizo bien las cosas, esto podría convertirse en una de las mayores filtraciones de datos de la historia.

  • Eso es lo que el texto sugiere, pero parece exagerado. Por desgracia, se dio suficiente información como para identificar al dueño de las credenciales robadas, y esa persona es un ingeniero de ventas.
    Parece que los datos salieron de la cuenta de Snowflake de esa persona, que se usaba para crear demos para clientes o clientes potenciales. Es posible que clientes le hayan dado acceso para usar parte de sus datos reales en demos, pero eso está muy lejos de decir que tenía acceso ilimitado a las bases de datos de Snowflake de los clientes.
    También es totalmente posible que el hacker se haya llevado datos falsos de demo, pero convincentes, y no conozca la diferencia.
  • El problema es que Hudson Rock está adivinando o queriendo sonar autoritativo sin conocer el proceso.
    Un solo ingeniero de ventas maneja varias cuentas. Los ingenieros de ventas de Snowflake normalmente no implementan dentro del entorno del cliente, sino que configuran cuentas demo con créditos de 400 dólares que cualquiera puede crear. Como las cuentas demo vencen con el tiempo, las crean una y otra vez.
    El ingeniero de ventas arma todo dentro de la cuenta demo que creó y se lo muestra al cliente. Después de 30 días, Snowflake bloquea la cuenta si no tiene tarjeta de crédito y luego elimina la instancia demo y los datos.
    Para trabajar, el cliente puede compartir datos desde su propia instancia de Snowflake hacia la instancia demo creada por el ingeniero de ventas, o darle acceso a ese ingeniero de ventas de Snowflake por medio de SSO.
    En cualquiera de los dos casos, esto parece más un problema de organizaciones que no operaban con una postura de seguridad lo bastante restrictiva. Más allá de haber encontrado a un ingeniero de ventas muy activo y a clientes que no limitaron bien el alcance de permisos de empleados/contratistas/invitados, no hay nada nuevo en este ataque.
  • Por mi experiencia recibiendo soporte de Snowflake hace alrededor de un año, para que el equipo de Snowflake pudiera ver o hacer algo, un administrador de la cuenta del cliente tenía que otorgarle a Snowflake acceso explícitamente, y si no recuerdo mal ese acceso también tenía vencimiento.
  • Si el actor de amenazas se movió correctamente, tiene potencial de convertirse en la mayor filtración de datos de la historia.
  • La idea es que todo fue posible con un solo ataque de malware como servicio contra el empleado adecuado. Lo que se usó fue Lumma.
    Curiosamente, en la primera página también aparece una historia cercana sobre el uso de Pegasus contra una ONG de Europa del Este. El principio de privilegio mínimo importa, pero la seguridad del dispositivo también.
    https://news.ycombinator.com/item?id=40535912

• No soy empleado de Snowflake, pero trabajo mucho con Snowflake y su organización de ingenieros de ventas.
  Cuando hacen demos con clientes, los ingenieros de ventas crean un entorno de demostración usando una cuenta demo de Snowflake de 400 dólares que cualquiera puede crear. Para armar una demo, el cliente le da acceso a ese ingeniero de ventas, y el ingeniero mueve algunos datos al entorno de demo para trabajar. El nombre del entorno que publicó Hudson Rock también respalda esto.
  A mi parecer, esto es un problema de proceso donde el cliente no venció el ID de la persona con la que compartía datos, y el actor de amenazas robó las credenciales. Como no es explotación de una vulnerabilidad, no hay nada nuevo aquí.
  Y felicidades a Hudson Rock por exponer públicamente a una persona afectada porque tenía malware en su computadora. No es distinto a darle credenciales a un contratista y que luego se las roben. Es una porquería.

  • Que no sea una “nueva explotación de vulnerabilidad” no significa que no sea grave.
    Snowflake sabía que las credenciales de un ingeniero de ventas podían ser robadas, que esas credenciales podían saltarse la autenticación multifactor, y según el artículo ni siquiera vencían. Eso ya son strikes 1, 2 y 3.
    Las prácticas de seguridad de Snowflake crearon una situación donde se requería o al menos se incentivaba que los clientes compartieran con empleados de Snowflake acceso a conjuntos de datos amplios. Eso es strike 4.
    Los clientes también tienen responsabilidad por haber otorgado acceso demasiado amplio, pero Snowflake también es responsable por no haber construido un sistema mejor en el que este tipo de acceso no fuera necesario, o al menos por no haber supervisado y controlado mejor este acceso transitivo.
    En el momento en que una cuenta así recibe acceso a datos de clientes, ya no es una “cuenta demo”. Es una cuenta real, con datos reales y muy valiosos, y debe tratarse como tal.
    Actualización: Snowflake afirma que la cuenta demo en cuestión no accedió a datos de clientes ni fue el origen de la filtración, lo que contradice lo que dice el atacante.
  • Mencionar el nombre de inicio de sesión de la cuenta comprometida realmente parece poco profesional e innecesario.
  • La descripción de “Bayonet”, uno de los principales productos de Hudson Rock, dice esto:
    “Imaginen tener acceso a una plataforma de prospección con cientos de miles de empresas comprometidas y vulnerabilidades activas en todo el mundo, con la posibilidad de convertirlas en clientes.”
    He visto y tratado con varias empresas de este tipo, y sus tácticas son bastante bajas, además de mostrar un nivel muy pobre de habilidad técnica y esfuerzo.
  • Leí rápido algunas otras publicaciones de Hudson Rock y varias terminan con algo como “debieron habernos comprado protección”. Huele a cobro de protección.
  • Toda la entrada del blog apesta a autobombo extremo, y exponer a la víctima sí fue una acción realmente basura. En general, el desempeño de Hudson Rock es muy deficiente.

• La respuesta oficial de Snowflake dice lo siguiente
  “Creemos que esto es el resultado de una campaña continua, en toda la industria, de ataques basados en identidad con la intención de obtener datos de clientes. La investigación indica que estos ataques se llevan a cabo utilizando credenciales de usuario de clientes expuestas a través de actividades cibernéticas maliciosas no relacionadas. Hasta ahora, no creemos que esta actividad se deba a una vulnerabilidad, error de configuración o actividad maliciosa dentro de los productos de Snowflake.”
  [0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

• Parece que pusieron el artículo en privado, pero todavía queda en Wayback Machine: https://web.archive.org/web/20240531140540/https://www.hudso...

  • No se ve bien. Si había algo incorrecto, después de hacer esas afirmaciones y acusaciones lo apropiado sería una fe de erratas. Borrar el texto sin ninguna explicación es irresponsable y poco profesional

• Este texto afirma que la intrusión de Ticketmaster de hace unos días en realidad fue parte de un hackeo mucho más amplio que afectó a más de 400 empresas mediante credenciales robadas de un empleado de Snowflake
  Por ahora parece una gran historia que solo está reportando hudsonrock.com. Es la primera vez que escucho de Hudson Rock; ¿alguien sabe si es una fuente confiable?

  • Supe de Hudson Rock por primera vez cuando su “CEO” empezó durante meses a inundar varios subreddits de seguridad con spam de blogs de baja calidad que afirmaban múltiples intrusiones
    Varias cuentas fueron baneadas por los operadores y administradores de Reddit. Personalmente no la considero una fuente confiable ni creíble
  • Hay un reporte de BBC News sobre un hackeo importante al banco Santander, y está vinculado con Snowflake
    https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
  • Los empleados de Snowflake necesitan tiempo para vender todas sus acciones. Esta noticia va a golpear fuerte el precio de la acción de SNOW

• Snowflake parece estar diciendo que no fue culpa suya, sino del cliente
  https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
  Si https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... no es una historia completamente inventada, Snowflake está siendo un poco menos que honesta con los hechos
  La frase “La investigación indica…” es ambigua sobre si se refiere a una investigación interna o a investigación de seguridad en general. La formulación de “no creemos que se deba a una vulnerabilidad, error de configuración o actividad maliciosa dentro de los productos de Snowflake” enumera escenarios posibles para negarlos, pero omite hábilmente cómo ocurrió realmente
  Si le crees a Hudson Rock, Snowflake fue contactada por el actor malicioso, así que es muy probable que supiera bastante bien cómo ocurrió

  • ¿La cita no insinúa dentro de la misma frase cómo ocurrió?
    Dice que fue “llevado a cabo utilizando credenciales de usuario de clientes expuestas a través de actividades cibernéticas maliciosas no relacionadas”, así que, si no es inventado, parece que asumen que las credenciales se obtuvieron en otro lugar
    Al final les dijeron a los clientes que revisaran la configuración de sus cuentas, así que van en la dirección de deslindarse. Aun así, por ahora las fuentes son una empresa que fue hackeada y una empresa que está aprovechando el caso para promocionar su producto mientras doxxea descaradamente a un empleado, así que probablemente haya que esperar a que salga más información
  • O quizás asumieron que el lado del cliente fue comprometido y les echaron la culpa sin hacer un análisis profundo y adecuado
    El hacker afirma que ni siquiera invalidaron los refresh tokens; si eso es cierto, es un problema enorme y evidente

• El artículo no parece muy consistente con el título de “compromiso de cientos de clientes”
  Primero, la contraseña de lift/okta aparentemente solo permite acceso al portal de ServiceNow y no a cuentas de clientes, así que el problema de los refresh tokens parece limitado al portal de ServiceNow y no parece relacionado con la exposición de datos de cuentas reales de clientes de Snowflake
  Segundo, en la captura de pantalla que dice que 10 cuentas de empresas fueron comprometidas, se ven 4 credenciales distintas de cuentas de Snowflake, y una de ellas parece una cuenta demo personal. Así que eso podría explicar como mucho compromisos de 3 clientes, pero no hay detalles que muestren otros compromisos de clientes
  Incluso asumiendo que se comprometieron todas las credenciales de todos los clientes con los que trabajaba el ingeniero de ventas, la cantidad de clientes comprometidos probablemente estaría en los dos dígitos bajos. Eso porque cada cuenta de cliente tendría que haber otorgado acceso individualmente al ingeniero de ventas
  Decir que toda la base de clientes de Snowflake fue comprometida con base en el problema de refresh tokens del portal interno de Okta es un salto enorme, y ese problema no está conectado a ninguna cuenta de cliente de Snowflake

  • Es difícil decirlo sin saber exactamente cómo estaba configurada la cuenta comprometida y qué permisos de acceso tenía. Incluso en una “gran telco orientada a la seguridad” que conozco, te sorprendería ver qué nivel de acceso tienen ciertos perfiles técnicos. Claro, todo acceso queda registrado
  • Es totalmente posible que dentro de ServiceNow hubiera credenciales u otras cosas que pudieran usarse para movimiento lateral hacia otros lugares. Claro, eso es especulación