¡Hola a todos! Hoy publico el primero de una serie de 3 artículos en los que hablaré sobre una técnica para crear y, en cierta forma, ocultar túneles HTTP en los que encapsular cualquier tipo de tráfico. Para ello, utilizaré la herramienta Chisel y el servidor NGINX. Además, también tocaré un poco el tema Domain Fronting. Esta técnica puede ser interesante y resultar útil, por ejemplo, en escenarios de Red Team donde el entorno sea muy restrictivo con el tipo de tráfico que permite salir a Internet y HTTP sea una de las pocas opciones, o incluso la única.

En esta primera parte os voy a hablar de Chisel y de cómo utilizar esta herramienta para crear túneles HTTP.

Chisel es un herramienta escrita en Go (golang) desarrollada por Jaime Pillora <Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.> que permite crear túneles TCP encapsulados en tráfico HTTP y protegidos por una capa SSH. Esta herramienta se compila en un solo ejecutable que puede funcionar como cliente o como servidor. Entre sus características se encuentran las siguientes:

• Conexiones Cifradas: siempre que chisel se ejecuta en modo servidor, se crea un par de claves pública/privada ECDSA en memoria que se utilizan para cifrar el tráfico de las conexiones.
• Conexiones Autenticadas: de forma opcional, cuando chisel se ejecuta en modo servidor mediante parámetros, se le puede indicar un archivo json o una lista de usuarios y contraseñas que deberán ser usados por un cliente para poder establecer una conexión con el servidor.
• Múltiples endpoints: un mismo cliente puede crear múltiples túneles (o endpoints) dentro de la misma conexión TCP, es decir, si por ejemplo se quiere redirigir más de un puerto, no es necesario ejecutar un cliente para cada uno.
• Soporte para proxies: cuando chisel se ejecuta en modo cliente se pueden pasar como parámetro las credenciales para autenticarse con un proxy HTTP mediante CONNECT.
• Soporte para conexiones SOCKS5: cuando chisel se ejecuta en modo servidor mediante parámetros, se le puede indicar que permita conexiones SOCKS5
• Soporte para redirección reversa de puertos: cuando chisel se ejecuta en modo servidor mediante parámetros, se le puede indicar que permita redirecciones reversas de puertos, de esta forma un cliente chisel puede exponer puertos de la máquina local en la que se está ejecutando como puertos locales en la máquina remota donde se está ejecutando el servidor.

A continuación, se muestra un ejemplo de ejecución básica de chisel. En el ejemplo se ejecuta un servidor chisel escuchando en el puerto 80, y después, un cliente chisel que se conecta a dicho servidor y crea una redirección del puerto 2222 local al puerto 22 del servidor. Con esto se consigue que cualquier conexión que se lance al puerto local 2222 se encamine por el túnel HTTP de chisel y acabe llegando al puerto 22 remoto de la máquina en la que se está ejecutando chisel en modo servidor.

chisel server -p 8080

chisel client --fingerprint fb:0f:ae:0d http://192.168.1.142:8080 2222:localhost:22

ssh -p2222 root@127.0.0.1



Chisel también ofrece una serie de opciones de ejecución que pueden ser útiles en ciertos escenarios. Para ambos modos de ejecución, cliente y servidor, existe el típico argumento -v que hace que la aplicación muestre más información de ejecución. Esto puede ser útil tanto para tener más detalle durante la ejecución de la herramienta, como para solucionar posibles problemas que puedan surgir durante dicha ejecución.

Para el modo servidor, dos parámetros interesantes son --auth y --reverse, los cuales comentamos a continuación:

• El parámetro --auth va seguido de una lista de credenciales en formato usuario:contraseña. Cuando un cliente chisel se intente conectar al servidor, deberá autenticarse con alguna de las credenciales de dicha lista para poder establecer la conexión. Una alternativa a esto es el parámetro --autfile, al que se le debe indicar el path de un archivo JSON, el cual permite una configuración de autenticación de usuarios más detallada.
• El parámetro --reverse activa el soporte para la redirección reversa de puertos en el servidor de chisel. Esto significa que un cliente chisel puede exponer puertos de la máquina en la que se está ejecutando en puertos locales de la máquina en la que se está ejecutando el servidor de chisel.

Para el modo cliente tres parámetros interesantes son --auth, --keepalive, y --proxy, los cuales comentamos a continuación:

• El parámetro --auth en el modo cliente funciona prácticamente igual que en el modo servidor, con la diferencia de que hay que proporcionar un único par en formato usuario:contraseña, que será el que se mande al servidor chisel para que lo valide y se establezca la conexión.
• El parámetro --kepalive hace exactamente lo que dice su nombre, mandar paquetes cada cierto tiempo para que la conexión entre cliente y servidor no se cierre. Simplemente, hay que pasarle un valor en formato número+carácter indicando el intervalo (por ejemplo, 30s o 2m). Esto puede ser útil si la conexión está pasando por algún elemento que la pueda cerrar, si no detecta actividad en un cierto intervalo de tiempo, como por ejemplo NGINX.
• El parámetro --proxy sirve para indicar que la conexión que lance el cliente chisel debe pasar primero por un servidor proxy. En la actualidad, este parámetro solo admite proxies del tipo HTTP CONNECT. El formato sería: http://usuario:contraseña@nombre-dominio-o-dirección-proxy:puerto.

Al igual que ocurre con los túneles SSH, el caso de uso más común es el del túnel directo o local, es decir, el caso en el que en un puerto local se expone un puerto remoto, que puede ser tanto de la máquina contra la que se lanza la conexión, como de otra máquina remota visible desde la máquina a donde se lanza la conexión. Sin embargo, en algunas circunstancias puede ser útil hacer justo lo contrario. En el caso del túnel reverso o remoto, en un puerto local de la máquina contra la que se lanza la conexión se expone un puerto de la máquina que lanza la conexión o un puerto de una máquina visible desde la máquina que lanza la conexión.

Chisel permite ambos tipos de conexión si se indica el parámetro --reverse cuando se lanza el servidor, como se ha descrito antes. Además, chisel permite crear múltiples conexiones dentro del mismo túnel. Tan solo hay que pasar estas por parámetro, separadas por espacio cuando se lance el cliente, respetando el siguiente formato y teniendo en cuenta que las direcciones y puertos se indican desde el punto de vista de la máquina que está ejecutando el cliente de chisel: <host-local>:<puerto-local>:<host-remoto>:<puerto-remoto> pare conexiones directas y R:<host-remoto>:<puerto-remoto>:<host-local>:<puerto-local> para conexiones reversas.

Para terminar con el post, simplemente decir que esta herramienta resulta bastante útil si se está en un entorno restringido que solo permite cierto tipo de tráfico (como HTTP) de salida hacia Internet y, por la razón que sea, se necesita lanzar otro tipo de conexiones. Con chisel esto es posible debido a que, a ojos de la red, el tráfico es HTTP. No obstante, dentro de ese túnel HTTP podemos encapsular cualquier cosa, desde SSH hasta RDP. Aun así, una nota de cautela: a nivel de máquina, ciertos controles pueden detectar el binario de chisel como software malicioso; y a nivel de red, el tráfico de esta herramienta es reconocible, lo que significa que es mejor usarla con cuidado y estar detrás de 7 proxies.

Y aquí termina este primer post sobre cómo utilizar la herramienta chisel para crear túneles HTTP- En la siguiente entrada de esta serie hablaremos sobre NGINX y de cómo utilizar esta herramienta para camuflar los túneles HTTP creados con chisel. ¡Nos vemos pronto!

David Bueno

• David Bueno