Acceso a Windows desde "Pass-the-hash"

Tradicionalmente se ha considerado que Windows no almacenaba las credenciales de sistema en claro en ningún momento. Ni siquiera en memoria, para evitar que pudiesen ser recuperadas de un equipo comprometido. La propia You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login de Microsoft inducia a ello.

Es por esto que se han popularizado en el mundo del pentesting las técnicas de You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login para poder You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login acceso a otros equipos de la red desde un sistema comprometido sin tener acceso a las credenciales en claro (aprovechando las características de la autenticación NTLM de Windows).

Pero un investigador francés apodado "Gentil Kiwi" ha You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login que esto no es del todo cierto. Veamos porque:

Dentro del sistema LSA (Local Security Authority) de Windows existen una serie de proveedores de autenticación activos por defecto, que podemos listar accediendo a su configuración en el registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages



You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

A primera vista muchos de estos nombres no revelan su utilidad. El más importante es You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login que es el utilizado para los procesos de logon en local si no existe un proceso de autenticación  personalizado. Cuando un usuario accede al equipo el servicio de LSA llama a MSV1_0 para que procese los datos recibidos por GINA (Graphical Identification and Authentication) desde el proceso Winlogon.

Además este proveedor almacena las contraseñas en memoria en forma de hashes, como estaba previsto, de manera que es relativamente seguro. Pero de la lista que hemos visto antes; ¿harán todos lo mismo?

Pues parece ser que al menos 2 de ellos no lo hacen así: tspkg y wdigest

• Tspkg es un proveedor de servicios de seguridad para conexiones SSO (Single-sign-on) con Terminal Server. Está disponible por defecto en los sistemas Windows Vista y posteriores. 
  

• Wdigest es un proveedor de servicios de seguridad para conexiones HTTP que requieran autenticación de tipo Digest. Está disponible por defecto en los sistemas Windows XP y posteriores. 
  

Ambos almacenan en memoria las credenciales de los usuarios que hayan accedido al sistema en local o mediante escritorio remoto codificadas de forma reversible. Es decir, la contraseña puede ser obtenida en claro sin necesidad de un proceso de cracking.

Aunque no conectemos nunca con servidores que requieran autenticación de tipo Digest o no utilicemos nunca conexiones de escritorio remoto con SSO, tendremos alguno de estos 2 módulos habilitados por defecto y nuestras contraseñas estarán accesibles en memoria.

Para recuperar las credenciales en claro solo es necesario contar con privilegios de Debug sobre el proceso LSASS. Privilegios normalmente disponibles para los usuarios del grupo de administradores.

Podemos comprobarlo con la herramienta que el propio "Gentil Kiwi" nos proporciona: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
 



You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Esta demostración esta realizada en un sistema Windows 7, pero cualquier Windows XP o posterior sería vulnerable por defecto.

Solo nos queda preguntarnos porque este hecho ha tardado tanto tiempo en salir a la luz. ¿Se ha ocultado intencionadamente esta información por parte de Microsoft? ¿Los investigadores punteros en materia de seguridad tenían guardado este as en la manga? ¿O tal vez nadie se había dado cuenta antes?

Ramón Pinuaga
Dep. Auditoría S21SEC

Gran aporte! Stiuvert salu2