Español | English
rss facebook linkedin Twitter

Se acabo el 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 documentación de Microsoft inducia a ello.

Es por esto que se han popularizado en el mundo del pentesting las técnicas de Pass-the-hash para poder obtener 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 desvelado 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



A primera vista muchos de estos nombres no revelan su utilidad. El más importante es MSV1_0 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: mimikatz
 

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

7 comentarios:

Anónimo dijo...

Si no recuerdo mal, esto lleva ya tiempo pasando, con soft también como el de nirsoft es posible de "forma sencilla" hacer la preuba de concepto también

http://www.nirsoft.net/utils/network_password_recovery.html

Auditoría S21sec dijo...

Estamos hablando de las credenciales del sistema local (usuarios locales).

Las contraseñas para acceso a Carpetas de red, las que cachea el Internet Explorer, las del Protected Storage, etc. ya se sabia que se almacenaban de forma reversible y son recuperables con herramientas como la que comentas.

Anónimo dijo...

Perdón :-), entonces esto es un suma y sigue...recemos sólo para que esto pueda solventarse de alguna forma.
Gracias!

Auditoría S21sec dijo...

La solucion rapida seria desactivar los security packages vulnerables. El 90% de la gente no los utiliza nunca y es innecesario tenerlos activos por defecto.

Anónimo dijo...

A ver cuando lo añaden a meterpreter jeje

Anónimo dijo...

El TSPKG, por lo menos en mi humilde experiencia, es usado o necesario en entornos de Citrix/TS/RDS, para uso del SSO o acceso a servidores con el NLA activado, por lo que es una faena :-(

Anónimo dijo...

Usen las tildes, por favor, que son gratis. Esas faltas de ortografía hacen que no me pueda fijar en el contenido.


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login