Estimados amigos de Inseguros !!!
Imaginas que en este post habláramos de la necesidad de usar claves seguras en el login... de más de 8 caracteres ... no !!! este post no va de eso.
Vamos a hablar de algunos aspectos de los mecanismos de autenticación básicos de los sistemas Microsoft que por comentarios y experiencia sospecho que no todo el mundo conoce.
Es importante conocer en profundidad los sistemas que manejamos, porque si todo va bien, es muy sencillo administrar un "guindo" pero si algún día tienes problemas, o sufres un incidente o tienes que estudiar si estás sufriendo un incidente... conocer estos términos te será fácil.
Vamos a empezar con el proceso de login, el denominado login interactivo. Es el que se produce cuando nos "sentamos" delante del equipo, cuando pulsamos ctrl+alt+spr. Dentro del login interactivo podemos incluir el que realizamos por RDP, podemos imaginar el RDP como un "túnel" en el que nos sitúa delante del pc. Realmente podemos denominarlo login remoto interactivo.
Cuando realizamos este login, estamos accediendo a la SAM ( Security Account Manager) o a un dominio. Es muy importante entender esto. Si usamos un pc de empresa por ejemplo, podemos autenticarnos contra el propio pc, o contra el dominio. Esto se puede modificar, ya lo sabemos, pero es importante entender estos conceptos. Si haces login en la SAM, en local, si entras a una carpeta de red de un pc de dominio, tendrás que autenticarte en el equipo destino.
*imagina usuario1/contraseña1 en pc1. imagina usuario1/contraseña2 en pc2. Cuando te conectas con usuario1 desde pc1 al pc2, pc2 te pedirá la contraseña2, la del equipo destino...*
Otro tipo de login interactivo es el que realizamos con una tarjeta, una smart card.
El siguiente grupo de logins es el denominado de red. El que realizas cuando te conectas a un recurso de red, como pueda ser una carpeta compartida o una GPO. Otro tipo de login puede ser como proceso Batch y como servicio.
Otro tipo de login muy interesante es el de la cache. Imagina un portátil corporativo que se inicia en casa del empleado sin haber levantado vpn contra la empresa. Usa las credenciales almacenadas en el equipo,por defecto 10 veces máximo, para autenticarse dentro de un entorno de dominio. Este comportamiento se debe cambiar, si los procesos de la empresa lo permiten, para evitar esta funcionalidad. Imagina un caso muy sencillo: se resetea la clave porque se ha comprometido. El atacante tendría 10 logins "locales" en el equipo hasta que sea obligado a autenticarse contra el DC con la nueva password...
Otro tipo de login, denominada 10 es el que se produce cuando ejecutamos Runas /netonly. Con este parámetro el equipo se ejecutará en local con el usuario que levanta la consola, es decir, el que se logueo en el sistema local, pero si el programa accede a la red, usará el equipo usuario proporcionado con el comando runas.
Una vez explicados los logins, vamos a hablar de los dos grandes proveedores de autenticación en los sistemas Microsoft, NTLM y KERBEROS.
Imagina que un equipo cliente se conecta a un servidor de ficheros. Mediante el handshake NTLM se establece una conexión entre pc y cliente, con un desafío o challenge que se cifra con el hash del password del fichero... y el servidor de ficheros comprueba la contraseña del cliente consultando al controlador de dominio... quien es el jefazo de la organización y conoce las claves de los usuarios.( el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector)
El proceso con Kerberos es algo distinto, ya que el el servidor de ficheros no se conecta al DC. El cliente solicita al DC un ticket de servicio para conectarse a un servidor destino, el DC le concede el ticket ( el funcionamiento de este mecanismo se ha simplificado para la comprensión del lector) y cuando el cliente se quiere conectar con el dichoso fileserver, le enseña ese ticket.
Voy a poner el ejemplo del parque de atracciones. Una persona entra al parque, y en la caseta le dan una pulsera. Cuando vas a la atracción, enseñas la pulsera. No va el tipo de la atracción a preguntar al de la caseta si realmente esa pulsera es válida. Entiende que si.
Un apunte sobre esta diferencia, cuando hacemos "barra barra" para conectarnos a un recurso de red, si usamos IP en vez de Nombre, estaremos usando NTLM en vez de Kerberos. Existen ataques muy conocidos para NTLM basados en man in the middle por lo que es una buena práctica generalizada usar siempre nombres DNS, no direcciones IP.
Tenemos otros proveedores de autenticación en los sistemas Microsoft, estos se denominan SSPI (Security Support Provider Interface) y aquí tienes todos los disponibles.
Esta imagen es la típica para explicar qué son estos interfaces.
Aquí aparece el famoso LSASS, el sistema local de autenticación, el encargado de recibir las credenciales del login y según el caso, equipo local ( SAM) o dominio ( DC) comprobar las credenciales. Otra función básicas del sistema LSA es proporcionar la "cache" de autenticación, es decir, lo que proporciona el Single Sign On del cliente. Te imaginas tener que meter la clave cada vez que accedes a un recurso del dominio? a una carpeta? a un buzón Exchange?
De esta manera, las credenciales "suelen" cachearse en memoria, en ese proceso. Haciendo Debug a ese proceso conseguimos obtener las credenciales en memoria con herramientas como Mimikatz. Vas hilando el asunto...? Una de las guías que más mecanismos de protección presenta es esta del SANS.
Estos tips son muy básicos y son cosas que pasan en tus Windows sin darte cuenta. Otro día haremos un troubleshooting y veremos cómo trackear todo esto, al igual que debugear el logon. Muchas veces nos encontramos con tipos de registros que no muestran el equipo externo. Imagina un Imap de Exchange expuestos a internet produciendo fallos de login en un DC... crees que va a salir la ip del malo en Rusia? es un ejemplo !!! no os lo tomeis todo al pie de letra.
Por supuesto que el propósito de este post no es ofensivo. Ni tan siquiera defensivo, es solo algo de conceptos que debes conocer.
Gracias por leerme !!!!