Un trabajo de investigación.

Aquí les traigo la presentacion de ecryptfs y crackeo de passwords dictados en nuestro curso de Criptografía

La idea vino a mí después de la utilización de un rasgo de Ubuntu que consiste en el cifrar el directorio de carpeta Home. Esta opción puede ser seleccionada durante la instalación o activada más tarde.

Si usted selecciona esta opción, no cambiará nada para el usuario pero los datos en su carpeta Home son cifrados. me interesó saber como trabaja el desciframiento para la fase de solicitud de pass. Descubrí que eCryptfs está incluido en el Kernel GNU/LINUX y las herramientas llamadas ecryptfs-utils son usadas para cifrado la carpeta Home de la distro Ubuntu.

Después de leer el código, descubrí como se realiza el cifrado. Primero se genera aleatoriamente un passphrase de 16bytes; Este passphrase será usado con AES-128 para encriptar y desencriptar los datos en la carpeta HOME. Este passphrase cifrado es almacenado en el archivo siguiente:

/home/.ecrpytfs/$USER/.ecrpytfs/wrapped-passphrase

El proceso de encriptar el passphrase es llamado key wrapping. Al generar una wrapping key o llave de envoltura, se cubre el passphrase, una parte de 8bytes y una contraseña son concatenados y asignados como entrada a SHA-512. El resultado es hasheado otra vez 65535 veces.

Los primeros 16 bytes del resultado son la llave de proteccion o Wrapping key. El resultado intermedio es hasheado otra vez y los primeros 8 bytes de esta operación representan la firma de la wrapping key. El passphrase es cifrado con la llave que usa AES-128 y almacenado con la firma en el archivo wrapped-passphrase como se ve aquí:

Para desempaquetar la llave el proceso es similar, el user y la contraseña son hasheados 65536 veces.

El resultado es hasheado otra vez. Si la firma de 8 bytes coincide con el archivo entonces eCryptfs detectará que la llave generada es correcta. Así puede desempaquetar el passphrase para el desciframiento de archivo. Desde el punto de vista de un atacante, para recuperar el passphrase, sería con el uso de fuerza bruta al passphrase con datos encriptados. Sin embargo ya que al azar se genera una llave de 16 bytes la precuperación con fuerza bruta no resulta práctica. El atacante también puede intentar la fuerza bruta a la contraseña usada durante el wrapping de la llave y así él sería capaz de generar la el wrapping key y recuperaría el passphrase. Él podría usar diccionarios precalculados sobre la firma para recuperar la contraseña

En este punto, noté que, para sistemas Ubuntu, la contraseña usada en el proceso de envoltura es directamente la contraseña de login. Esto explica por qué no preguntan ninguna información adicional realizando el desciframiento de carpeta Home.
Lo que quiere decir que un atacantesería capáz de crackear  el pass del wrapping obteniendo no solo el passphrase, sino también la contraseña de usuario.
Después vi como el nombre es generado ya que no es almacenado en ninguna parte del archivo wrap-passphrase.
Finalmente encontré en el código, que ecryptfs-utils busca el nombre en el archivo de configuración

$HOME/.ecryptfsrc

Si el archivo no existe, un valor por defecto de 0x0011223344556677 es usado. Este comportamiento ya había sido notado antes. Para un sistema que usa eCryptfs, como el archivo de configuración es almacenado en la (ahora cifrada) carpeta Home que no pudo ser encontrado, entonces el valor del nombre por defecto es usado para desencriptar la carpeta Home.
En términos prácticos esto significa que, para un sistema que usara esta versión de eCryptfs el valor de nombre usado debe ser el valor por defecto. Si no, hará un encriptado inicial usando un nombre de ~/.ecryptfsrc que nunca fuera descifrado correctamente. como ahora no se puede encontrar el archivo config, eCryptfs aplicaría el nombre por defecto en el momento de desencriptado

Limpiamente un ataque de diccionario precomputado o un ataque de rainbow table puede ser montado contra tal sistema para crackear  las contraseñas de usuario.
Estructurando el ataque con mi instrumento favorito: John the ripper (JTR), descubrí que el algoritmo ya fue puesto en práctica en la versión 1.8.0 jumbo. El formato es:

$ecryptfs$0$1$0011223344556677$21ff10301b5457e1

donde el valor rosado es obviamente el nombre y el valor verde es la firma correspondiente a la contraseña que se quiere crackear.

También noté una script de Pitón ecryptfs2john.py, en JTR que lee el archivo wrapped-passphrase y lo convierte al formato correcto. El algoritmo también es puesto en práctica en hashcat.

Como una prueba de concepto, calculé un diccionario de 14 millones de firmas basadas en la famosa rock u diccionary. Esto me tomó aproximadamente un mes sobre mi ordenador personal.Pero con este diccionario ahora es posible invertir una firma lookup, asumiendo que el pass estaba en la lista de rockyou.


Desde luego sky security notificó a los desarrolladores de  ecryptfs-utils sobre el problema con distribuciones Ubuntu, un CVE fue abierto y rápidamente corregido. Ellos publicaron un nuevo formato de archivo para el archivo wrap-passphrase. Ahora comienza con 0x3a02. el nombre es generado de/dev/urandom/y almacenada en el mismo archivo por omisión. Los viejos archivos de versión automáticamente son convertidos después de la actualización y un logoff.
El nuevo contenido de archivo debería parecerse a esto:






Incluso con la corrección, la contraseña de usuario todavía sigue expuesta al ataque de bruteforce con un nombre al azar. Sin embargo en el estándar Linux la contraseña hashing es de 5000 iteraciones de SHA-512 que es más fácil para crackear comparado a las 65536 iteraciones de eCryptfs. Como tal, y debido al empleo dual de esta contraseña la puesta en práctica eCryptfs es un objetivo menos interesante para un entusiasta del cracking.
En el artículo usamos salt como nombre para volverlo mas comprensible a quienes recien ven sobre criptografia; salt se refiere a un dato random usado como entrada adicional.

herramientas usadas:
http://ecryptfs.org
http://www.openwall.com/john/
http://pastebin.com/imQumQA0

referencias:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9687%20CVE-2014.9687