Resistencia al phishing primero
La autenticación resistente al phishing es la línea de base actual para la autenticación segura, lo que significa FIDO/WebAuthn, FastPass, PIV/CAC, etc. Esta publicación se centrará en cómo aquellos que ya cumplen con esta línea de base pueden llevar la seguridad al siguiente nivel.
Las contraseñas, los SMS, las notificaciones push y los códigos de un solo uso son vulnerables a ataques mucho menos sofisticados que los descritos en este artículo, por lo que no los recomendamos.
Dónde se queda corta la resistencia al phishing
Como se señaló anteriormente, FastPass, Passkeys y otros autenticadores FIDO son una excelente manera de proteger a tu organización contra ataques de phishing, lo que esencialmente requiere que el atacante obtenga algún tipo de presencia en tu dispositivo (o incluso robe físicamente una clave).
Los autenticadores resistentes al phishing se basan en dos requisitos definidos por el NIST, Verifier Name Binding y Channel Binding [este es un borrador de especificaciones, los comentarios están 'cerrados'], que en conjunto evitan con éxito la mayoría de los ataques de phishing. Tanto FIDO como FastPass se basan en Verifier Name Binding, por ejemplo.
Además de estos requisitos, los autenticadores resistentes al phishing deben crear un canal protegido entre el navegador y el autenticador para evitar escuchas o ataques de retransmisión a un dispositivo remoto. Pero los requisitos no tienen en cuenta la presencia de software malicioso en el dispositivo del usuario. Como resultado, puede producirse una clase de ataques más sofisticados y, cuando tienen éxito, permiten a los atacantes satisfacer los requisitos de resistencia al phishing.
Ejemplo de ataque: Autenticación entre dispositivos a través de SOCKS
Imagina a una víctima que hizo clic en un enlace que instaló malware en su sistema. Como base para este ataque, el atacante ya debe poder ejecutar código como el usuario en su máquina.
|
1 |
El atacante crea un proxy inverso SOCKS entre el dispositivo comprometido y su propio dispositivo (Paso 1 en el diagrama). Con la configuración correcta, el atacante puede retransmitir los desafíos FastPass o FIDO2 desde su propio dispositivo al dispositivo comprometido a través del proxy SOCKS. |
|
2-3 |
El atacante intenta acceder a los recursos del usuario desde su propio dispositivo y retransmite el desafío de autenticación al dispositivo del usuario a través del proxy. |
|
4 |
El navegador sondea directamente desde el dispositivo del atacante al servidor de Okta, esperando que se cumpla el desafío de autenticación. |
|
5 |
El atacante debe hacer que el dispositivo comprometido firme la respuesta al desafío con su TPM.
Una política bien configurada requerirá la presencia del usuario, lo que activará una solicitud al usuario para datos biométricos o el código de acceso del dispositivo, lo que puede despertar las sospechas del usuario. Dado un escenario en el que hay malware en el dispositivo, sin embargo, el atacante puede proporcionar un código de acceso o programar el ataque de forma inteligente de modo que el usuario no se sorprenda por la solicitud (por ejemplo, cuando el usuario está lejos de su máquina o espera una solicitud de autenticación de todos modos). |
|
6-8 |
Finalmente, la respuesta al desafío se envía desde el dispositivo comprometido al servidor de Okta, pasando las comprobaciones de clave TPM, la resistencia al phishing y las garantías de confianza del dispositivo.
Como resultado, el dispositivo del atacante ahora tiene una sesión válida porque pudo hacer un proxy transparente de la autenticación entre su navegador web y el autenticador en el dispositivo comprometido. |
Ingrese Filtros de aplicaciones de confianza
En agosto de 2024, Okta lanzó una función para mitigar este tipo de ataque para FastPass: Trusted App Filters. Esta configuración de alta seguridad permite a los administradores bloquear automáticamente cualquier intento de autenticación por parte de aplicaciones que no estén específicamente en la lista de permitidas o que no estén firmadas en absoluto o estén firmadas por un certificado de firma de código no confiable.
Cómo funciona
Cuando una aplicación como Chrome intenta autenticarse utilizando FastPass, el widget de inicio de sesión de Okta intentará conectarse a Okta Verify que se ejecuta en el dispositivo y luego entregará el desafío de autenticación desde el backend de Okta.
Mientras esta conexión está activa, Okta Verify rastrea el puerto y el proceso que creó la conexión en el dispositivo. Si no se puede encontrar el puerto y el proceso, puede indicar que el origen fue remoto y la conexión se interrumpe.
Si se puede identificar el proceso, Okta Verify recopila datos de firma detallados sobre el ejecutable, verificando que la firma coincida con el certificado de firma de código y que el certificado de firma de código sea de confianza para la cadena de confianza local.
Por ejemplo, usamos SecCodeCopySigningInformation (macOS) WinVerifyTrust (Windows) para obtener información detallada sobre el proceso. Una vez que se capturan todos estos datos, se envían en una respuesta de desafío junto con la certificación de administración y las señales del dispositivo, todo envuelto y firmado con una clave ligada al hardware.
Supervisión
Si usas FastPass en macOS o Windows, esta información está disponible actualmente en tus SysLogs.
Este es un ejemplo de inicio de sesión en el Okta Dashboard usando Chrome para macOS.
A medida que revisas tus registros, puedes ver con qué aplicaciones se están autenticando tus usuarios y crear flujos de trabajo para alertarte sobre las nuevas aplicaciones que se están utilizando. Querrás tener una buena comprensión de qué binarios están asociados con las aplicaciones a las que se accede en tu organización. Por ejemplo, los usuarios deben autenticarse con Slack solo a través de un navegador o la aplicación nativa de Slack.
Aplicación
Después de haber compilado una lista completa de aplicaciones que se aplican a una política de autenticación determinada, puede aplicar Filtros de Aplicaciones Confiables para bloquear estos ataques antes de que comiencen. Esto puede ser un poco complejo, por lo que es más sencillo crear reglas de política de autenticación separadas para cada plataforma de escritorio (por ejemplo, establezca la regla de garantía de plataforma o dispositivo en macOS o Windows para una regla determinada).
Una vez que su Lenguaje de Expresiones esté en su lugar, cualquier aplicación que no pase la verificación de la firma (por ejemplo, malware no firmado) será bloqueada, junto con la entrada de SysLog relevante. Las aplicaciones firmadas que no están en la lista (como el demonio SSH) también serán bloqueadas.
Ejemplo 1: Chrome, Firefox y Safari en macOS
En este ejemplo, permitimos todos los principales navegadores compatibles con macOS, utilizando la extensión SSO o los enlaces Loopback. Esto significa que solo los dos enlaces resistentes al phishing activarán la regla para FastPass. Ten en cuenta que las aplicaciones nativas con sus propias vistas web como O365 no cumplirían con esta regla. Si deseas permitirlas, también deberás incluir sus identificadores.
Ejemplo 2: Edge y Chrome en Windows
Windows es un poco más sencillo, ya que LOOPBACK es el único enlace válido para esta comprobación. Tenga en cuenta que esto también evitará los flujos no resistentes al phishing activados por el enlace CUSTOM_URL.
Combinación de filtros de aplicaciones de confianza con FIDO u otros autenticadores
Si deseas utilizar un autenticador diferente de FastPass, por ejemplo, una clave de seguridad FIDO, también puedes aplicar filtros de aplicaciones de confianza en esa regla de autenticación, siempre que una cuenta de Okta Verify esté inscrita también en ese dispositivo.
Para hacer eso, cree una regla con todo lo siguiente:
- Una condición registrada o administrada
- El lenguaje de expresión de los filtros de aplicaciones de confianza
- Permita los autenticadores que le gustaría apoyar, o utilice "Permitir cualquier método"
Si estás utilizando FastPass en macOS o Windows en tu organización, ¡puedes comenzar a monitorear qué aplicaciones nativas están activando la autenticación de FastPass hoy mismo! Una vez que tengas una idea clara de qué aplicaciones confiables se están utilizando, debes poner en la lista de permitidos esas aplicaciones y evitar que todas las demás utilicen FastPass.
Si quieres ver más sobre este tema, incluyendo una gran demostración de Zach Newton, consulta nuestra charla de Oktane 2024 (requiere registro gratuito).
¿Tiene alguna pregunta sobre FastPass o seguridad del dispositivo? Únase al foro de la comunidad de Okta FastPass e inicie una conversación.
¿Tiene preguntas sobre esta publicación de blog? Contáctenos en eng_blogs@okta.com.
Explora más Blogs de Ingeniería de Okta para ampliar tus conocimientos.
¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visita nuestra página de empleo.
Desbloquea el potencial de la gestión de identidad moderna y sofisticada para tu organización. Ponte en contacto con ventas para obtener más información.
