Análisis del riesgo de UX en OAuth del phishing con código de dispositivo

El truco de phishing más cruel no siempre es la página de inicio de sesión falsa con el dominio de máscara de Halloween con descuento. A veces es la página de autorización real, sonriendo con educación mientras le pide a un usuario que apruebe lo incorrecto. El phishing con código de dispositivo es el tipo de problema de identidad que hace que los defensores miren fijamente una función perfectamente legítima y susurren: claro, esto se convirtió en una primitiva de ataque. La lección no es que OAuth esté roto. La lección es que la experiencia de inicio de sesión, el acceso condicional y los avisos de consentimiento ahora forman parte de la superficie de ataque, y merecen la misma sospecha que normalmente reservamos para las bases de datos expuestas y los comunicados de prensa sobre tomarse la seguridad en serio.

Qué ocurrió, según Proofpoint y Rubrik

Proofpoint describe el phishing con código de dispositivo como una evolución en la toma de control de identidades, no como un nuevo hechizo misterioso encontrado en un grimorio de sótano. Su investigación de amenazas dice que el phishing de credenciales sigue permitiendo la toma de control de cuentas, el fraude, el ransomware y el espionaje, mientras que los actores de amenazas se han expandido hacia el phishing con código de dispositivo y OAuth a medida que las organizaciones mejoran sus defensas contra el phishing común de MFA. Ese es el avance de la trama: cuando los defensores hacen que el viejo truco sea menos rentable, el adversario no se jubila; busca un flujo de trabajo en el que los usuarios ya confían. La conversación de Rubrik con la investigadora de Proofpoint Selena Larson plantea el problema como abuso del flujo de autenticación, con adversarios que explotan estructuras de comunicación legítimas para capturar acceso administrativo y empresarial. Esa formulación importa porque el camuflaje no es solo una marca falsificada o un dominio parecido. El camuflaje es la propia ceremonia normal de inicio de sesión, lo que significa que los equipos de seguridad tienen que revisar la ceremonia, no solo las credenciales introducidas durante ella.

Cómo el flujo real se convierte en

el señuelo, según Proofpoint Proofpoint dice que, de 2020 a alrededor de 2022, los equipos rojos y, ocasionalmente, delincuentes y actores de amenazas de espionaje usaron phishing con código de dispositivo para engañar a alguien y lograr que autorizara una solicitud maliciosa. Esa es la parte importante para quienes construyen sistemas: la víctima no necesariamente está escribiendo una contraseña en una página falsificada. Puede estar completando un flujo de autorización real y concediendo acceso en un contexto que no entiende. Esto cambia la pregunta defensiva de si el usuario detectó la página falsa a si el sistema hizo que la decisión riesgosa fuera comprensible antes del consentimiento. Un aviso que dice “aprueba este código” puede ser técnicamente exacto y aun así inútil para una persona que intenta terminar una invitación a una reunión, un chat de soporte o algún otro ritual laboral de leve pánico. La precisión no es lo mismo que la comprensión, y los atacantes prosperan en esa brecha como moho en una nevera olvidada de oficina.

Qué quedó expuesto, según Krebs y BleepingComputer

Krebs on Security documentó la versión anterior de esta historia de identidad en 2022, cuando el phishing por SMS apuntó a empleados de empresas comerciales de contratación de personal y los llevó a páginas que imitaban pantallas de autenticación de Okta. Krebs informó que a quienes enviaban sus credenciales luego se les pedía que proporcionaran códigos de un solo uso para MFA. La técnica es distinta, pero la moraleja resulta tristemente familiar: si el paso de autenticación puede ser retransmitido o manipulado mediante ingeniería social, la presencia de MFA no significa automáticamente que la decisión haya sido segura. La cobertura de BleepingComputer sobre el phishing con código de dispositivo OAuth en Azure y Google señala otra complicación práctica: las defensas de identidad viven dentro de implementaciones específicas de cada plataforma. Eso no significa que todos los equipos tengan que convertirse en aficionados del comité de estándares de OAuth, aunque felicitaciones a las tres personas que ya lo son. Significa que los defensores deberían inventariar dónde está habilitada la autorización de dispositivo, qué aplicaciones pueden solicitarla y cómo explica cada plataforma la solicitud a la persona que tiene el teclado.

Cómo contenerlo, según Rubrik y Krebs La conversación de

Rubrik orienta a los defensores hacia controles arquitectónicos, incluidas políticas de acceso condicional y marcos estrictos de cumplimiento de dispositivos. Exactamente ahí es donde pertenece este problema. Capacitar a los usuarios para reconocer avisos sospechosos es útil, pero hacer que cada empleado depure personalmente OAuth bajo presión de tiempo no es una estrategia; es una prueba de estrés laboral con tokens en la nube. Krebs también informó en 2022 que Apple, Google y Microsoft anunciaron compatibilidad con enfoques de inicio de sesión sin contraseña que dependen de desbloquear un teléfono inteligente, y expertos dijeron que los cambios deberían ayudar a derrotar muchos tipos de phishing, aunque advirtieron que un futuro verdaderamente sin contraseñas aún podría estar a años de distancia para la mayoría de los sitios web. Lo sin contraseña puede reducir el robo de contraseñas, pero el phishing con código de dispositivo recuerda que la próxima batalla es la claridad de la autorización. Si un usuario está aprobando acceso, el producto debe mostrar qué se está aprobando, para qué aplicación, desde qué contexto y por qué la solicitud es inusual.

Qué significa realmente para ti, según Proofpoint y Krebs

Para los equipos de identidad, la conclusión es lo bastante simple como para caber en una nota adhesiva y lo bastante deprimente como para arruinar el almuerzo: revisen los flujos de inicio de sesión como superficies de producto, no solo como tuberías de seguridad. El enfoque de Proofpoint sobre la toma de control de cuentas y la historia de Krebs sobre el phishing de códigos apuntan al mismo modo de fallo, donde un paso de autenticación técnicamente válido se convierte en un escenario de ingeniería social. Audita la disponibilidad del código de dispositivo, endurece el acceso condicional, exige dispositivos conformes cuando corresponda y reescribe los avisos para que los usuarios puedan entender el riesgo antes de dar su consentimiento. Para todos los demás, no traten una página de inicio de sesión real como prueba de que la solicitud es legítima. Ve más despacio cuando un aviso te pida introducir un código, aprobar un dispositivo o autorizar una aplicación que no empezaste a usar intencionalmente. La próxima defensa de identidad útil quizá no sea otra casilla en el panel de configuración de MFA. Puede ser una frase más clara justo en el momento exacto en que alguien está a punto de entregar las llaves al personaje equivocado.