Las versiones de OpenSSH desde 2011 son vulnerables a ataques Oracle
OpenSSH continúa siendo vulnerable a los ataques Oracle, y el problema afecta a todas las versiones del paquete desde septiembre de 2011. Los desarrolladores corrigieron un error similar hace menos de una semana.
Los investigadores de seguridad de Qualys descubrieron un nuevo problema de enumeración de nombre de usuario en la última versión de OpenSSH. Permite a un atacante probar varios nombres de usuario en el servidor y determinar cuáles son válidos. La vulnerabilidad recibió el número de seguimiento CVE-2018-15919.
Qualys detectó el problema de la misma manera que el fallo anterior, mientras analizaba una confirmación en el código fuente de OpenBSD de la suite.
El problema esta vez se encuentra en el componente auth2-gss.c, activo por defecto en Fedora, CentOS y Red Hat Enterprise Linux, y posiblemente otras distribuciones.
Los investigadores de Qualys explican que cuando un usuario intenta autenticarse, el atacante recibe el mismo paquete, sea que el usuario sea o no sea válido.
"Sin embargo, si el usuario es válido, entonces se establece 'server_caused_failure'", dicen los investigadores en un aviso, agregando que esto no ocurre cuando se proporciona un usuario que no existe en el servidor.
Detallan que el número predeterminado de intentos para un usuario no válido está limitado a seis, luego el servidor desconecta al atacante. Si se proporciona un usuario válido, "el atacante puede intentar la autenticación GSSAPI indefinidamente". Esto deja la puerta abierta a ataques de fuerza bruta contra la contraseña.
diff -pruN openssh-7.8p1/gss-genr.c openssh-7.8p1-poc/gss-genr.c
--- openssh-7.8p1/gss-genr.c 2018-08-22 22:41:42.000000000 -0700
+++ openssh-7.8p1-poc/gss-genr.c 2018-08-22 22:41:42.000000000 -0700
@@ -286,6 +286,7 @@ ssh_gssapi_check_mechanism(Gssctxt **ctx
ssh_gssapi_build_ctx(ctx);
ssh_gssapi_set_oid(*ctx, oid);
+ return 1;
major = ssh_gssapi_import_name(*ctx, host);
if (!GSS_ERROR(major)) {
major = ssh_gssapi_init_ctx(*ctx, 0, GSS_C_NO_BUFFER, &token,
diff -pruN openssh-7.8p1/sshconnect2.c openssh-7.8p1-poc/sshconnect2.c
--- openssh-7.8p1/sshconnect2.c 2018-08-22 22:41:42.000000000 -0700
+++ openssh-7.8p1-poc/sshconnect2.c 2018-08-22 22:41:42.000000000 -0700
@@ -701,6 +701,7 @@ userauth_gssapi(Authctxt *authctxt)
ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_TOKEN, &input_gssapi_token);
ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_ERROR, &input_gssapi_error);
ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, &input_gssapi_errtok);
+ return 1;
mech++; /* Move along to next candidate */
Los desarrolladores de OpenSSH no consideran que esta vulnerabilidad sea una prioridad debido a su bajo nivel de gravedad. El razonamiento es que "es una divulgación parcial de información no confidencial".
Dicen que el error permite a "un atacante hacer conjeturas de fuerza bruta de nombres de cuentas y verificar si existen en el sistema de destino". La limitación de seis intentos reduce aún más las posibilidades de éxito.
El desarrollador de código abierto Damien Miller que trabaja en OpenSSH dice que las bibliotecas del sistema no tratan este tipo de divulgación de información como una amenaza porque los nombres de usuario se consideran la parte no secreta de la identidad del usuario, inútil para un atacante sin la contraseña correspondiente.
Un atacante sofisticado puede beneficiarse de este tipo de falla durante la etapa de reconocimiento, ayudándolos a determinar qué ataques tendrían más éxito, dice Jimmy Graham, Director de Gestión de Producto en Qualys.
"Los usuarios específicos en un sistema a menudo pueden regalar el sistema operativo o la distribución exacta, así como también los servicios que se ejecutan en el sistema, especialmente si tienen nombres de usuario predeterminados para esos servicios", dijo Graham a BleepingComputer.
Graham admite que los ataques Oracle no son una amenaza significativa, pero deben tratarse como cuestiones de seguridad, no obstante, porque exponen la información del usuario.