Vulnerabilidad en OpenSSH permite enumerar usuarios (Time-Based Info Leak)
El pasado jueves 14 de julio se hizo pública una vulnerabilidad que afectaba a la última versión de OpenSSH, en concreto a OpenSSH 7.2p2. Esta ha sido recogida en el expediente CVE-2016-6210 dónde se explica que se pueden enumerar los usuarios en un sistema operativo a través del servicio OpenSSH, gracias a un leak de información basado en el tiempo de cómputo que tiene este tipo de servicios al procesar la criptografía.
El proceso de hashing que se lleva a cabo tiene un coste computacional, por lo que, si la contraseña que el usuario remoto envía es lo suficientemente grande, se producirá un retardo importante en el tiempo de respuesta. El info leak se produce ya que si el usuario no existe, el software de OpenSSH no hace el procesado criptográfico de la contraseña, por lo que la respuesta es de menor tiempo.
Si analizamos un flujo de ejecución se observa que cuando un usuario no existe solo disponemos del tiempo de comprobación de existencia de usuario, lo cual es algo, prácticamente, instantáneo. Cuando el usuario existe, la contraseña pasa por un proceso de hashing para llevar a cabo la comprobación. Esto hace que al tiempo de comprobación de existencia de usuario se le sume el tiempo de hashing, el cual es bastante más grande que el primero. Una posible mitigación es calcular el hashing de la contraseña tanto si el usuario existe como si no, con el fin de igualar tiempos de respuesta en ambos casos.
Otro error de configuración es que el usuario pueda incluir contraseñas enormes, las cuales no tienen sentido. En la prueba de concepto que se ha incluido en la publicación que se ha hecho en la lista Full Disclosure se puede ver como la contraseña enviada es de 25.000 A's.
Ejecutando el código publicado contra un servidor OpenSSH vulnerable observamos que si el usuario existe en la máquina remota el tiempo se encontrará cercano al segundo. En el caso de que el usuario no exista, la respuesta o corte de conexión se realizará en una magnitud de tiempo muy inferior.
Como se puede ver, el usuario "pablo" existe y, por lo tanto, obtenemos unos resultados grandes en lo que a tiempo de respuesta se refiere. El resto de usuarios que fueron probados dan resultados mucho más bajos, por lo que quiere decir que los usuarios no existen.
Esto podría llevarnos a pensar a que podríamos modificar el script de Python ligeramente para leer los nombres de usuario desde un archivo. Cada línea del fichero sería un nombre de usuario e iríamos probando por diccionario que usuarios se encuentran registrados en el sistema.
Contenido completo en fuente original El lado del mal
¿Dónde se encuentra la vulnerabilidad?
Cuando un usuario remoto envía un usuario y una contraseña al servidor OpenSSH, éste valida en primer lugar el nombre de usuario, y en segundo lugar si la contraseña es correcta o no. En el caso de que el usuario exista, el servidor OpenSSH necesita lidiar con la criptografía de la contraseña y para ello aplica un algoritmo SHA256/SHA512.El proceso de hashing que se lleva a cabo tiene un coste computacional, por lo que, si la contraseña que el usuario remoto envía es lo suficientemente grande, se producirá un retardo importante en el tiempo de respuesta. El info leak se produce ya que si el usuario no existe, el software de OpenSSH no hace el procesado criptográfico de la contraseña, por lo que la respuesta es de menor tiempo.
Si analizamos un flujo de ejecución se observa que cuando un usuario no existe solo disponemos del tiempo de comprobación de existencia de usuario, lo cual es algo, prácticamente, instantáneo. Cuando el usuario existe, la contraseña pasa por un proceso de hashing para llevar a cabo la comprobación. Esto hace que al tiempo de comprobación de existencia de usuario se le sume el tiempo de hashing, el cual es bastante más grande que el primero. Una posible mitigación es calcular el hashing de la contraseña tanto si el usuario existe como si no, con el fin de igualar tiempos de respuesta en ambos casos.
Otro error de configuración es que el usuario pueda incluir contraseñas enormes, las cuales no tienen sentido. En la prueba de concepto que se ha incluido en la publicación que se ha hecho en la lista Full Disclosure se puede ver como la contraseña enviada es de 25.000 A's.
Ejecutando el código publicado contra un servidor OpenSSH vulnerable observamos que si el usuario existe en la máquina remota el tiempo se encontrará cercano al segundo. En el caso de que el usuario no exista, la respuesta o corte de conexión se realizará en una magnitud de tiempo muy inferior.
Esto podría llevarnos a pensar a que podríamos modificar el script de Python ligeramente para leer los nombres de usuario desde un archivo. Cada línea del fichero sería un nombre de usuario e iríamos probando por diccionario que usuarios se encuentran registrados en el sistema.
Contenido completo en fuente original El lado del mal
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!