Notas sobre la gestión de credenciales en Windows

RESUMIENDO

Cuando las aplicaciones requieren autenticar a un usuario, estás pueden enviar la petición a SSPI especificando el servicio al que sean acceder, los parámetros necesarios, como el SSP a utilizar, y las credenciales necesarias, si éstas no han sido cacheadas por Windows ya durante el inicio de sesión. SSPI examinará el contenido de la petición y lo pasará al SSP correspondiente para que lleve a cabo la autenticación y devuelva el resultado a SSPI. Éste, entonces, lo comunica a la aplicación.

Más información: https//technet.microsoft.com/en-us/library/dn751047(v=ws.11).aspx

NOTAS:

SSP Digest

• Puede ser implementado por aplicaciones cliente/servidor que utilicen comunicaciones en HTTP o SASL.
• Las credenciales se envían sobre la red en forma de  MD5 o mensaje Digest.
• Fue introducido en Windows XP, y conserva la contraseña cifrada en memoria de una manera que puede ser descifrada (la contraseña de cifrado fue publicada por Microsoft)
• Deshabilitado por defecto desde Windows 8.
• Este es el principal culpable de que herramientas como Mimikatz y WCE sean capaces de extraer contraseñas en texto claro.

SSP Negotiate

Se utiliza para negociar el protocolo de autenticación a utilizar. Este puede realizarse:

1.- Especificando un único protocolo de autenticación

2.- Se negocia el protocolo, mediante el mecanismo: Simple and Protected GSSAPI Negotation Mechanism (SPNEGO)

Single Sign-On

Permite suministrar las credenciales sólo una vez, sin necesidad de introducirlas una y otra vez.

Es importante entender que el proceso de autenticación se produce, pero es transparente para el usuario. Para ello, Windows guarda localmente en memoria las credenciales, concretamente gracias al subsistema: LOCAL SECURITY AUTHORITY (LSA)

Las técnicas: Pass-the-hash y Pass-the-tickets, abusan de ésta característica para obtener los hashes y tickets kerberos

Local Security Authority (LSA)

Es un subsistema protegido que autentica y permite la autenticación de usuarios en las máquinas.

En general, es responsable de:

• Administrar la política de seguridad local
• Proporcionar los servicios para la autenticación o inicio de sesión interactivo
• Genera tokens de acceso
• Administra las políticas de auditoria

NOTA:

Access Token: es un objeto o estructura de datos que describe el contexto de seguridad de un proceso o hilo. Cuando un usuario inicia sesión en un sistema Windows, el sistema comprueba que las credenciales son correctas y LSA genera un access token asociado a dicho usuario. Posteriormente, todo proceso ejecutado por este usuario tendrá asignado un access token derivado de dicho token. Por lo tanto, en Windows, todo proceso o hilo tiene un Access token asignado.

Esta estructura de datos contiene información con el SID de usuario, el SID de los grupos a los que el usuario pertenece, los privilegios asignados al usuario o sus grupos, referencia a su sesión de logon asociada para realizar Single Sign-On, etc.

Además, los access token forman parte del proceso de autenticación automática contra otros sistemas en la red, por lo que cada uno de ellos contiene la referencia a la sesión logon asociada, la cual se almacena en LSASS y contiene las credenciales necesarias para realizar el inicio automático de sesión.

Como añadido, cuando un usuario administrador local inicia sesión en una máquina, dos access tokens separados se crearán para este usuario: uno estándar y otro de administrador.

Más información: https//technet.microsoft.com/en-us/library/Windows/desktop/aa374909(v=vs.85).aspx

Dependiendo del tipo de cuenta a autenticar, LSA procederá:

• Si las credenciales son locales, LSA validará la información de usuario contra la BBDD local SAM (Security Accounts Manager
• Si las credenciales pertenecen a un dominio, LSA contactará con el controlador de dominio para verificar que la información facilitada es válida

Así mismo, y sólo en algunas ocasiones, LSA guarda ciertas credenciales en disco de manera cifrada. Algunas de estas credenciales son:

• Contraseña de la cuenta de equipo de AD. Esto se utilizará en aquellos casos donde la máquina necesite autenticarse mediante su cuenta de dominio AD pero el controlador de dominio no esté disponible en ese momento o no se disponga de conexión a la red.
• Contraseñas de las cuentas de servicios Windows configurados en la máquina
•  Contraseñas de las cuentas para las tareas programadas
•  Otras

Dentro de este subsistema, reside el proceso: LSASS (Local Security Authority Subsystem Service)

Local Security Authority Subsystem Service (LSASS)

Este proceso es el responsable, en última instancia, de imponer las políticas de seguridad en el sistema, administrar los cambios de contraseñas y crear access tokens. Así mismo, puede almacenar credenciales, aunque sólo de sesiones activas.

En cualquier caso …

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia.