FIDO2 es un término de grupo de autenticación moderno para autenticación sin contraseña. La Alianza Fast Identity Online (FIDO) lo desarrolló para reemplazar el uso de contraseñas conocidas heredadas y proporcionar un método seguro para autenticarse mediante una clave física o integrada.
FIDO2 es conocido principalmente por proteger a las personas contra ataques de intermediario (MITM), phishing y secuestro de sesiones.
En este artículo, lo guiaré a través de mi investigación para descubrir cómo usar ataques MITM para evitar FIDO2. Primero, describiré un WebAuthn completo. autenticación fluya, luego camine a través de las protecciones de FIDO2. Luego abordaré técnicas de ataque famosas y proporcionaré casos de uso de la vida real. Por último, analizaré las mitigaciones y lo que puede hacer para proteger su empresa.
Pero primero, algunos antecedentes.
El flujo de autenticación FIDO2 consta de la especificación API WebAuthn para una parte de confianza (RP) del cliente, que es la comunicación de la aplicación en la nube, y el protocolo Cliente a Autenticador (CTAP) para la comunicación de hardware. Todo el proceso es gestionado por el navegador y consta de dos pasos de autenticación: registro del dispositivo y autenticación.
Está construido de esta manera porque FIDO2 se basa en un mecanismo de criptografía de clave pública. Aquí es donde el cliente genera una clave pública y privada y envía esta última a RP para la verificación de la firma al iniciar sesión. FIDO se puede aplicar como método de autenticación para una sola aplicación o en una federación. Para aquellos que no lo saben, una federación se refiere a un inicio de sesión único (SSO) para múltiples aplicaciones no relacionadas administradas por un único proveedor de identidad (IdP).
Funciones de seguridad FIDO2
FIDO2 es famoso por sus características de seguridad, principalmente para prevenir ataques de phishing, intermediarios y secuestro de sesión.
Como parte de mi investigación, quería ver si FIDO2 es inmune a estos ataques y los resultados me sorprendieron. Comencé con el secuestro de sesión, una técnica de ataque en la que el adversario roba la sesión de un navegador para obtener acceso a la aplicación y a los datos privados del usuario. El segundo ataque que investigué fue un ataque de intermediario (MITM) al IdP, donde un adversario escucha, modifica y retransmite las comunicaciones entre dos dispositivos que creen que se están transmitiendo directamente entre sí.
Hoy en día, MITM es más difícil de lograr gracias a la protección TLS. Aun así, existen muchos métodos para lograr un MITM, incluida la suplantación de DNS/DHCP, el envenenamiento de ARP y SLAAC. Además, se sabe que los actores estatales superan y descifran TLS robando el certificado de una organización. Un ejemplo es atacar Active Directory Servicios de Certificación.
FIDO fue diseñado para prevenir estos ataques. Sin embargo, al implementar este método de autenticación moderno, la mayoría de las aplicaciones no protegen los tokens de sesión creados después de que la autenticación sea exitosa. Descubrí que muchos proveedores de identidades todavía son vulnerables a tipos de ataques MITM y de secuestro de sesión.
Para entender cómo funciona esto, debemos volver a lo básico.
Con el tiempo, los conceptos básicos de la comunicación web apenas han cambiado. El protocolo HTTP y sus características se utilizan ampliamente en la World Wide Web, incluido el uso de GET y POST para transferir atributos entre puntos finales y cookies para mantener el estado de la sesión de un cliente. Las aplicaciones web y los protocolos SSO, como OIDC y SAML, dependen del protocolo HTTP y deben seguir sus pautas para mantener el estado del cliente. A lo largo de los años, la seguridad de las sesiones de los usuarios ha mejorado en términos de cómo el navegador la mantiene localmente y cómo la aplicación la calcula. Sin embargo, estos cambios no son suficientes.
¿Cómo te protege exactamente FIDO2?
Para una autenticación FIDO2 exitosa, el usuario debe registrar el dispositivo FIDO en la parte de confianza u ordenar al navegador que realice una función navigator.credentials.create(). Esto indica al dispositivo FIDO que genere una clave pública y privada para un usuario específico y la vincule a un origen de dominio. Luego, el navegador puede validar el origen del dominio de la parte que confía durante el proceso de autenticación.
El siguiente es el paso de autenticación, donde la parte de confianza llama a navigator.credentials.get() del navegador para cada solicitud de autenticación. Una vez que el RP lo activa, el navegador se comunica con la clave de seguridad FIDO a través de CTAP. Si el usuario final aprueba la autenticación, la clave de seguridad genera una firma utilizando la clave privada almacenada. Posteriormente, el RP verifica esta firma utilizando su clave pública.
En un ataque de phishing a un sitio web con una URL diferente, el origen del dominio del sitio web validado evitará posibles robo de credenciales porque la URL no coincide con el origen registrado. Sin embargo, el mecanismo de ataque MITM es diferente. El requisito previo para un ataque MITM es tener un certificado confiable de la víctima objetivo. La mayoría de los navegadores modernos alertarán y forzarán la autenticación segura a través de TLS en un sitio web remoto. Un ataque MITM exitoso expone todo el contenido de la solicitud y la respuesta del proceso de autenticación. Cuando finaliza, el adversario puede adquirir la cookie de estado generada y secuestrar la sesión de la víctima. En pocas palabras, la aplicación no realiza ninguna validación una vez finalizada la autenticación.
Casos de uso de prueba
decidí tomar Entra IdP, PingFederate y Yubico como casos de uso de investigación. Cada uno funciona de manera diferente y tiene sus pros y sus contras.
Caso de uso 1: Parque infantil Yubico
Yubico Playground fue creado para demostrar y probar las funciones y claves de seguridad de FIDO. En este ejemplo, FIDO autentica al usuario directamente a través de HTTP en una base de datos de usuarios local. Tras una autenticación exitosa, se genera una cookie denominada "sesión". No hay validación en el dispositivo que solicitó esta sesión y cualquier dispositivo puede utilizar esta cookie hasta que caduque. La adquisición de esta cookie podría permitir al adversario saltarse el paso de autenticación, acceder al área privada del usuario y, en este caso, eliminar la clave de seguridad del perfil del usuario. Este es un ejemplo sencillo de secuestro de sesión; A medida que avancemos hacia escenarios más complicados, veremos cómo cambia este método.
Caso de uso 2: Entra ID SSO
El segundo caso de uso es Entra ID SSO, que cuenta con capacidades de seguridad para autenticarse a través de varios protocolos SSO y otros métodos de autenticación modernos. Su función de Acceso Condicional (con la característica de fuerza de autenticación) limita los mecanismos sin contraseña, específicamente FIDO2. Nuestras pruebas validaron aplicaciones nativas de Microsoft, como Office 365 y el portal de administración de Azure, a través del protocolo OpenID Connect (OIDC) y una aplicación de terceros de ejemplo a través del protocolo SAML. En ambos protocolos de federación, el IdP proporciona un token de acceso firmado con un tiempo de expiración de 1 hora que se pasa como atributo POST a la parte que confía. En el mecanismo de federación, el adversario ni siquiera tiene que retransmitir el proceso de autenticación. El atacante solo necesita un token firmado, que puede volver a usar en el plazo adecuado y generar cookies de estado dentro de un plazo más largo. OIDC admite tokens de actualización que pueden generar tokens de sesión para un período prolongado.
Podemos ver en el siguiente ejemplo que la aplicación nativa del portal de administración de Azure no valida el token otorgado por el SSO.
Caso de uso 3: PingFederate
El tercer caso de uso es PingFederate. Esta aplicación general proporciona SSO de federación para una gran variedad de aplicaciones empresariales. A diferencia de Entra, Ping utiliza adaptadores de terceros para realizar la autenticación. Estos adaptadores se pueden encadenar en un flujo de política de autenticación. Cada adaptador tiene su propio contexto y está separado del otro. La autenticación exitosa es cuando un usuario cumple con los requisitos de todos los adaptadores de la política. Las capacidades FIDO2 se pueden utilizar con el adaptador PingOne. Sorprendentemente, nuestro equipo descubrió que si el desarrollador de confianza no valida el token OIDC (o la respuesta SAML), el ataque MITM descrito tendrá éxito.
Eslabón más débil de autenticación
Los casos de uso de SSO son más graves desde el enfoque directo. A medida que participan más actores en el proceso de autenticación, la parte que confía tiene menos control para validar la integridad del dispositivo de origen. Aunque FIDO protege contra ataques MITM, toda la cadena depende de sus eslabones más débiles, que son los protocolos SSO donde sus tokens de concesión pueden ser reutilizados por un dispositivo diferente.
Mitigaciones y próximos pensamientos
¿Qué pasaría si hubiera una manera de verificar que la sesión autenticada sea utilizada únicamente por el cliente autenticado? Presentando Vinculación de tokens, una propuesta de estándar solicitada en 2018.
Token Binding permite que las aplicaciones y servicios vinculen criptográficamente sus tokens de seguridad a la capa TLS para mitigar el robo de tokens y los ataques MITM. Token Binding v1.0 vinculará toda la sesión a su protocolo de enlace TLS subyacente. La criptografía de clave pública se extiende más allá del contexto de autenticación y WebAuthn entregará de forma segura la firma vinculante del token.
Pero, ¿cómo funciona Token Binding?
- Tras el saludo Cliente-Servidor, hay disponible una extensión Token Binding.
- Los dos puntos finales acuerdan los campos TLS que firmará el cliente.
- Exactamente como en WebAuthn, el navegador crea un par de claves públicas y privadas de larga duración.
- El cliente envía la clave pública al RP para verificación de firma; luego la firma se envía a través de la capa de aplicación.
- El servidor verifica la firma y la vincula al token de sesión.
Inicialmente realicé esta investigación a mediados de 2023 y envié los resultados a Microsoft. En respuesta a la divulgación inicial, Microsoft afirmó que esto no es una vulnerabilidad. Aun así, es un superficie de ataque Esto podría causar daños a una organización expuesta. Cuatro meses después, Microsoft presentó una vista previa de acceso condicional de Token Protection, una variante de la vinculación de tokens específica para Trusted Platform Module (TPM). En su documentación, Microsoft explica que el robo de tokens es poco frecuente, pero el daño que puede ocasionar es significativo. En el caso de las aplicaciones web, TPM puede funcionar de forma similar a FIDO, utilizando un método de comunicación diferente con el chip de seguridad. Sin embargo, el protocolo WebAuthn se mantiene igual para la comunicación entre el navegador y el RP. La vista previa actual se limita a aplicaciones web y versiones de cliente de Windows específicas. La configuración actual es compleja, y en el futuro Microsoft ampliará la función a claves de seguridad FIDO genéricas.
Hasta la fecha, Microsoft EDGE es el único navegador que ofrece Token Binding. Chrome ofreció Token Binding pero lo eliminó debido a la baja adopción.
La propuesta de Token Binding analiza dos tipos de vinculación de dispositivos. Uno para la autenticación directa se llama Enlace de token proporcionado. Este tipo es común en aplicaciones simples como el parque infantil Yubico. El segundo tipo, Vinculación de tokens referidos analiza la protección tanto del proveedor de identidad como de la parte que confía. En cualquiera de los casos, WebAuthn puede pasar la firma Token Binding de forma segura en la fase de autenticación.
Se recomienda que los administradores de aplicaciones requieran Token Binding en una autenticación FIDO2, si está disponible.
Al diseñar un mecanismo de autenticación, es necesario comprender la atribución de amenazas y desarrollar la autenticación en consecuencia. En casos delicados, se recomienda el enfoque directo ya que la aplicación puede tener más control sobre el token de sesión.
Para los desarrolladores de aplicaciones, recomendamos agregar enlace de token al proceso de autenticación FIDO2 si es posible, o al menos limitar el uso del token OIDC o de respuesta SAML de cada autenticación exitosa para que se use una vez.
Es preocupante que las excelentes funciones de seguridad de FIDO2 no protejan toda la sesión del usuario. Es importante comprender que los métodos de autenticación modernos no son un amuleto mágico de seguridad, y no basta con comprarlos e implementarlos: es necesario comprender profundamente sus pros y sus contras.
Para aprender más sobre la Silverfort, obtenga una demostración aquí.
