En septiembre de 2022, un atacante que había comprado la contraseña de un contratista de Uber intentó iniciar sesión una y otra vez. Cada intento enviaba al contratista una solicitud de aprobación del segundo factor. Las primeras bloquearon al atacante. Luego una fue aceptada, y el atacante entró (actualización de seguridad de Uber). Un mes antes, Cisco había descrito el mismo patrón en su propia brecha: llamadas de voz de alguien que se hacía pasar por el servicio de soporte y una sucesión de notificaciones push hasta que un empleado aceptó una (Cisco Talos).
Ambas empresas tenían la autenticación multifactor activada. Los atacantes no rompieron el segundo factor: lo rodearon, con técnicas que funcionan precisamente porque el MFA implantado le pide a una persona cansada que tome una decisión de seguridad en el peor momento posible.
Si su MFA es un código por SMS o una notificación de un solo toque para «¿Aprobar?», esto merece diez minutos de su atención. Esos dos métodos son hoy los que los atacantes planean esquivar, no los que los detienen.
Tres ataques que vencen a «algo de MFA»
- Push-bombing (fatiga de MFA, MFA bombing, 2FA bombing). El atacante ya tiene la contraseña, obtenida de una filtración, de un phishing o de la reutilización de credenciales. Desencadena un inicio de sesión tras otro, disparando una avalancha de avisos de aprobación al teléfono del usuario hasta que, por confusión o simplemente para que pare, alguien toca Aprobar. Un solo toque y ya están dentro.
- SIM swapping. El SMS nunca se diseñó como canal de seguridad. Un atacante que convence (o soborna) a un operador móvil para trasladar un número a una nueva SIM recibe todos los códigos de un solo uso que se envían a ese número. Sin malware, sin página de phishing: basta una llamada a un servicio de atención al cliente.
- Adversary-in-the-middle (AiTM). Una página de inicio de sesión falsa y convincente actúa como proxy de la real en tiempo real. La víctima introduce su contraseña, el sistema real le pide el segundo factor y la víctima lo aporta, porque de verdad está intentando iniciar sesión. El proxy del atacante se queda con la sesión resultante. El MFA «funcionó». La cuenta se ha perdido igualmente.
La agencia estadounidense de ciberseguridad CISA menciona los tres en sus recomendaciones y traza una línea clara: solo la autenticación FIDO/WebAuthn y la de clave pública (PKI) cuentan como resistentes al phishing, porque la clave está vinculada a la dirección del sitio web real y una página de imitación no puede usarla. La aprobación por notificación push, incluso con coincidencia de números (number matching), no figura en esa lista (ficha informativa de CISA).
Qué detiene a cada uno
Estos ataques tienen puntos débiles distintos, así que conviene ser precisos sobre qué neutraliza a cuál.
- SIM swap e interceptación de códigos: eliminar el código. Si la clave del usuario se genera en el hardware seguro del teléfono y nunca sale de él, no hay ningún secreto compartido guardado en una base de datos ni nada que llegue por SMS. No hay nada que interceptar, y trasladar un número de teléfono no traslada nada que un atacante pueda aprovechar.
- Push-bombing: permitir que el usuario lea lo que aprueba. Ninguna clave ni ninguna biometría sirven de nada una vez que la solicitud llega al teléfono, porque el ataque simplemente le pide al usuario que diga que sí. La biometría solo confirma que quien toca es el dueño del teléfono, no que el inicio de sesión sea legítimo. Lo que funciona es una solicitud que lleve una descripción específica y legible de exactamente qué se está aprobando: qué servicio, qué acción, desde dónde. Un aviso que el usuario nunca inició es visiblemente ajeno, así que lo rechaza. La caducidad de las solicitudes y los límites a la frecuencia con que pueden desencadenarse eliminan el volumen del que depende el ataque.
- Adversary-in-the-middle: la aprobación por sí sola no lo detiene. Aquí no se engaña al usuario para que apruebe el inicio de sesión de otra persona. Aprueba el suyo propio, en el sitio web equivocado. Lo que ayuda es mostrar de dónde procede la solicitud: si la aprobación indica la dirección desde la que llegó el inicio de sesión, un proxy en otro país salta a la vista de un usuario que se fije. Eso encarece el ataque; no lo hace imposible. Cuando el modelo de amenazas exige resistencia al phishing en sentido estricto, la respuesta son las llaves FIDO vinculadas al sitio, junto con sesiones de corta duración y políticas de inicio de sesión que limiten dónde pueden usarse las sesiones.
Esa es la diferencia entre un MFA que el atacante ya tiene automatizado para saltárselo y un MFA que hace que cada uno de estos ataques sea visible o inútil.
Dónde encaja Notakey
Notakey elimina el código y hace que cada aprobación sea legible.
- La clave del usuario se genera dentro del hardware seguro de su teléfono y nunca sale de él. No hay ningún SMS que interceptar ni ningún código que retransmitir.
- La notificación no es más que un timbre. Cuando el usuario abre la aplicación, esta obtiene la tarjeta de aprobación por HTTPS del servidor en el que se registró, de modo que lo que el usuario lee procede de su servidor, no de la notificación, y su firma cubre exactamente esa solicitud.
- Frente al push-bombing, la defensa es lo que el usuario lee: la tarjeta muestra qué servicio lo solicita y qué se está aprobando, de modo que un aviso que nadie inició resulta evidente a simple vista y se rechaza. Las solicitudes caducan, y un limitador integrado restringe la frecuencia con que pueden desencadenarse, de modo que la avalancha de avisos de la que depende el ataque se corta en seco.
- Frente al adversary-in-the-middle, el servidor puede configurarse para que la tarjeta muestre la dirección IP desde la que llega la solicitud, el nombre del servicio o la URL, de modo que el usuario vea desde dónde procede realmente el inicio de sesión. No afirmaremos más que eso: hace visible un proxy para el usuario que se fije; no hace imposible el ataque.
- Cubre las vías que los atacantes usan de verdad; consulte las guías prácticas sobre 2FA en una VPN con RADIUS, escritorio remoto de Windows y SSH en Linux.
Compruébelo usted mismo
La forma más rápida de notar la diferencia es aprobar una transacción que realmente pueda leer: una acción concreta, firmada desde su propio teléfono, en lugar de un aviso sin contexto.
Pruebe la demo en vivo para firmar una en unos dos minutos, o solicite una demostración y trazaremos sus inicios de sesión de VPN, SSO o Windows hacia un piloto en su propia infraestructura.