reDuh: HTTP Tunneling

Hace un par de semanas hablábamos de la posibilidad de modificar un exploit de elevación de privilegios para ejecutarlo de forma no interactiva, y de esta forma poder tomar el control de una máquina.

En el anterior post, nos quedábamos en que habíamos conseguido crear un usuario con privilegios de root (uid=0) en la máquina, pero no teníamos acceso a nivel de red al puerto de SSH, por lo que no podíamos terminar de establecer una sesión interactiva.

Para ello, y dado que solo tenemos acceso a la máquina objetivo a través del servicio que acabamos de explotar, intentaremos usar este mismo servicio para crear un túnel de tráfico TCP sobre este protocolo, en este caso TCP sobre HTTP. La herramienta a utilizar va a ver reDuh, de Sensepost, que dispone de dos piezas: un servidor en versiones php, aspx y jsp que se pueden subir al servidor comprometido, y un cliente java que se lanzará desde nuestro equipo para establecer el túnel.

Una vez subido el servidor reDuh correspondiente (en este caso era php), podemos comprobar si ha sido subido correctamente simplemente con acceder a su URL. Esta pieza no está preparada para ser llamada de esta forma, así que nos da un mensaje de error, pero por lo menos nos confirma que la URL es la correcta:

Una vez subido el php (ya veremos en otra ocasión diferentes formas de hacerlo), ya solo tenemos que llamar al cliente de reDuh señalándole esta URL, de la siguiente forma:

# java -jar reDuhClient.jar http://172.16.146.134/reDuh.php

Tras establecerse esta conexión, reDuh levanta una consola de administración en nuestra máquina local, en el puerto 1010, a la que podemos acceder vía telnet para configurar los túneles que queremos utilizar. Para este caso, que simplemente queremos acceder al SSH local, nos bastará con algo así:

>> [createTunnel]2222:127.0.0.1:22

En este momento ya tenemos un túnel entre nuestro puerto 2222 y el puerto 22 de la máquina comprometida, así que solo tenemos que conectar nuestro cliente de SSH favorito a nuestro puerto local 2222 y todo ese tráfico va a ser encapsulado a través de protocolo HTTP hasta el servicio web que acabamos de explotar, y de ahí, ya otra vez como tráfico TCP "puro", hasta el puerto 22 local de esa máquina. Podemos verlo en un gráfico que me he permitido tomar prestado de la web de Sensepost:

Muy bonito, pero... ¿funciona?

Vamos a ver si podemos conectar mediante este puerto 2222 local al SSH de la máquina comprometida y entrar con las credenciales de usuario que nos creamos en el post anterior:

¡Perfecto! Parece que estamos dentro :)

Ahora ya podemos "jugar" todo lo que queramos con la máquina, con una sesión totalmente interactiva, por supuesto.

Gracias a Sensepost por esta fantástica herramienta.

SANS Event: Community night of presentations and cutting edge infosec topics

El próximo día 25 de Enero tendrá lugar en Madrid un evento organizado por el SANS Institute con el objetivo de presentar los cursos que van a impartirse en España a lo largo del 2011.

El evento se ha titulado Community Night of Presentations and Cutting Edge Infosec Topics, y a parte de la presentación de estos cursos, podremos asistir a un par de charlas sobre seguridad técnica, impartidas por Raúl Siles (Taddong) y yo mismo (S21sec).

El programa de las charlas será el siguiente:

18:00 - 18:15: Introducción. Marlene Sanchez y Rafael Ausejo (VASS).

18:15 - 19:45: Browser Exploitation for Fun and Profit Redux. Raúl Siles (Taddong)

19:45 - 20:30: IP Fragmentation Overlapping v2.0. Jose Selvi (S21sec)

20:30 - 21:00: Preguntas.

Yo por mi parte, hablaré de las técnicas de "IP Fragmentation Overlapping" como ya hice en otra ocasión en Barcelona, pero esta vez además de explicar la técnica y mostrar como utilizarla y protegerse de ella, veremos también el ataque desde el punto de vista de la respuesta ante incidentes: Una vez producido el ataque sin que hagamos podido aplicar las defensas adecuadas ¿Cómo actuaríamos? ¿Cómo descubriríamos que nos ha hecho el atacante?

Ven el próximo día 25 al evento y lo descubrirás.

Para más información sobre el evento pulsad y registro pulsa AQUÍ, mientras que si lo queréis es ver el catálogo de cursos que va a ofertar SANS en España a lo largo de 2011, pulsa AQUÍ.

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.