En la actualidad, asistimos con regularidad a los discordantes resultados de la exitosa bombardeo por empuje a medida que esta táctica se convierte en un método de ataque habitual. Hoy en día, las organizaciones se enfrentan a más ataques de bombardeo push de autenticación multifactor (MFA), en los que un atacante generalmente ya tiene uno de los factores de autenticación, como nombre de usuario/contraseña. El atacante puede entonces solicitar notificaciones push que irán al smartphone del usuario.
Los bombardeos rápidos se basan en Fatiga del AMF. Aunque recibir una notificación push inesperada no es algo normal, es posible que el usuario apruebe la solicitud. Incluso si el usuario toma la decisión correcta y rechaza la solicitud la primera vez, es posible que los mensajes le agoten o le confundan. Basta con un "permitir" para que el atacante quede autentificado. Dependiendo de la estructura del entorno y de otros controles de seguridad existentes, eso puede dar al actor de la amenaza acceso a las aplicaciones, redes o archivos corporativos. Recientemente detallamos las especificaciones que ID Plus utiliza para detectar y protegerse de estos ataques en un blog llamado Protegerse contra los ataques de bombardeo MFA Prompt.
Enfrentarse a la fatiga MFA es un reto de seguridad interesante para la mayoría de las organizaciones. Aunque este tipo de ataque no debería producirse todos los días, si ocurre, su equipo de seguridad debe saberlo y responder. No sólo significa que estás siendo atacado, sino que también es probable que algunas credenciales ya estén comprometidas. El bombardeo inmediato entra en la categoría de ocurrencia baja y riesgo alto. En este artículo se describen algunos de los métodos fundamentales para hacer frente a este tipo de ataque desde la perspectiva de un equipo de operaciones de seguridad.
Para estar preparado para el Push Bombing y combatir la fatiga del AMF, hay que empezar por el elemento humano.
- Conocimiento del usuario. Los usuarios tienen que ser más que conscientes: tienen que estar informados, vigilantes y preocupados. Pero, al mismo tiempo, fomentar la concienciación sobre la ciberseguridad tiene que ser fácil para ellos o fracasarán. Recibir un curso de concienciación sobre seguridad una vez al año puede satisfacer las necesidades de cumplimiento, y proporciona algún beneficio, pero no es suficiente para combatir un ataque sofisticado. Hay que decir a los usuarios que si no han iniciado una comunicación, deben considerarla sospechosa. Si los usuarios disponen de las herramientas y la formación adecuadas, pueden tener una oportunidad.
- Educación de los usuarios. Asegúrate de que tus usuarios finales sepan que es posible que reciban una solicitud push-to-auth incorrecta y que no deben hacer clic automáticamente en "Aceptar" en el mismo cuadro de diálogo que han visto 100 veces. Para que este mensaje llegue a algunos o a la mayoría de los usuarios, su programa de seguridad debe tener algún tipo de comunicación regular con los usuarios, junto con una forma de persistir en la comunicación: considere una alerta por correo electrónico, publique la alerta en una página de blog persistente a la que puedan acceder todos los usuarios y añada enlaces a la alerta en otra documentación de la empresa, en su página de aterrizaje de seguridad o conviértala en un tema para el Mes de Concienciación sobre Ciberseguridad.
- Recursos de los usuarios. Recuerda que para ejecutar con éxito ataques de MFA Fatigue y Prompt Bombing, lo más probable es que un atacante ya tenga las credenciales del usuario. Los atacantes más avanzados iniciarán el spear phishing y podrían enviar SMS, alertas de WhatsApp, llamadas telefónicas o correos electrónicos al usuario para añadir confusión a la Fatiga MFA. Para que los usuarios sean capaces de contrarrestar estos intentos, necesitan tener confianza en cómo informar de un problema, y entender realmente cómo su Help Desk, Service Desk, y el equipo de seguridad se comunican con ellos. Una vez más, en este caso la concienciación no consiste en una formación anual, sino en la persistencia de la comunicación a los usuarios y la comprensión general de cómo encontrar los recursos necesarios y cómo deben funcionar las cosas. Si todos los usuarios saben que deben llamar inmediatamente al ServiceDesk y éste dispone de documentación actualizada, o incluso si alguien del equipo recuerda simplemente que este recurso existe y puede localizarlo, entonces su organización está bien posicionada.
- Acciones del usuario. Un usuario sin recursos y sin formación es un buen objetivo. ¿Saben los usuarios que deben solicitar siempre el contacto con el Service Desk a través de las herramientas adecuadas (Teams, Slack, etc.) y no aceptar ninguna llamada telefónica sin que antes llegue una comunicación verificada? Establezca las expectativas y ofrezca una forma de verificar si el usuario no está seguro.
En resumen, debería plantearse estas preguntas sobre su programa de seguridad y utilizar las respuestas para mejorar sus procesos según sea necesario:
- ¿Saben los usuarios qué hacer si reciben una solicitud de autenticación push inesperada?
- ¿Pueden los usuarios informar rápidamente de un problema de seguridad?
- ¿Saben todos los usuarios cómo ponerse en contacto con su Servicio de Atención al Usuario?
- ¿Sabe su servicio de asistencia técnica cómo responder a un problema de seguridad?
- ¿Disponen los usuarios de un medio para llegar directamente al equipo de seguridad?
- ¿Saben los usuarios cómo se pondría legítimamente en contacto con ellos el Service Desk, y que no se debe confiar en los contactos fuera de ese mecanismo?
- ¿Saben los usuarios cómo validar que un contacto es legítimo?
La primera forma de evitar la fatiga de la AMF es no permitir que se produzca. No utilizar contraseñas elimina el principal vector de ataque: un par de nombre de usuario y contraseña que puede persistir durante meses. Considere la posibilidad de utilizar FIDO como factor principal. Pero puede que FIDO aún no sea práctico para todo el mundo, y si ese es el caso, ¿qué debería hacer en su lugar?
Como suele ocurrir con la seguridad, la mejor prevención técnica es una defensa a varios niveles. He aquí algunas de las cosas que hay que tener en cuenta. Elige las que mejor se adapten a tu entorno:
- Si todavía confía en nombres de usuario y contraseñas, asegúrese de que dispone al menos de un almacén de contraseñas o, mejor aún, de una solución completa de Gestión de Autenticación Privilegiada (PAM) para sus accesos más sensibles. Asegúrese también de que se utiliza correctamente; puede que haya llegado el momento de una revisión.
- Si sospecha que sus credenciales están comprometidas, fuerce el restablecimiento de la contraseña. El restablecimiento evitará que se produzcan bombardeos en el futuro.
- Aunque no es una buena práctica cambiar arbitrariamente las contraseñas (por una serie de razones), forzar un cambio de contraseña limita el tiempo en que las credenciales comprometidas pueden utilizarse fácilmente para un bombardeo push.
- Revise la configuración de su MFA para asegurarse de que los patrones de acceso tienen sentido. Es posible configurar incluso las mejores soluciones de AMF para permitir demasiado acceso con una verificación limitada.
- También se aplican las mejores prácticas de sentido común en materia de contraseñas. Eduque a los usuarios para explicarles por qué no deben compartir contraseñas entre servicios. De este modo, si se produce un ataque, se limitará la superficie de ataque para el bombardeo.
- Si confía demasiado en la autenticación push o para proteger datos demasiado sensibles, considere aumentar la frecuencia de las solicitudes de contraseñas de un solo uso (OTP) mediante tokens blandos o duros. Las solicitudes de OTP serán vistas por el atacante en un escenario de ataque y nunca llegarán al usuario.
Para detectar una falsa solicitud de autenticación push mediante programación, es posible que necesite que muchas cosas funcionen correctamente. Los registros de su sistema de autenticación deben establecerse en el nivel correcto, enviarse al recopilador de registros adecuado, analizarse correctamente y el contenido debe estar en su lugar para generar una alerta apropiada. A partir de ahí, un vigilante Centro de Operaciones de Seguridad (SOC) 24/7 debe recibir y reconocer esta alerta con un manual actualizado sobre qué hacer a continuación. Esto no parece fácil, y no lo es. Diversas herramientas y mecanismos pueden reducir el esfuerzo, pero lo más importante es que hay que identificar el evento de registro que nos interesa, tener en cuenta los umbrales que nos importan y averiguar qué medidas debemos tomar cuando recibimos una alerta y validar todo el proceso.
Es posible que desee considerar la posibilidad de tener una alerta significativa para un rechazo push auth y afinar hacia abajo si eso hace demasiado ruido. Recuerde, si sus usuarios están bien entrenados, pueden hacerle saber de un problema muy rápidamente. Incluso pueden ser más rápidos de lo que un SIEM puede analizar los registros, enviar la alerta y que el SOC pueda detectarla y responder a ella. Siempre es bueno tener un plan de respaldo y varias capas de seguridad y supervisión.
Revise los eventos de registro y los escenarios hipotéticos basados en un ataque. Debe asegurarse de que identifica y recibe los datos correctos. Busque un evento de registro específico de un usuario que deniegue una solicitud push como principal elemento de interés. Otro elemento de interés son las solicitudes de autenticación push abandonadas.
Recuerde que detectar una solicitud push incorrecta significa que probablemente también ha detectado un compromiso de credenciales. Por lo tanto, incluso si un usuario dice "No" a la solicitud push, es posible que ya esté en riesgo si hay algún lugar en la red de su empresa al que una combinación de nombre de usuario y contraseña podría permitir el acceso. Si dispone de detección de solicitudes de autenticación push incorrectas, puede servir como mecanismo de detección de credenciales comprometidas.
Los usuarios de RSA pueden ver cómo ID Plus utiliza la autenticación basada en el riesgo y otras funciones para detectar y defenderse de bombardeos puntuales.
La respuesta apropiada al push-bombing depende del umbral con el que te sientas cómodo. Pero incluso con un Push to Authenticate inesperado, un usuario debería perder su sesión y verse forzado a cambiar su contraseña. Recuerde, esto debería ser un evento de baja ocurrencia. Asegúrese, no se arrepienta. Cambiar la contraseña también evitará posibles ataques futuros con esas credenciales de usuario específicas.
A pesar de que las contraseñas están mostrando su edad, si forman parte de la AMF en su organización, desarrolle y documente un proceso de confianza para forzar un restablecimiento de la contraseña y obtenga el compromiso previo del liderazgo para apretar el gatillo en el cambio de contraseña y la revocación de la sesión ante cualquier sospecha de compromiso. Cuanto más tiempo tenga un atacante acceso a su red, más daño podrá hacer. Tenga en cuenta el tiempo de respuesta. Póngase en contacto con los usuarios o sus responsables de forma rápida y proactiva a través de un canal de confianza si recibe una alerta y determine el mecanismo de contacto adecuado para su organización, como una carta por correo electrónico, para informar a los usuarios y sus responsables de lo sucedido y ponerlos en alerta. La comunicación contribuye en gran medida a generar una confianza que dará sus frutos en caso de que surjan problemas de seguridad en el futuro.
Tenga en cuenta que el push-bombing es un tipo de ataque, y debe priorizar cualquier respuesta al mismo en su programa general en relación con la probabilidad y el riesgo para su entorno. Si un atacante tiene éxito, tendrás que confiar en tus otros controles de seguridad para limitar los daños y asegurarte de que puedes recuperarte rápidamente.
