Uber, MGM Resorts y decenas de empresas reportaron autenticación de dos factores activa en sus auditorías. Los atacantes igual entraron.
Durante casi una década, la autenticación multifactor fue la respuesta estándar de cualquier responsable de seguridad cuando se le preguntaba cómo había reducido el riesgo de toma de cuentas. Aparece en prácticamente todas las listas de cumplimiento normativo y en todos los cuestionarios de ciberseguros, y por buena razón: agregar un segundo factor al login con contraseña cerró una enorme porción de ataques basados en credenciales. Las organizaciones que lo adoptaron temprano vieron el resultado en menos cuentas comprometidas. Esa confianza ahora está desactualizada de una manera que muchos equipos de seguridad todavía no registraron del todo. La tasa de adopción de MFA que se reporta a un directorio o a un auditor rara vez distingue entre el método usado para cumplir con el requisito. Una notificación push y una llave de seguridad física cuentan ambas como «MFA habilitado» en el mismo reporte de cumplimiento, y lo mismo ocurre con un código de un solo uso enviado por SMS, a pesar de que están en puntos radicalmente distintos del espectro de lo que un atacante puede vencer.
Cómo falló MFA en Uber y MGM a pesar de estar técnicamente activo
La brecha de Uber en 2022 y el incidente de MGM Resorts comparten la misma causa raíz: MFA estaba presente, y MFA igual falló, porque el método implementado nunca fue diseñado para resistir a un atacante dirigido. En ambos casos, los atacantes no necesitaron robar nada sofisticado. Solo necesitaron una contraseña robada y la disposición a enviar la misma solicitud de aprobación al teléfono de alguien una y otra vez, a veces durante horas, hasta que el usuario se cansó lo suficiente, o se confundió lo suficiente, como para tocar aprobar. Los equipos de seguridad llaman a esto push fatigue o MFA bombing. Funciona con la frecuencia suficiente como para que ahora sea una de las formas más comunes en que los atacantes superan MFA que está técnicamente «activado».
El problema con los códigos de un solo uso por SMS es más simple y más feo que el push fatigue. Es solo un código, y un código se puede obtener. A veces un atacante convence a un operador móvil de mover el número de teléfono de una víctima a una SIM que ellos controlan, una estafa que ha vaciado silenciosamente billeteras de criptomonedas y cuentas de correo corporativas durante años. Cada vez más, sin embargo, ni siquiera requiere tanto esfuerzo. Los kits de phishing construidos alrededor de herramientas de reverse-proxy ahora pueden interceptar un OTP en tiempo real: la víctima escribe su contraseña y código en lo que parece una página de login normal, sin saber que la página está reenviando silenciosamente todo al sitio real en nombre del atacante, sesión incluida.
La brecha de diseño que ambos métodos comparten y los atacantes explotan
Ambos modos de falla comparten una brecha de diseño simple. El método de autenticación nunca verifica que la persona que aprueba el login y el sistema que lo solicita estén hablando con el mismo destino legítimo. Esa es la propiedad que los atacantes explotan, y es exactamente la propiedad que los estándares más nuevos fueron construidos para cerrar. Si se pregunta qué detiene a un sitio de phishing de funcionar contra FIDO2 o una passkey, la respuesta no es astucia, es matemática. Una passkey no tiene ningún código para robar en primer lugar. Lo que se crea durante la inscripción es un par de claves criptográficas bloqueadas a un sitio web específico, permanentemente, y un dominio falso simplemente no es ese sitio web, sin importar cuán convincente se vea a un ojo humano. El navegador verifica el origen antes de que suceda cualquier otra cosa, encuentra que no coincide y el intento de login muere ahí mismo, antes de que el usuario pueda ser engañado para aprobar algo que no debería.
Este enlace de origen es todo el punto, y vale la pena ser preciso al respecto, porque los proveedores comercializan una amplia gama de productos bajo la etiqueta «resistente a phishing» sin que todos cumplan con el estándar. Una llave de hardware que todavía permite una opción de respaldo de OTP no es resistente si ese respaldo permanece accesible. Una passkey almacenada de manera insegura en un dispositivo compartido o no administrado reduce la brecha pero no la cierra por completo. La fortaleza del control depende de la ruta de autenticación completa, no solo del eslabón más fuerte en ella.
Por qué la migración que nadie quiere admitir sigue siendo difícil
Si el argumento técnico para MFA resistente a phishing es tan fuerte, la pregunta natural es por qué tantas organizaciones todavía funcionan con push y OTP. La respuesta honesta no es ignorancia. Es fricción, y pretender lo contrario no ayuda a nadie a planificar una migración. Los sistemas on-premises más antiguos no fueron construidos con WebAuthn en mente, y tampoco lo fueron algunas plataformas SaaS todavía en uso amplio, por lo que alguien termina agregando un control compensatorio o encontrando una solución alternativa, porque arrancar y reemplazar no es realista en la mayoría de los cronogramas. Las llaves de hardware tampoco son gratuitas: multiplicar incluso un costo modesto por usuario en una fuerza laboral grande suma rápido, y a diferencia de una notificación push, una llave perdida o dañada se convierte en un ticket de soporte real.
Luego está la parte que a nadie le gusta admitir en voz alta: los empleados que están acostumbrados a tocar aprobar en su teléfono en dos segundos van a notar, y quejarse, cuando el nuevo proceso signifique sacar una llave física de una bolsa y conectarla. Nada de eso significa que la migración no valga la pena. Significa que necesita un plan de despliegue detrás en lugar de un memo diciéndole a todos que cambien para el viernes.
El patrón de migración que funciona en empresas con sistemas heredados
Las organizaciones que están haciendo progreso real en esto no están convirtiendo a toda su fuerza laboral de la noche a la mañana. Están comenzando donde el riesgo está concentrado y la resistencia al cambio es más baja: cuentas de administrador, acceso a proveedores de identidad y cualquier persona con la capacidad de restablecer las credenciales de otro usuario. Estas son las cuentas que los atacantes apuntan primero precisamente porque comprometer una desbloquea todo lo que está aguas abajo, y también son las cuentas donde una población pequeña de usuarios técnicamente capaces puede absorber un nuevo flujo de trabajo sin mucha interrupción. Finanzas e ingeniería vienen después, junto con cualquier otro grupo que esté cerca de sistemas sensibles.
Las aplicaciones heredadas que todavía no pueden soportar el nuevo estándar no obtienen un pase permanente. En América Latina, donde sectores como banca y energía todavía operan infraestructura crítica sobre plataformas que datan de antes de 2015, esta fricción es particularmente visible. Bancos en Brasil y México reportan MFA habilitado en sus auditorías de cumplimiento, pero la implementación real sigue siendo notificaciones push sobre aplicaciones móviles propietarias que no soportan WebAuthn. Eso no es un problema de presupuesto únicamente: es un problema de arquitectura que requiere planificación de migración a varios años, y mientras tanto, las cuentas de administrador de esos mismos bancos siguen siendo vulnerables al mismo ataque de push fatigue que comprometió a Uber.
Nuestro análisis
El patrón que emerge de Uber, MGM Resorts y la lista creciente de intrusiones empresariales rastreadas hasta mesas de ayuda comprometidas es que la presencia de MFA en un reporte de cumplimiento dejó de ser un indicador confiable de resistencia real a ataques dirigidos. La brecha entre «MFA habilitado» como casilla de auditoría y «MFA resistente a phishing» como control técnico efectivo se amplió hasta el punto en que reportar ambos bajo la misma métrica es engañoso. Lo que todavía no se sabe es cuántas organizaciones en la región están reportando tasas de adopción de MFA superiores al noventa por ciento sin distinguir entre métodos, y cuántas de esas implementaciones seguirían el mismo patrón de falla si un atacante con una contraseña robada y paciencia decidiera probar push fatigue durante una madrugada.
La migración hacia FIDO2 y passkeys no es una actualización de software que se puede desplegar en un fin de semana. Es una reingeniería de flujos de autenticación que toca aplicaciones heredadas, procesos de soporte y expectativas de usuario, y en contextos donde la infraestructura crítica todavía corre sobre plataformas que no fueron diseñadas para estos estándares, la pregunta no es si migrar, sino cuánto tiempo más se puede sostener la ficción de que el MFA actual es suficiente antes de que el próximo incidente demuestre lo contrario.