Ciberdelincuencia, gestión de fraude y ciberdelincuencia, autenticación multifactorial y basada en riesgos El robo de datos de los clientes de Snowflake muestra que los proveedores necesitan defensas sólidas Mathew J. Schwartz (euroinfosec) •28 de junio de 2024 Imagen: Shutterstock ¿Quién es responsable de las violaciones de datos experimentadas por clientes de la plataforma de almacenamiento de datos Snowflake? Ver también: Clínica de seguridad de identidad La versión corta de cómo se desarrolló este ataque se puede explicar en dos palabras: relleno de credenciales. Esto se refiere a tomar nombres de usuario (a menudo direcciones de correo electrónico) y pares de contraseñas de una filtración de datos públicos o privados y probarlos en una variedad de otros sitios para ver dónde podrían funcionar. En un informe conjunto sobre las violaciones de datos, Mandiant y CrowdStrike, que fueron contratados para ayudar con la respuesta a incidentes, dijeron que los atacantes crearon una herramienta, elegantemente llamada «rapeflake» (ahora rastreada por Mandiant de Google como «Frostbite») para automatizar este proceso. Se violaron varias cuentas de clientes de Snowflake y algunas víctimas recibieron demandas de rescate por los datos robados. Los investigadores dicen que unas 165 organizaciones se han visto afectadas. Si bien la mayoría no ha sido nombrada públicamente, las víctimas conocidas incluyen el Banco Santander, el proveedor de repuestos para automóviles Advance Auto Parts, el Distrito Escolar Unificado de Los Ángeles y el minorista de lujo Neiman Marcus. Otra víctima, Ticketmaster de Live Nation Entertainment, en su última notificación de violación de datos dijo que la violación de su cuenta Snowflake comenzó el 2 de abril y fue descubierta el 23 de mayo. El informe conjunto de Snowflake publicado a principios de este mes dice: «No hemos identificado evidencia que sugiera que esta actividad fue causado por una vulnerabilidad, mala configuración o violación de la plataforma de Snowflake”. «El entorno empresarial de Snowflake no ha sido violado», dijo un portavoz. El CISO de Snowflake, Brad Jones, dijo en una publicación de blog: «Creemos que esto es el resultado de ataques continuos basados ​​en la identidad en toda la industria con la intención de obtener datos de los clientes». Pregunta sobre responsabilidad Entonces, ¿quién es responsable cuando los ataques de relleno de credenciales resultan en violaciones de datos? «Es difícil definir proporciones de responsabilidad, pero lo que está claro es que la seguridad es una responsabilidad conjunta», dijo el experto en violación de datos Troy Hunt, fundador del sitio gratuito Have I Been Pwned? Servicio de notificación de incumplimiento. «Si las credenciales se obtuvieron por deficiencias en nombre del cliente, entonces eso es responsabilidad de ellos, pero igualmente, las plataformas como Snowflake deben trabajar bajo el supuesto de que estos ataques son comunes y brindan resistencia contra ellos». Una triste realidad para una organización cuyas cuentas de clientes son violadas en un ataque de este tipo es que a menudo se les considera responsables, al menos en la percepción del público. Los ataques de intercambio de credenciales han sido comunes durante años, y los aficionados intercambian regularmente listas de relleno de credenciales en foros de piratería. ¿Qué debería hacer una organización para demostrar que hizo todo lo posible para combatir el relleno de credenciales? Hunt, que durante mucho tiempo ha asesorado a empresas sobre las defensas necesarias, me dijo que para él, un enfoque moderno incluiría «una combinación de controles que incluyan el bloqueo de contraseñas violadas conocidas, la antiautomatización y el reconocimiento de comportamientos anómalos en los intentos de autenticación». Aquí está mi lista más completa de defensas sugeridas: Apoyar una MFA sólida. La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. afirma que «la MFA ‘resistente al phishing’, como una tarjeta inteligente o una clave de seguridad FIDO, es el estándar de oro de la protección de MFA», y los usuarios siempre deben utilizar «el nivel más fuerte de MFA que puedan». Pero MFA no resolverá todo, especialmente «cuando hablamos de claves utilizadas para comunicarse entre la aplicación y la plataforma en la nube», dijo Hunt. Hacer obligatoria la MFA. Brinde a los administradores la capacidad de exigir que sus usuarios empleen MFA sólida y resistente al phishing. Rechazar contraseñas reutilizadas. Alrededor de 2016, sitios como Facebook y Netflix comenzaron a hacer caducar por la fuerza las contraseñas de los usuarios si descubrían que los clientes las reutilizaban en otro sitio. Revisan continuamente las filtraciones de datos en busca de dicha información. Bloquear contraseñas reutilizadas. En 2017, Hunt lanzó el servicio gratuito Pwned Passwords que los sitios pueden usar para ayudar a los usuarios a nunca elegir una contraseña que haya aparecido en una violación de datos conocida, poco después de que el Instituto Nacional de Estándares y Tecnología de EE. UU. comenzara a recomendar esa práctica. Combatir comportamientos sospechosos. La advertencia de Per Hunt de monitorear el «comportamiento anómalo de los intentos de autenticación» y bloquear volúmenes altos o inusuales de solicitudes o actividades de inicio de sesión, que podrían ser atacantes que utilizan herramientas maliciosas como Frostbite. Verificar clientes. MFA no protegerá todos los tipos de conexión, como a través de API o directamente a bases de datos. “En estas situaciones se necesitan mejores controles para verificar la legitimidad del cliente que consume el servicio”, dijo Hunt. A raíz de que aproximadamente 165 clientes de Snowflake vieron que sus datos de Snowflake desaparecían debido a ataques de relleno de credenciales, la plataforma de almacenamiento de datos prometió perfeccionar su enfoque para MFA y defensas basadas en red. Snowflake actualmente admite solo un tipo de MFA: Cisco Duo, «y solo esa instancia administrada por Snowflake», dijo la compañía, aunque en agosto pasado dijo que estaba considerando agregar otras opciones. Cada usuario debe autoinscribirse en este MFA y los clientes no pueden hacer que el uso de MFA sea obligatorio. Duo se puede utilizar para autenticarse no solo en la interfaz web de Snowflake, Snowsight, y su herramienta de interfaz de línea de comandos, sino también con SnowSQL de la compañía y los controladores Snowflake JDBC y ODBC. Snowflake también admite una variedad de proveedores compatibles con SAML para el inicio de sesión único. Okta y Microsoft Active Directory Federation Services ofrecen soporte nativo, además de OAuth y el uso de una clave de hardware criptográfica que genera un par de claves. «Para cuentas de servicio (es decir, casos de uso interactivos no humanos), utilice autenticación de par de claves u OAuth para la comunicación de máquina a máquina en lugar de credenciales estáticas», dijo Snowflake. No está claro si el acceso a cualquiera de estas funciones genera costos adicionales de Snowflake; El proveedor no respondió de inmediato a mi solicitud de comentarios. Mandiant dijo que el hecho de que no todos los usuarios de los clientes de Snowflake emplearan MFA fue un factor en las violaciones de datos. «El amplio impacto de esta campaña subraya la necesidad urgente de monitoreo de credenciales, la aplicación universal de MFA y autenticación segura, limitando el tráfico a ubicaciones confiables para las joyas de la corona y alertando sobre intentos de acceso anormales», dijo. Snowflake ha prometido ofrecer a los clientes MFA adicional y otras opciones. «Estamos desarrollando un plan para exigir a nuestros clientes que implementen controles de seguridad avanzados, como autenticación multifactor o políticas de red», dijo el lunes. Idealmente, la empresa también comenzará a respaldar el estándar de oro de MFA resistente al phishing que defiende CISA. Debido a que los vendedores y proveedores de servicios almacenan datos pertenecientes a sus clientes o en nombre de ellos, deberían buscar MFA resistente al phishing de forma predeterminada, además de controles de seguridad adicionales para bloquear ataques de relleno de credenciales perpetrados por API u otras vías. Cualquier cosa menos, los proveedores corren el riesgo de sufrir las inevitables violaciones de datos de los clientes que se producirán a continuación. URL de la publicación original: https://www.databreachtoday.com/blogs/breaches-due-to-credential-stuffing-whos-accountable-p-3656