¿Por qué es segura la Guardia de credenciales de Windows, cuando Windows puede "acceder" a las credenciales mediante RPC?

4

He leído algunos blogs que describen la Guardia de credenciales de Windows: cómo funciona y qué beneficios de seguridad ofrece.

Sin embargo, algunos de ellos mencionan que Windows puede "acceder" a las credenciales mediante las llamadas RPC al Modo seguro virtual (VSM).

Pero si el sistema operativo Windows puede comunicarse con VSM (Credential Guard), ambos ejecutándose en el hipervisor, ¿por qué un atacante con privilegios administrativos locales no puede hacer lo mismo?

NB: corríjame, si hay algún dato relacionado con Windows Credential Guard.

    
pregunta Shuzheng 18.11.2018 - 12:36
fuente

1 respuesta

5

En primer lugar, es importante saber qué protege y no protege Windows Credential Guard. Protege las credenciales de dominio que se han utilizado para iniciar sesión en el sistema actual, de modo que las herramientas como Mimikatz no pueden simplemente volcar LSASS y obtener credenciales almacenadas en caché en un formato que se puede usar para pasar a otros sistemas en la red. También protege las credenciales de dominio que se han utilizado para RDP. No protege las cuentas locales, los tickets de servicio de Kerberos (aunque Kerberos TGT está protegido), las credenciales de resumen o los verificadores de contraseña de inicio de sesión en caché (son hashes, no credenciales utilizables).

WCG forma parte de la nueva función de seguridad basada en virtualización (VBS) en Windows 10. La forma en que funciona es usar el hipervisor Hyper-V para ejecutar el sistema operativo principal y un sistema operativo secundario seguro en conjunto. El sistema operativo secundario seguro se conoce como Modo seguro virtual (VSM) y comprende el Modo de núcleo seguro (SKM) y el Modo de usuario aislado (IUM). Efectivamente, puede pensar en VSM como una especie de versión aislada de LSA, que se ejecuta fuera del sistema operativo.

Uno de los requisitos de seguridad clave para ejecutar VSM correctamente es habilitar el arranque seguro. Cuando está habilitado, todos los fragmentos de código desde el cargador de arranque de Windows al hipervisor Hyper-V al SKM e IUM están protegidos a través de una cadena de confianza firmada. Dado que la VM segura tiene numerosas funciones de seguridad habilitadas (SMEP, TPM, IOMMU / VT-d, SLAT), resulta imposible obtener ejecución de código en la VM segura sin algún tipo de vulnerabilidad de SMM o hardware. Como el sistema operativo normal (donde un atacante obtendría la ejecución del código) está virtualizado por separado por Hyper-V, está completamente aislado de la VM segura y no puede influir en él, excepto a través de las API expuestas.

Como tal, la única forma de acceder a los datos almacenados en el VSM es a través de las API expuestas. Estas API están expuestas solo al kernel (ring0) en el sistema operativo normal. El principio operativo principal de WCG es que actúa como un oráculo. Le pide que genere un token de inicio de sesión remoto para un sistema en particular usando credenciales almacenadas en caché, y lo hace. No puede ver las credenciales en caché y no puede usar el token generado para recuperar la credencial en caché o generar otros tokens de inicio de sesión. Tampoco puede usarlo para generar tokens maliciosos, como un ticket dorado de kerberos, que fue posible en el pasado a través de herramientas como Mimikatz.

Lecturas futuras que te pueden interesar:

respondido por el Polynomial 18.11.2018 - 13:29
fuente

Lea otras preguntas en las etiquetas