Usan un zero-day de Solaris para atacar redes corporativas

Desde hace algún tiempo se viene observando un grupo bautizado por Mandiant como UNC1945 que utiliza una serie de herramientas y técnicas contra sistemas Windows, Linux y muy reseñablemente contra sistemas Solaris. Para los que no habéis tenido la oportunidad de tocar este sistema Unix ex-de Sun Microsystems he de deciros que era cosa fina a lomos de un Sparc dentro de una Enteprise 450 o hasta de una Ultra 5/10... pero esas son historias de un admin-cebolleta de hace más de 15 años... 

Para dar un poquito más de contexto decir que el código fuente de Solaris se liberó en 2005 convirtiéndose en OpenSolaris hasta el año 2010 en el que Oracle compró Sun y decidió que dejara de ser "open". La última versión estable, la 11.4, data de 2018 es decir de hace más de 2 años. Aún así mantiene soporte y sigue habiendo todavía muchos servidores Solaris en circulación (incluso versiones obsoletas) y actores como UNC1945 lo consideran interesante de explotar pues pueden suponer un target importante de cara a infiltrarse en muchas redes corporativas.


Curiosamente, en abril de 2020, encontrábamos en el black market por $3000 USD un exploit con la descripción "Oracle Solaris SSHD Remote Root Exploit" llamado EVILSUN y, oh casualidad, a mediados de 2020 se descubrió en un servidor Solaris 9 una herramienta de UNC1945 que contenía un 0-day bautizado con el CVE-2020-14871 que explotaba una vulnerabilidad recientemente parcheada en el módulo PAM (Pluggable Authentication Module).

PAM permite que una aplicación Solaris autentique a los usuarios al tiempo que permite que el administrador del sistema configurar en un único sitio los parámetros de autenticación (por ejemplo, la complejidad y la caducidad de la contraseña). La vulnerabilidad real es un desbordamiento de búfer clásico basado en pila ubicado en la función parse_user_name:

static int
parse_user_name(char *user_input, char **ret_username)
{
            register char *ptr;
            register int index = 0;
            char username[PAM_MAX_RESP_SIZE];
       /* ... */

            ptr = user_input;
       /* ... */
             /*
             * username will be the first string we get from user_input
             * - we skip leading whitespaces and ignore trailing whitespaces
             */
            while (*ptr != '\0') {
                  if ((*ptr == ' ') || (*ptr == '\t'))
                               break;
                  else {
                               username[index] = *ptr;
                               index++;
                               ptr++;
                  }
            }
             /* ret_username will be freed in pam_get_user(). */
            if ((*ret_username = malloc(index + 1)) == NULL)
                  return (PAM_BUF_ERR);
            (void) strcpy(*ret_username, username);
            return (PAM_SUCCESS);
}


La vulnerabilidad surge siempre que un nombre de usuario de más tamaño que PAM_MAX_RESP_SIZE (512 bytes) se pasa a parse_user_name. De hecho, es probable que la vulnerabilidad haya existido durante décadas y que haya estado "latente" tanto tiempo porque solo es explotable si una aplicación no limita los nombres de usuario a una longitud menor antes de pasarlos a PAM, como puede ocurrir con un demonio SSH.

La autenticación Keyboard-Interactive es un mecanismo de autenticación de "passthrough" en el que el protocolo SSH transmite mensajes y respuestas entre las librerías PAM del servidor y el cliente. Fue diseñado para admitir formas personalizadas de autenticación, como de doble factor, sin modificar el protocolo SSH. Al manipular la configuración del cliente SSH para forzar la autenticación de Keyboard-Interactive para solicitar el nombre de usuario en lugar de enviarlo por los medios normales, un atacante también puede pasar una entrada ilimitada a la función parse_user_name de PAM.

Exploit PoC

Con el fin de probar rápidamente diferentes versiones de Solaris y ver si pueden ser vulnerables, la gente de Mandiant desarrolló un exploit de prueba para provocar el desbordamiento y bloquear el servidor SSH. El cliente estándar de OpenSSH ofrece todas las opciones necesarias para activar la vulnerabilidad:


Para ver si el servidor es vulnerable basta con recibir un "Authentication failed" (si no lo fuera se nos volvería a pedir el usuario). El desbordamiento en la librería PAM también hace que el servidor SSH crashee:

El sistema operativo escribe un dump por el crash en /core si el servidor SSH falla sin un debugger attacheado. De hecho, si existe un archivo /core en una máquina Solaris y vemos que se trata de sshd, esos son indicadores claros de que e ha explotado previamente esta vulnerabilidad.

Sistemas operativos vulnerables

  • Solaris 9 (algunas versiones)
  • Solaris 10 (todas las versiones)
  • Solaris 11.0
    • Si bien la función parse_user_name sigue siendo vulnerable en Solaris 11.1 sin parches y posteriores algunos cambios no documentados en la librería PAM truncan el nombre de usuario antes de que la función vulnerable lo reciba, lo que hace que el fallo no sea explotable a través de SSH. Si la función parse_user_name fuera accesible en otro contexto, entonces la vulnerabilidad podría volverse explotable.
  • Illumos (OpenIndiana 2020.04)

Mitigaciones y workarounds

Podemos encontrar un parche de Oracle para Solaris 10 y 11 entre las actualizaciones de octubre de 2020.
Debido a que Solaris 9 ya no está soportado Oracle ya no se ha publicado un parche. Para los sistemas Solaris 9, así como Solaris 10 u 11 donde la aplicación de parches es inconveniente, se recomienda editar el archivo /etc/ssh/ shd_config para agregar las líneas ChallengeResponseAuthentication no y KbdInteractiveAuthentication no y reiniciar el servidor SSH. Si bien esto elimina la posibilidad de aprovechar la vulnerabilidad mediante la autenticación Keyboard-Interactive SSH, puede haber otras formas de atacar la función parse_user_name y recomendamos usar esta solución solo como una solución provisional hasta que se puedan actualizar los sistemas Solaris 9 o se pueda actualizar el parche de octubre.

Fuentes: 

Comentarios

Publicar un comentario