lunes, 3 de enero de 2011

Privilege Escalation no Interactivo

En general, la elevación de privilegios dentro de un sistema suele resultar menos complicada que obtener el acceso al sistema, ya que frecuentemente suelen publicarse vulnerabilidades en el Kernel de los diferentes sistemas operativos que permiten elevar privilegios. Un buen ejemplo de la cantidad de vulnerabilidades y exploits publicados que existen de este tipo los podemos obtener en la categoría LOCAL de la web Exploit-DB:


Sin embargo, no siempre estos exploits van a solucionar por si mismo lo que necesitamos, ya que todos ellos requieren acceso interactivo, es decir, hacer establecido algún tipo de shell, algo que en ocasiones puede que no sea posible.


En muchas ocasiones nos vamos a encontrar un algún tipo de vulnerabilidad web que nos habrá permitido ejecución de comandos, pero a través de la cual no podemos tener un acceso shell. Esto es debido a que la gran mayoría de servicios web que se ofrecen en la actualidad se encuentran balanceados mediante dispositivos que distribuyen la carga entre varios servidores, y muchas veces dichos sistemas no disponen de una conexión directa a Internet, por lo que es imposible establecer shell reversas de ningún tipo, salvo a través del propio tráfico HTTP que llega desde el balanceador (y a este desde Internet) al servidor web, y las respuestas de este.

Esto nos puede suponer un problemas a la hora de realizar elevación de privilegios, ya que muchos de los exploits de este tipo acaban ejecutando una shell interactiva con los privilegios de root o SYSTEM, y con este acceso a través de balanceador va a ser imposible interactuar con esta shell.

Por poner un ejemplo, vamos a hablar de la vulnerabilidad CVE-2009-2698 y del exploit que hay publicado, que utilicé recientemente en uno de estos casos. Se trata de una vulnerabilidad local en los Kernel de Linux de la rama 2.6 con versión inferior a la 2.6.19, que como comentábamos anteriormente, nos da un acceso a una shell interactiva con privilegios de root:


¿Y cómo se supone que vamos a ejecutar esto desde un acceso HTTP mediante el que no podemos tener un acceso interactivo? Pues la respuesta es fácil: NO podemos... tal y como está el exploit ahora mismo, así que vamos a tenerle que pegar un pequeño vistazo:


Si le pegamos un vistazo a uno de estos exploits de elevación de privilegios, es probable que nos encontremos con que acaban lanzando algún tipo de shell (sh, bash, o similar), mediante algún tipo de llamada como execl() o system().

Pero nosotros... no queremos una shell interactiva, porque nos vamos a poder interactuar con ella, pero nada nos impide cambiar esta linea para que lance algún otro tipo de comando no-interactivo que nos pueda resultar interesante. Por ejemplo, si quisiéramos que el exploit nos mostrara directamente el contenido del fichero /etc/shadow para luego poder intentar crackear las contraseñas, podríamos cambiar esa linea por la siguiente:

execl("/bin/cat", "/bin/cat", "/etc/shadow", NULL);

Ahora sí que podemos utilizar este exploit a través de HTTP para obtener la información que deseamos, pero la verdad es que es un poco... pesado tener que modificar el exploit y volverlo a compilar para cada comando que queramos lanzar, así que podemos realizar alguna modificación para que el exploit, tras elevar privilegios, lance los comandos que le hemos pasado por linea de comandos, o a través de un shellscript. En mi caso, dado que uso jsp/php/asp-shells que me permiten editar ficheros de una forma cómoda, me resultaba más cómodo hacerlo de esta segunda forma, cambiando la linea por la que sigue:

execl("/bin/sh", "/bin/sh", "root.sh", NULL);

Ahora que ya lo tenemos listo, solo tenemos que crear el fichero root.sh con la secuencia de comandos que queramos, y ejecutarlo a través de HTTP:



Ahora podemos acceder a los ficheros que queramos, crear usuarios, y todas las demás acciones que queramos realizar con permisos de root, con tan solo modificar el fichero root.sh.

Y si nos creamos un usuario... ¿Cómo podemos obtener luego una shell interactiva si el sistema comprometido se encuentra en una red aislada como es el caso? Lo vemos en el próximo post.

15 comentarios :

0xroot dijo...

Muy buena la entrada, fácil y sencilla de leer a estas horas.

Y además explicando algo que no sabía, genial :D

Un saludo

Jose Selvi dijo...

Gracias @0xroot :)

La modificación de exploits es algo que le da mucho respeto a mucha gente, y es verdad que puede llegar a ser complicado, pero hay otros casos como este en el que una pequeña modificación muy sencilla nos puede resultar muy útil.

Gracias por tu comentario!
Saludos!

Anónimo dijo...

Muy ilustrativo. Esperando con ganas el siguiente post.

Alejandro Nolla dijo...

Interesante entrada Jose, tengo una dudilla, ¿se podría modificar el exploit (o pasarlo mediante el .sh que comentas) para que hiciese un wget/escribir a un fichero un payload de meterpreter inverso por http ó https? Mi duda es si el balanceador de carga / firewall dejarían salir el tráfico aunque no exista "sesión" (no sé si me he explicado bien... sería algo así como una ACL reflexiva)

saludos

Jose Selvi dijo...

@Alejandro: No, precisamente ese es el problema, que la red donde está la granja de servidores HTTP se encuentra aislada, sin conectividad directa a Internet, así que no podemos conectar directamente, tenemos que utilizar la propia conexión HTTP que viene a través de los balanceadores y sus respuestas.

No está todo perdido, se puede establecer una shell o meterpreter de todos modos, pero con algo un poco más elaborado que veremos en el siguiente post.

Gracias por tu comentario ;)

Dade dijo...

Muy bueno,

a esperar a la continuación.

Esto mismo alguna vez yo también lo he hecho de la siguiente forma:

http://victima.com/shell.php?cmd=./exploit <<< id; whoami; cat /etc/passwd

Un saludo!

Dade dijo...

Me han faltado unas comillas, sería:

http://victima.com/shell.php?cmd=./exploit <<< "id; whoami; cat /etc/shadow"

Jose Selvi dijo...

@Dade: Puede que tu forma resulta incluso más cómoda a la hora de ejecutar los comandos, pero requerirá modificar un poco más el exploit.

Para los lectores: Lo que @Dade hace es modificar el exploit para que ejecute los comandos que se le pasan por la entrada estandar, y entonces lo llama pasándole comandos por esta entrada.

Puede ser una buena solución si nos encontramos en una situación en la que resulte engorroso editar root.sh , desde luego.

Gracias por el aporte! ;)

fossie dijo...

Buen artículo aunque reconozco que me pierdo con cosas como las que comenta Alejando Nolla ;) pero es interesante la forma de modificar el código a nuestra conveniencia ya que no todo te lo van a dar hecho. Además, así se aprende un poco sobre lo que realmente se esta haciendo ya que no todo es copy&paste.

Metasploiter dijo...

Espectacular!!!

A uno le da vergüenza después de esto crear un blog de seguridad... jejeje

Un saludo.

Jose Selvi dijo...

@Metasploiter: Para nada! Seguro que tienes cosas interesantes que aportar ;)

@fossie: Es que el término "ACL Reflexiva" que ha usado Alejandro es un poco complicado, pero básicamente lo que decía Alejandro es si no podíamos subir un payload de Metasploit como Meterpreter y lanzar un reverse shell a través de http o https que pasara a través de los Balanceadores. Y mi respuesta fue que no creo que se pueda :P

Metasploiter dijo...

PEro utilizando el PAYLOAD de reverse_http de metasploit no debería habe problema:
Copy&paste:

Description:
Tunnel communication over HTTP using IE 6, Inject the meterpreter
server DLL via the Reflective Dll Injection payload (staged)

O si?
Un saludo

Jose Selvi dijo...

@Metasploiter: Ese Stage que comentas lo que hace es inyectar una DLL en el navegador del sistema comprometido, para utilizar para salir a Internet la configuración del navegador.

Puede ser muy útil para salir de redes mediante las que solo se puede salir a través de proxy autenticado (el navegador de un usuario ya estará autenticado, en teoría), pero no sirve para el caso en el que no existe salida hacia Internet de ninguna forma. El balanceador no va a actuar como proxy de salida a Internet ni nada parecido.

Luis dijo...

Hola,

A lo mejor mi pregunta parece de principiante pero es que realmente lo soy ;-)

"http://victima.com/shell.php?cmd=./exploit" viendo esto, mi pregunta es ¿ El fichero exploit esta en el sistema local o en el servidor web remoto ?

S2.

Jose Selvi dijo...

@Luis: El exploit ya lo has conseguido subir al servidor por algún medio, y la llamada es a un fichero local a la máquina.

¿Cómo consigues subir el fichero? Eso puede que de para otro post, pero básicamente, si puedes ejecutar comandos a mi me gusta ir usando el comando echo para ir creando linea a linea el fichero (hay que modificarlo un poco, haciendo un shellscript auto-extraible, por ejemplo).

Tengo pensado escribir otro post sobre esto temas cuando saque un rato, que llevo una racha...

Gracias por el comentario!