Relaying SSH con UDP

Como ya sabéis algunos, me encuentro impartiendo en estos momentos curso del SANS Institute SEC-560: Network Penetration Testing & Ethical Hacking. Durante el transcurso de las clases, mientras veíamos la parte de pivoting, comentábamos que, en ocasiones, todos los puertos TCP pueden estar cerrados de salida, lo cual dificulta hacer el pivoting, aunque no lo imposibilita.

Como una de las posibles soluciones a esta situación está que en muchas empresas existen reglas para permitir la realización de peticiones DNS hacia Internet. Estas peticiones emplean el puerto 53/UDP, por lo que vamos a poder utilizar este puerto para realizar una conexión inversa y realizar el pivoting. En realidad, un relay de puertos mediante UDP es (muy) levemente distinto a un relay de puertos puramente TCP, como el que vimos hace ya tiempo AQUÍ (si alguien no domina este concepto, recomiendo su lectura previa a este post). Sin embargo, he visto en ocasiones gente que ha publicado herramientas específicas para hacer relay empleando puertos de salida UDP, quizá porque no se han parado a analizar profundamente la potencia que herramientas como NetCat nos ofrece:

$ nc -h

usage: nc [-46CDdhklnrtUuvz] [-b boundif] [-i interval] [-p source_port]

 [-s source_ip_address] [-w timeout] [-X proxy_version]

 [-x proxy_address[:port]] [hostname] [port[s]]

Command Summary:

-4 Use IPv4

                [...]

                -u UDP mode

                [...]

NetCat nos da la opción de usarlo en modo UDP (-u), tanto cuando lo empleamos en modo cliente como cuando lo empleamos en modo escucha. Esto nos permite una gran flexibilidad a la hora de definir conexiones. A modo de ejemplo, vamos a ver como podríamos establecer una conexión SSH a una máquina interna haciendo que el relay se estableciera mediante conexiones UDP al puerto 53:

En primer lugar, deberíamos poner en nuestro equipo "algo" a escuchar en el puerto 53/udp para recoger la conexión que nos vamos a mandar desde el equipo comprometido, y a su vez que este nos ofrezca el servicio SSH en algún puerto al que podamos conectar mediante un cliente SSH estándar. Para ello emplearemos NCat, que es la implementación que viene con la suite NMap del antiguo NetCat y que ya vimos EN ESTE POST. Como podéis ver, ponemos dos NCat's a la escucha, uno en el puerto 22/tcp y otro en el puerto 53/udp, conectados entre si. El orden en el que se llaman es importante, ya que el primero que se ejecuta debería ser el que primero vaya a recibir la conexión, en este caso el UDP.

A continuación, en la máquina comprometida, empleamos NetCat para hacer lo mismo que antes pero, esta vez, en modo cliente en lugar de a la escucha ¿Por qué usamos NetCat en lugar de NCat? Sencillamente porque NetCat está pensado para funcionar de forma standalone, mientras que NCat tiene algunas dependencias de las que podríamos no disponer en el sistema comprometido.

En este momento ya tenemos un NetCat que conecta al puerto 22/tcp de la máquina comprometida, que le pasa la información a otro NetCat que conecta a nuestro sistema al puerto 53/tcp y le pasa esta misma información al NCat que tenemos aquí a la escucha, que a su vez se lo pasa todo al NCat que hemos puesto a la escucha en nuestro puerto 22/tcp, por lo que... ¿Qué ocurrirá ahora si conectamos a nuestro puerto 22/tcp? Veamoslo:

Como podemos ver, conseguimos conectar al puerto SSH de la máquina comprometida, al que al principio no podríamos llegar, pero nos aprovechamos que la salida a través del 53/udp está permitida para cambiar de protocolo la conexión de tcp a udp, para luego en nuestro equipo deshacer este cambio y poder emplear un cliente estándar.

Es solo un pequeño ejemplo más de las cosas que se pueden hacer con NetCat/NCat. Por algo le llaman "la navaja suiza".