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:

http://www.exploit-db.com/local/

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.