Password Files & Authentication
En esta práctica veremos como están formados los archivos passwd y shadow en Linux y SAM en Windows y como se maneja la autenticación en estos SO.
Last updated
En esta práctica veremos como están formados los archivos passwd y shadow en Linux y SAM en Windows y como se maneja la autenticación en estos SO.
Last updated
passwd
y shadow
Objetivo de la Practica del curso de CEH de la UTN:
Dentro de los entornos de los distintos SO, encontraremos archivos que tienen una gran importancia respecto a la autenticación, son el archivo passwd
y el shadow
, de las distribuciones de LINUX o el archivo SAM
de Windows. El ejercicio de aquí es analizar y detallar esos archivos y describirlos lo mejor posible.
Anteriormente en Linux las credenciales de usuario solían ser almacenadas directamente en el archivopasswd
. No obstante por limitaciones y cuestiones de seguridad actualmente solo almacena información de las cuentas de usuarios, mientras que los hashes de los passwords se almacenan en el archivo shadow
.
El archivo se encuentra comúnmente en la siguiente ubicación /etc/passwd
y su contenido es de texto plano. Generalmente el acceso de solo lectura es permitido dado que muchas utilidades utilizan su contenido para relacionar IDs
a las correspondientes cuentas de usuario. Dentro del mismo podemos encontrar una lista de system accounts
. De cada cuenta se exponen las siguientes piezas de información: Username
, Password
, UID
, GID
, UserID Info
, Home Dir
, Command/Shell
. Veamos que significa cada uno y como es la estructura general de este archivo y sus datos.
/etc/passwd
Ya mencionamos que el archivo passwd
almacena información en texto plano. Dicha información es almacenada de a una entrada por línea. Cada línea delimita sus campos usando los dos puntos :
.
Veamos un diagrama de la estructura de cada línea.
Veamos una descripción sobre que función cumple cada una de las partes:
Username: Comúnmente usado para el proceso de login, de longitud entre 1 y 32 caracteres.
Password: Un carácter x
que indica que el password hash esta almacenado en el archivo /etc/shadow
.
UID (User ID): A cada user se le asigna un ID
, siendo 0
reservado para el root
, los de 1 a 99
reservados para cuentas predefinidas, los de 100 a 999
reservados para cuentas administrativas y de sistema. Finalmente los IDs superiores a 1000
son asignados para los usuarios.
GID (Group ID): El grupo primario al que pertenece el user, almacenado en /etc/groups
.
UserID Info: Permite almacenar información adicional del usuario, como ser el nombre del servicio
(service accounts) o detalles del tipo Nombre completo del user
.
User Home Directory: La ruta absoluta la carpeta home del user en cuestión.
Comando o Shell: Indica el shell
o comando
. Comúnmente es un shell
pero no es siempre el caso.
Permisos: Este archivo suele ser de solo lectura
para los usuarios y propiedad de root
.
/etc/passwd
Veamos que contenido obtenemos al ejecutar el comando en alguna de nuestras máquinas virtuales.
cat /etc/passwd
vemos que los resultados incluyen una larga lista de cuentas de administración, servicios y finalmente usuarios.
/etc/shadow
Ya mencionamos que actualmente las credenciales en Linux residen en gran parte en el archivo /etc/passwd
pero también mencionamos que el password hash
de cada usuario se almacena en el archivo llamado /etc/shadow
. Veamos en detalle como es la estructura de este otro archivo.
De igual forma que en el archivo /etc/passwd
la data dentro de /etc/shadow
se almacena también línea por línea. Incluso cada una de las líneas de este archivo se corresponde 1 a 1 con las del archivo password
.
Incluso existen herramientas como unshadow
(parte de JohnTheRipper) que nos permite recombinar los archivospasswd
y shadow Para luego crackearlos rápidamente con
John.
Username: El Nombre del usuario.
Password Encriptado: El password encriptado, usualmente sigue un patrón de este estilo $tipo$Sal$Hash
.
Donde el tipo
es el algoritmo de hash que fue usado para encriptar el password.
$6$: Indica el uso de SHA-512.
$5$: Indica el uso de SHA-256.
$2a$: Indica el uso de Blowfish.
$1$: Indica el uso de MD5 Hash.
$2y$: Indica el uso de Eksblowfish.
La Sal
(salt
en ingles): es un valor que se utiliza para garantizar la aleatoriedad del hashing, de manera que el hash resultante siempre sea distinto.
Finalmente el Hash value
: El resultado de hash generado para el encriptado de nuestro password.
Ultimo cambio de password: Representa una fecha en días, contando desde el primero de enero de 1970 hasta el día de hoy.
Edad mínima del password: Normalmente se setea en cero indicando que el no hay un mínimo establecido para la caducidad del password. Si contiene otro valor, el mismo representa la cantidad de días que deben transcurrir para cambiar el password.
Edad máxima del password: Número de días antes de que el password expire.
Período de Advertencia: La cantidad de días antes de que el password expire. Por ejemplo un valor de 6 le recordará al usuario cambiar el password 6 días antes de que el password caduque.
Período de Inactividad: El número de días luego de que el password haya vencido donde la cuenta de usuario quedará desactivada. Normalmente esta en cero.
Fecha de expiración: La fecha donde la cuenta de usuario fue efectivamente deshabilitada.
Sin Uso (Reservados para futuro uso): Actualmente es ignorado, se guarda para futuros posibles usos.
Hasta acá vimos como esta compuestos los archivos /etc/passwd
y /etc/shadow
y como se organiza y encripta la información dentro de ellos.
En Windows las contraseñas son almacenadas en el archivo SAM. Este archivo es en realidad una base de datos, donde Windows almacena las contraseñas en formato de hashes. Para generar estos hashes Windows ha utilizado distintos mecanismos a lo largo de las versiones. En particular nos centraremos en las siguientes: LM, NT-Hash(NTLM, NTLMv1 y NTLMv2)
.
LM Hash es la forma antigua en la que Windows almacenaba las contraseñas y se remonta a los años '80. Las principal desventaja de este hash es que trabajaba con un set de caracteres limitados (14 caracteres), lo cual lo convertía en uno muy fácil de crackear. Internamente los hashes se generan mediante un mecanismo muy débil en general y la longitud del set de caracteres no es su única desventaja.
Wikipedia: Data Encryption Standard (DES) es un algoritmo de cifrado, es decir, un método para cifrar información. DES fue sometido a un intenso análisis académico y motivó el concepto moderno del cifrado por bloques y su criptoanálisis. Hoy en día, DES se considera inseguro para muchas aplicaciones. Esto se debe principalmente a que el tamaño de clave de 56 bits es corto; las claves de DES se han roto en menos de 24 horas. . Se cree que el algoritmo es seguro en la práctica en su variante de Triple DES, aunque existan ataques teóricos. Desde hace algunos años, el algoritmo ha sido sustituido por el nuevo AES (Advanced Encryption Standard).
Veamos rápidamente como opera el algoritmo LM:
Conversión: Se convierten todas las letras minúsculas de la contraseña a letras mayúsculas.
Modificación: Se agregan al password caracteres nulos (NULL) hasta completar los 14 caracteres.
División: Se separa el password en dos bloques, cada uno de 7 caracteres.
Generación de KEYs: Se generan 2 claves DES para cada bloque.
Cifrado: Se cifra cada bloque con DES y un texto fijo con el valor KGS!@#$%
.
Hash Generado: El hash se genera en base a la concatenación de ambos bloques encriptados con DES.
Considerando la facilidad con la que se puede crackear, LM Hash fue desactivado por defecto con la salida de Windows Vista y Windows Server 2008. No obstante aún se mantiene una retro compatibilidad para sistemas legacy y puede ser activado manualmente mediante una Group Policy (GPO).
Podemos ver este hash en acción usando una herramienta como la que se encuentra online en este link.
Como podemos observar los Hashes generados para cada contraseña en formato LM resultan iguales luego de la conversión, esto se debe al primer paso que lleva adelante el algoritmo, la conversión de minúsculas a mayúsculas. Si observamos los hashes resultantes en formato NTLM, vemos que son diferentes para cada contraseña.
Veamos que tan sencillo es crackear ese hash usando una herramienta como hashcat
.
hashcat -m 3000 -a 3 hash
Dentro de la VM demoró 10min aproximadamente en crackear el password:
Como vemos es relativamente simple y rápido el proceso de crackeo de los hashes LM.
Actualmente en Windows se utiliza un mecanismo de hash conocido como NT Hash o NTLM Hash. Existen varias versiones de este hash que han ido mejorando la seguridad del mismo. Veamos rápidamente las características principales de cada versión.
El protocolo NTLM es un sistema del tipo Challenge-Response
el cual utiliza el intercambio de 3 mensajes para autenticar al cliente y un cuarto mensaje opcional para la integridad del intercambio. El hash tiene una longitud de 128 bits y funciona tanto para cuentas locales como para cuentas de dominio de Active Directory.
El algoritmo para este protocolo es bastante simple para la generación del hash, y hace uso de ambos tipos de hash: LM Hash y NT Hash
. Esta versión 1 de NTLM ya esta deprecada siendo actualmente mantenida para retro compatibilidad con sistemas viejos.
El algoritmo para esta versión de NTLM es bastante simple de comprender a alto nivel:
Conversión: Se convierte la contraseña a Unicode (UTF-16-LE).
Modificación: Para cada carácter agrega un 0 (Zero byte)
Hashing: Finalmente aplica el algoritmo MD4 al resultado del proceso anterior.
El algoritmo en concreto se puede consultar en Wikipedia, pero para referencia se ve así:
Wikipedia: El algoritmo en concreto se ve de la siguiente forma. [LINK]
Veamos como podemos crackear este nuevo hash usando hashcat
y un hash de ejemplo.
Hash de ejemplo (De la página de hashes de hashcat): [LINK]
u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c
hashcat -m 5500 -a 3 ntlm_v1_hash
Esta vez le tomó a hashcat unos 5 minutos aproximadamente para crackear el hash.
Como podemos notar el proceso de crackeo de la versión NTLMv1 es también relativamente simple y rápido.
La versión 2 de NTLM continúa usando el protocolo NTLM de formato challenge-response
que vimos antes, pero incorpora mejoras de seguridad y criptografía para hacerlo más seguro y reemplazar a NTLMv1. También se incorpora el uso de HMAC-MD5 como algoritmo de Hashing y se incorpora el nombre de dominio como variable para el proceso de autenticación.
Negociación: Se genera el challenge de 8 bytes
y es emitido por el server.
Respuesta: Se generan 2 bloques de 16 bytes con hashes HMAC-MD5
a modo de respuesta al challenge
. Estos bloques de respuesta incluyen también un challenge
generado en el lado del cliente, el password hash (HVAC-MD5) y puede incluirse otra información de identificación.
Respuesta Corta (shorter-response): En este bloque de respuesta se incluyen los 8 bytes del challenge
del lado de cliente y los 16 bytes de del bloque
. Esto genera un bloque de respuesta de 24 bytes
consistente con el formato usado en NTLMv1
.
Segunda Respuesta: El segundo bloque de respuesta usa un challenge
de longitud variable, que incluye entre otras cosas: el horario actual en formato NT Time
, un valor aleatorio de 8 bytes
, el nombre de dominio
e información estándar adicional. Considerando que esta respuesta debe incluir el challenge
del lado del cliente, su longitud variara en cada caso.
El hash resultante se puede apreciar en el siguiente ejemplo obtenido en la página de hashes de hashcat:
NTLMv2 Hash: [LINK]
admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030
El algoritmo se puede ver en detalle en el artículo de Wikipedia, el cual proporciona información adicional.
Wikipedia: El algoritmo en concreto se ve de la siguiente forma. [LINK]
Hasta aquí vimos los diferentes tipos de manejos de passwords en Windows. Para no terminar la práctica sin aprender alguna herramienta que nos permita interactuar con estos hashes almacenados en SAM, veamos como podemos extraer estos hashes de un host Windows
usando mimikatz
y posteriormente crackearlos usando hashcat
. No obstante no ahondaremos en detalle en como utilizar mimikatz en sí, sino que lo utilizaremos rápidamente para hacer un dump de los hashes. Quizás cubra el uso de mimikatz en otro escrito a futuro, dado que es una herramienta sumamente interesante.
Descarga mimikatz desde su repositorio: [LINK]
Deberás desactivar Windows Defender, dado que mimikatz es detectado como archivo malicioso.
El primer paso es obtener una copia del archivo SAM, para lo cual usaremos la terminal de Powershell (como Admin) y copiaremos los archivos SAM
y SYSTEM
a nuestra carpeta de trabajo.
Deberíamos tener algo similar a esto luego de realizar ese proceso:
Ahora necesitamos abrir una consola, idealmente como administrador, y navegar hasta la carpeta donde tenemos nuestro export y mimikatz
.
Lo siguiente es ejecutar mimikatz desde la terminal de Windows (PowerShell):
Ahora debemos indicarle a mimikatz que queremos extraer los hashes de archivo SAM y para ello debemos hacer uso del siguiente comando:
Como vemos mimikatz extrae los hashes presentes en la base de datos de SAM:
Por último usaremos nuevamente a nuestro amigo fiel hashcat
para tratar de crackear el password de la cuenta administrador
. Como podemos ver el hash esta en formato NTLM.
hashcat -m 1000 -a 3 hash
Hashcat demora nuevamente unos minutos en crackear el hash.
Hasta aquí hemos visto como funciona el manejo de passwords tanto en Linux como en Windows y como podemos crackear distintos tipos de hashes usando mimikatz
y hashcat
. Cabe mencionar que también existe otro protocolo de autenticación que no hemos visto en esta práctica llamado Kerberos
que es comúnmente usado para autenticación contra dominios como Active Directory
.
Kerberos no forma parte del alcance de esta práctica y lo veremos en detalle más adelante.
Ha sido una práctica extensa y que me ha permitido estudiar bastante sobre los temas cubiertos, principalmente sobre el funcionamiento de autenticación en Windows que no lo tenía muy presente.
Estas prácticas están sujetas a modificaciones y correcciones, la versión más actualizada disponible se encuentra online en el siguiente link.