Los puntos ciegos del MFA de los que nadie habla

Iniciado por Dragora, Marzo 10, 2023, 12:04:23 PM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

Marzo 10, 2023, 12:04:23 PM Ultima modificación: Marzo 10, 2023, 12:07:12 PM por Dragora

La autenticación multifactor (MFA) se ha convertido hace mucho tiempo en una práctica de seguridad estándar. Con un amplio consenso sobre su capacidad para defenderse de más del 99% de los ataques de adquisición de cuentas, no es de extrañar por qué los arquitectos de seguridad lo consideran imprescindible en sus entornos. Sin embargo, lo que parece ser menos conocido son las limitaciones de cobertura inherentes de las soluciones MFA tradicionales. Si bien son compatibles con la conexión RDP y los inicios de sesión de escritorio local, no ofrecen protección para herramientas de acceso de línea de comandos remotos como PsExec, PowerShell remoto y similares.

En la práctica, significa que las estaciones de trabajo y los servidores siguen siendo tan vulnerables al movimiento lateral, la propagación de ransomware y otras amenazas de identidad a pesar de tener una solución MFA completamente funcional. Para el adversario, es solo cuestión de tomar la ruta de la línea de comandos en lugar del RDP para iniciar sesión como si no hubiera protección instalada en absoluto. En este artículo exploraremos este punto ciego, comprenderemos su causa raíz e implicaciones, y veremos las diferentes opciones que los equipos de seguridad pueden superar para mantener sus entornos protegidos.

El propósito principal de MFA: evitar que los adversarios accedan a sus recursos con credenciales comprometidas

MFA la medida de seguridad más eficiente de nuevo toma de control de la cuenta. La razón por la que tenemos MFA en primer lugar para evitar que los adversarios accedan a nuestros recursos con credenciales comprometidas. Entonces, incluso si un atacante pudiera apoderarse de nuestro nombre de usuario y contraseña, que es un escenario más que plausible, aún no podrá aprovecharlos para el acceso malicioso en nuestro nombre. Por lo tanto, es la última línea de defensa contra el compromiso de credenciales, que tiene como objetivo anular este compromiso de cualquier ganancia.

El punto ciego: MFA no es compatible con las herramientas de acceso de línea de comandos en el entorno de Active Directory

Si bien MFA puede cubrir completamente el acceso a SaaS y aplicaciones web, es significativamente más limitado cuando se trata del entorno administrado de Active Directory. Esto se debe a que los protocolos de autenticación de claves que se usan en este entorno, NTLM y Kerberos, se escribieron mucho antes de que existiera MFA y no lo admiten de forma nativa. Lo que significa es que todos los métodos de autenticación que implementan estos protocolos no se pueden proteger con MFA. Eso incluye todas las herramientas de acceso remoto basadas en CMD y PowerShell, de las cuales las más destacadas son PsExec y PowerShell remoto. Estas son las herramientas predeterminadas que utilizan los administradores para conectarse de forma remota a las máquinas de los usuarios con fines de solución de problemas y mantenimiento, y por lo tanto se encuentran en prácticamente cualquier entorno de AD.

Las implicaciones de seguridad cibernética: el movimiento lateral y los ataques de ransomware no encuentran resistencia.

Esta ruta de conexión remota convencional está, por definición, desprotegida de un escenario de credenciales comprometidas y, como resultado, se utiliza en la mayoría de los movimientos laterales y ataques de propagación de ransomware. No importa que haya una solución MFA que proteja la conexión RDP y evite que se abuse de ellos. Para un atacante, pasar de la máquina de paciente cero a otras estaciones de trabajo en el entorno con PsExec o PowerShell remoto es tan fácil como hacerlo con RDP. Es solo cuestión de usar una puerta en lugar de la otra.

La dura verdad: La protección parcial de MFA no es protección en absoluto

Por lo tanto, si ha pasado por el dolor de instalar agentes MFA en todos sus servidores y estaciones de trabajo críticos, lo más probable es que haya logrado poco para protegerlos de las amenazas de identidad. Este es uno de los casos en los que no se puede llegar a mitad de camino. O estás protegido o no lo estás. Cuando hay un agujero en el fondo del barco, no importa que todo el resto sea madera maciza. Y de la misma manera, si los atacantes pueden moverse lateralmente en su entorno proporcionando credenciales comprometidas a las herramientas de acceso de línea de comandos, ya no importa que tenga protección MFA para RDP e inicio de sesión de escritorio.

Las limitaciones de MFA en el entorno local también ponen en riesgo sus recursos en la nube

A pesar del cambio a la nube, más del 90% de las organizaciones mantienen una infraestructura de identidad híbrida con estaciones de trabajo y servidores administrados por AD, así como aplicaciones SaaS y cargas de trabajo en la nube. Por lo tanto, no solo los recursos básicos locales, como las aplicaciones heredadas y los recursos compartidos de archivos, están expuestos al uso de credenciales comprometidas debido a la falta de protección MFA, sino también las aplicaciones SaaS.

La práctica común hoy en día es sincronizar contraseñas entre todos estos recursos, por lo que se utiliza el mismo nombre de usuario y contraseña para acceder tanto a un servidor de archivos local como a una aplicación SaaS de la organización. Esto significa que cualquier ataque local que incluya el compromiso y el uso de las credenciales de los usuarios puede pivotar fácilmente para acceder a los recursos SaaS directamente desde las máquinas atacadas.

El cambio de paradigma: del AMF tradicional a la protección unificada de la identidad

La brecha que hemos descrito se deriva de cómo se diseña e implementa el MFA tradicional. La limitación clave es que las soluciones MFA de hoy se conectan al proceso de autenticación de cada recurso individual, por lo que si el software que realiza esta autenticación no admite MFA, como en las herramientas de acceso de línea de comandos de AD, no puede haber protección en blanco.

Sin embargo, hoy en día hay un nuevo enfoque que cambia el enfoque de colocar MFA en cada recurso individual al directorio, superando así la barrera por completo.

Silverfort es pionera en la primera plataforma de Protección de Identidad Unificada que puede extender MFA a cualquier recurso, independientemente de si admite MFA de forma nativa o no. Utilizando una tecnología sin agente y sin proxy, Silverfort se integra directamente con AD. Con esta integración, cada vez que AD recibe una solicitud de acceso, espera su veredicto y la envía a Silverfort. Silverfort luego analiza la solicitud de acceso y, si es necesario, desafía al usuario con MFA. En función de la respuesta del usuario, Silverfort determina si confiar en el usuario o no y pasa el veredicto a AD que otorga o deniega el acceso, respectivamente.

La innovación en este enfoque es que ya no importa si esta solicitud de acceso se realizó a través de RDP o línea de comandos y si admite MFA o no. Siempre que se haya hecho a AD, AD puede pasarlo a Silverfort. Por lo tanto, al pasar de la protección MFA a nivel de recursos a la protección MFA en el nivel de directorio, el punto ciego del que los adversarios están abusando durante años finalmente se resuelve y se protege.

Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta