Ligolo-ng, pivoting avanzado de la mano de Go

Ligolo-ng, pivoting avanzado de la mano de Go



Muy buenas, durante esta entrega hablaremos de una herramienta que facilita mucho la temática de los túneles. ¡No os perdáis en él! .

Ligolo-ng es una herramienta simple, ligera y rápida que permite a los pentester establecer túneles desde una conexión TCP/TLS inversa utilizando una interfaz virtual “tun” (sin necesidad de SOCKS). A diferencia de Chisel u otras herramientas, con Ligolo-ng no necesitamos hacer uso de SOCKS, si no que mediante interfaces virtuales levantaremos un túnel (al más puro estilo VPN).

Gracias a esto, podremos correr herramientas como Nmap sin tener que usar proxychains, por lo que las tareas de pivoting se vuelven más sencillas y rápidas, ya que una de las ventajas de Ligolo-ng es una significativa mejora en el rendimiento de las conexiones frente al uso de SOCKS. Tendremos conexiones más rápidas y estables. 

A continuación, os detallamos cómo usar esta herramienta correctamente:

Get-ready

Agent – Máquina víctima

Proxy – Máquina atacante

En primer lugar, descargaremos en nuestro directorio de trabajo los binarios que vamos a necesitar. Os dejamos el repositorio oficial de Ligolo-ng:  .
 
Tenemos la posibilidad de descargar el código fuente o el binario ya compilado, por comodidad en este caso, descargaremos tanto el binario del agente como el del proxy en función de los sistemas operativos que vayamos a emplear (en nuestro caso Linux):

En el caso de optar por descargar el código fuente (GO), usaremos los siguientes comandos para compilarlo:

Linux:


Windows: 


Configurar Ligolo-ng:

Ligolo-ng se basa en una interfaz virtual a través de la cual se establecerá un túnel entre la máquina víctima y la atacante, es por ello por lo que será necesario levantar primeramente la interfaz “tun” sobre la que se apoya Ligolo-ng:



Consultamos las opciones que nos ofrece el proxy:




En donde se nos presenta las distintas opciones de certificados TLS que disponemos:

  • Autocert: El proxy automáticamente solicitará un certificado usando Lets encrypt. Esta opción requiere accesibilidad al puerto 80. 
  • Certfile / -keyfile: Si queremos usar nuestros propios certificados.
  • Selfcert: Generara automáticamente un certificado autofirmado. Esta opción es la menos recomendada en términos de seguridad, pero si estamos trabajando en un laboratorio aislado o en un entorno de pruebas, es una opción válida.
  • Tun <nombre interfaz>: En el caso de haber escogido otro nombre para la interfaz.
  • Laddr <IP:port>:  La interfaz de escucha por defecto 0.0.0.0:11601, para definir otra interfaz lo indicaremos mediante este comando.
Lanzamos el proxy con la configuración por defecto, valiéndonos de certificados autofirmados para el cifrado de la conexión

En la máquina atacante:


En la máquina víctima:


Ya tendríamos la sesión creada:


Ahora seleccionamos en el proxy (maquina atacante) la sesión que acabamos de crear:


Siempre tendremos que indicar sobre que sesión queremos trabajar. Una vez levantada la sesión podemos llevar a cabo diferentes acciones:


Desde el propio proxy podremos consultar las interfaces de red que hay levantadas en el agente (víctima) mediante el comando ifconfig:


Para poder llegar a esta nueva red (192.168.1.0/24) tendremos que indicar a nuestra máquina atacante que redirija el tráfico con destino 192.168.1.0/24 a través del túnel Ligolo que acabamos de crear. Para ello añadimos la siguiente ruta estática a la tabla de routing de la máquina atacante: 


Y por último iniciamos el túnel: 



Os muestro en el siguiente diagrama lo realizado hasta aquí:


Y ahora pasamos a comprobar que llegamos a la nueva subred (192.168.1.0/24) a través de la interfaz eth1 de la víctima:


Enlace puente

Los agentes permiten escuchar en puertos prestablecidos, de tal forma que todo el tráfico entrante hacia esos puertos sea redirigido directamente a la máquina atacante. 

Desde el proxy (atacante) y sobre la misma sesión que teníamos establecida, levantamos un listener en el agente (víctima): 



Cualquier tráfico entrante en la máquina víctima con destino el puerto 1234, será redirigido a la máquina atacante al puerto 4321. Esto es muy útil cuando tenemos que ejecutar un reverse payload hacia la máquina atacante o descargar ficheros en la víctima desde un servidor HTTP alojado en la máquina atacante. 



Avanzamos quedando así, un ejemplo de una reverse shell seria este:


Podemos gestionar cada uno de los listener levantados mediante listener_list y listener_stop/start.


Pivotando entre varias máquinas

Si queremos pivotar entre varias máquinas, podemos crear tantas sesiones como queramos apoyándonos de los listener, de tal forma que en cada máquina haya un listener escuchado en un puerto establecido que nos redirija a la máquina anterior de salto y así sucesivamente, hasta llegar al puerto 11601 (por defecto) de la máquina atacante en donde proxy-ligolo está escuchando peticiones de nuevos agentes (víctimas).

Ejemplo: desde la red 192.168.1.0/24 (donde se encuentra la máquina de salto) levantamos el agente (víctima 2) hacia el listener de la máquina intermedia (víctima 1) que nos redirigirá directamente al proxy-ligolo (atacante).

1. Configuramos el listener en la máquina de salto (192.168.1.147) desde la máquina atacante:


2. En la nueva máquina víctima lanzamos el agente (víctima 2) hacia el listener de la máquina de salto intermedia (192.168.1.147:11601):


3. La conexión será redirigida al proxy-ligolo. Se establece una nueva sesión que permitirá a acceder a nuevas subredes:


Concluyendo con esta práctica hemos realizado este ejercicio:

¡Hasta aquí hemos llegado! ¡Esperamos que haya sido de interés y utilidad para todos!
¡¡¡A volar, perdón, a pivotar!!!! 

Alejandro Auñón, Offensive Security Senior Analyst at Zerolynx.
Regresar al blog

Deja un comentario

Ten en cuenta que los comentarios deben aprobarse antes de que se publiquen.