Cuando se habla de movimientos laterales es muy habitual mencionar servidores proxy o túneles que se encarguen de enrutar el tráfico de una máquina a otra. Normalmente la máquina que “enruta” es aquella que el atacante ha podido comprometer y utiliza como pivote para atacar otras máquinas que se encuentran disponibles en la red local de la víctima. Este es el escenario más habitual y conocido, además también es común utilizar herramientas como SSH (para crear túneles), Socat para crear redirectores o las características de networking que ya vienen incluidas en Meterpreter. No obstante como suelo decir, es importante conocer otras herramientas, alternativas y técnicas que se sumen a las ya aprendidas. El motivo es muy simple: No dependencia. Por ejemplo, SSH es estupendo para crear túneles cifrados utilizando dicho protocolo, lo que en una operación de Red Team es genial pero no siempre se contará con la suerte de poder utilizar SSH y crear túneles locales, remotos o dinámicos ya sea porque no se encuentra instalado (y por lo que sea no puede llevar a cabo el proceso de instalación en ese sistema) o porque no se tiene una cuenta valida en el sistema ni privilegios para crear un usuario nuevo. Hay que buscar otras alternativas. Por ese motivo, en este post se hablará de 2 herramientas que son estupendas y encajan perfectamente en una campaña de Red Team, concretamente en la etapa de pivoting y movimientos laterales, se trata de SSLH y Chisel.

Sobre esta herramienta he escrito algo hace varios años pero su uso y filosofía siguen siendo ideales para realizar movimientos laterales en campañas de Red Team. A grandes rasgos, permite recibir peticiones en un puerto concreto utilizando protocolos tan conocidos como HTTPS (TLS/SSL), OpenVPN o SSH y posteriormente, enrutar internamente dicha petición con su información a otro puerto distinto. Básicamente, funciona como un multiplexor en el que utilizando el mismo puerto se pueden servir dos servicios distintos (o más) en función a la petición realizada. Un ejemplo podría ser levantar el servicio HTTPS por el puerto 443, SSH por el 22 y todas las peticiones entrantes por el puerto 4444 (por poner un ejemplo) pueden ser procesadas por el servidor web en el caso de que se trate de una petición HTTPS o por SSH si la petición utiliza ese protocolo.
El proyecto se encuentra en GitHub (https://github.com/yrutschle/sslh) y la documentación en el sitio web de su creador (https://www.rutschle.net/tech/sslh/README.html) en donde están descritas las instrucciones para su instalación. El programa también está disponible para sistemas basados en Debian y RedHat en sus repositorios oficiales, por lo tanto se puede instalar fácilmente con instrucciones como “apt install sslh” o “yum install sslh”. No obstante es posible que resulte conveniente generar el ejecutable realizando el proceso de construcción manual con “make” para poder transferir el binario a la máquina comprometida. En las últimas versiones de esta aplicación hay dos ejecutables que hacen lo mismo (sslh-fork y sslh-select), pero que tal como se indica en la documentación, se debe usar uno u otro en función al número de peticiones concurrentes que se pretenda realizar. En el caso de sslh-fork tal como su nombre indica y se puede ver en el fichero sslh-fork.c, se invoca a la función “fork()” para cada petición entrante, lo que a la larga puede generar un consumo excesivo de recursos en el servidor y por lo tanto no es el mejor enfoque si se pretende realizar múltiples conexiones. La otra alternativa es sslh-select la cual en lugar de hacer un “fork” del proceso principal, levanta un nuevo hilo con la función “select”, algo que también se puede apreciar en el fichero sslh-select.c. Conociendo estos detalles es posible elegir alguna de las dos con prudencia y teniendo muy en cuenta el uso que se le pretende dar, así como las características del sistema comprometido.
Utilizarlo no representa ninguna dificultad ya que las opciones son muy intuitivas y entendido el funcionamiento de la herramienta es fácil levantar un multiplexor/redirector con SSLH, tal como se puede comprobar en la siguiente imagen.

Como se puede ver se ha utilizado el mismo puerto (4443) para acceder a dos servicios diferentes, uno por SSH y otro por HTTPS. La herramienta se encarga de enviar la petición correspondiente al servicio correcto y la conexión se establece en el caso de que, por supuesto, en el destino el servicio se encuentre levantado.

Se trata de una herramienta que funciona bastante bien a la hora de enmascarar peticiones HTTP hacia un servidor cifrando los datos con SSH. Tal como se indica en el repositorio GitHub del proyecto (https://github.com/jpillora/chisel) su principal objetivo es el de evadir restricciones impuestas por Firewalls.
Se encuentra desarrollado en Go y se puede instalar muy fácilmente utilizando las siguientes instrucciones, las cuales generarán el binario de Chisel para levantar los componentes cliente y servidor.

A continuación, el binario generado se debe ubicar en la máquina del atacante (servidor) y transferir a la víctima (cliente). Una vez hecho esto, se empezara a crear diversos tipos de túneles y combinaciones interesantes. Un primer ejemplo podría verse en la siguiente imagen:

En la primera consola se ejecuta el servidor, es decir, en la máquina del atacante. Como se puede apreciar se especifica el puerto 9000 y en las trazas que genera el programa se puede ver que en dicho puerto se vincula a todas las interfaces de red disponibles en el servidor.

En la segunda terminal, es decir, en la máquina de la víctima se ejecuta Chisel con el argumento “client” y se especifica la ubicación del servidor que en este caso concreto es la IP “192.168.1.116” y el puerto, debe ser el 9000 (el indicado en la máquina donde se ejecuta el servidor). La siguiente parte del comando permite especificar la sintaxis del túnel. En este caso concreto, se especifica que se abrirá el puerto 9001 en la máquina de la víctima (cliente) y que todas las peticiones entrantes por dicho puerto (9001), serán enviadas al servidor en el puerto 9000 y éste, se encargará de hacer la redirección correspondiente a http://www.startpage.com:443.

Finalmente, en la tercera terminal se realiza la prueba utilizando CURL, en donde se puede comprobar claramente que la IP de la víctima (192.168.1.76) responde correctamente a las peticiones por el puerto 9001 y de forma transparente de puede apreciar en las cabeceras de la respuesta que proviene del servidor StartPage.com. Lo que ha ocurrido al ejecutar la petición contra el puerto 9001 es que la víctima (cliente) se ha puesto en contacto con el atacante (servidor) para que sea éste el que realice la petición al dominio solicitado (www.startpage.com:443).

Con este ejemplo se puede ver el potencial de la herramienta y que puede resultar muy conveniente como una alternativa a la creación de túneles SSH para pivotar o exfiltrar información. Sin embargo, aquí no termina ya que Chisel cuenta con más opciones y combinaciones. Otro ejemplo se puede ver en la siguiente imagen.

Este sería el caso más habitual a la hora de realizar pivoting y port-forwarding con Chisel. En este escenario el atacante ha comprometido una máquina y quiere enrutar todas las peticiones hacia un objetivo que se encuentra ubicado en una red interna, dicha red es accesible desde la máquina de la víctima pero no lo es desde la máquina del atacante. A continuación se explica cómo se ha utilizado Chisel en este caso.

En la primera consola se ejecuta Chisel en la máquina del atacante (servidor) y se abre el puerto 9000, además notar que se utiliza la opción “-reverse” la cual permite crear un túnel reverso entre la víctima y el servidor, un término conocido para aquellos que saben lo que es un túnel SSH remoto.

En la segunda consola se utiliza Chisel en la máquina víctima (cliente) y se indica que debe establecerse una conexión contra el puerto 9000 del atacante (servidor).  La siguiente parte del comando sirve para especificar la creación del túnel. En este caso es uno remoto “R”, se abrirá en la máquina del atacante (servidor) el puerto 8000 y luego, todas las peticiones que se reciban en dicho puerto en la máquina del atacante serán enrutadas automáticamente a una IP y puerto que se encuentra en un segmento de red al que tiene acceso la víctima, en el caso de la imagen anterior el segmento es el 192.168.1.0/24 la IP concretamente es la 192.168.1.115 y el puerto es el 80.

Como se ha mencionado antes, cuantas más alternativas, herramientas y técnicas se conozcan para llevar a cabo cada una de las etapas de una campaña de Red Team o un Pentest mucho mejor, así si falla alguna o no se puede aplicar por el motivo que sea se cuenta con otras alternativas que pueden “salvar el día”.

Un saludo y Happy Hack!
Adastra.