Minipivoting by Jeshua Masté
Para comenzar, desplegamos nuestro laboratorio, aquí nos encontramos con varios segmentos de red. El objetivo
principal es comprometer el sistema ubicado en la dirección IP [Link], partiendo desde la máquina con IP
[Link] (nuestra máquina atacante).
Como primer paso, realizamos un ping a todas las direcciones disponibles para identificar con cuáles tenemos
conectividad.
La única dirección que respondió fue [Link], lo que indica que, por ahora, solo tenemos conexión con ese host.
A continuación, realizamos un reconocimiento activo sobre la dirección IP [Link] utilizando la herramienta Nmap,
con el fin de identificar los servicios y puertos abiertos que puedan ser aprovechados para avanzar en la intrusión.
Durante el escaneo con Nmap, identificamos dos servicios expuestos en la IP [Link]:
SSH en el puerto 22
HTTP en el puerto 80
Procedemos a realizar fuzzing sobre el servicio HTTP para descubrir directorios y archivos ocultos. Utilizamos la
herramienta Gobuster con el siguiente comando:
gobuster dir -u [Link] -w /usr/share/wordlists/dirbuster/[Link] -x php,txt,html
El escaneo con Gobuster reveló un directorio interesante llamado /shop .
Al explorar este recurso, notamos un mensaje peculiar en la página que dice:
"Error de Sistema: ($_GET['archivo'])"
Realizamos un nuevo escaneo de directorios, esta vez enfocado en la ruta /shop , utilizando nuevamente Gobuster
Encontramos [Link]. Volviendo al código que nos apareció, el código ($_GET['archivo']") podemos interpretarlo
como decirle a PHP:
“Oye PHP, incluye (carga y ejecuta) el archivo cuyo nombre me pases por la URL, sin preguntar ni validar
nada.”
$_GET['archivo'] permite controlar qué archivo se incluye y ejecuta en el servidor a través de la URL.
Puedo incluir el archivo /passwd a través de un path traversal para subir carpetas (con ../ ) y llegar a archivos fuera
de la carpeta web, como /etc/passwd .
Pero.. ¿Cómo llegamos a passwd?
Partimos desde:
/var/www/html/shop/[Link]
Queremos llegar a:
/etc/passwd
Podemos usar ../
¿Qué hace cada ../ ?
Cada ../ significa subir un nivel en la estructura de carpetas (ir al directorio padre).
Vamos a ver cada paso:
Paso Ruta actual Acción Nueva ruta
0 /var/www/html/shop Punto de partida /var/www/html/shop
1 /var/www/html/shop ../ subir 1 /var/www/html
2 /var/www/html ../ subir 2 /var/www
3 /var/www ../ subir 3 /var
4 /var ../ subir 4 / (raíz del sistema)
Después de esos 4 subes, llegas a la raíz / .
Desde ahí bajas a:
/etc/passwd
En resumen, hacemos esto:
../../../../etc/passwd
¿Qué significa cada parte?
1. [Link]
→ Es la dirección base del servidor y la carpeta donde está el código PHP.
2. ?
→ Es el separador entre la URL base y los parámetros que le pasas al servidor.
3. archivo=../../../../etc/suddoers
→ Es un parámetro llamado archivo con el valor ../../../../etc/suddoers .
Podemos decir que este servidor es vulnerable a LFI: Se incluye archivos locales, puede mostrar contenido o ejecutar
PHP local, pero limitado a lo que hay en el servidor.
A diferencia de RCE que ejecuta código malicioso arbitrario, generalmente más grave y permite control total.
Sobre /etc/passwd
Es un archivo de texto que contiene información sobre los usuarios del sistema.
No es una carpeta, es un solo archivo.
Por eso PHP puede incluirlo (aunque solo se lea el contenido, no se ejecute).
En cambio, si intentas incluir un directorio, te dará error.
En este sentido, obtenemos:
A partir de la información recopilada, identificamos dos posibles usuarios: seller y manchi.
Dado que el puerto 22 (SSH) está abierto, decidimos realizar un ataque de fuerza bruta (brute force) para intentar
acceder con estas credenciales.
Probamos primero con el usuario seller, pero no tuvimos éxito.
Sin embargo, al intentar con manchi, logramos acceder satisfactoriamente al sistema a través de SSH.
Entramos por SSH:
Fuerza bruta para hallar contraseñas de usuarios en linux
Con acceso a la máquina mediante el usuario manchi, nuestro siguiente objetivo fue obtener la contraseña del usuario
seller.
Para ello, utilizamos un script encontrado en un repositorio de GitHub, el cual permite realizar ataques de fuerza
bruta contra usuarios SSH utilizando un diccionario de contraseñas.
Copiamos el diccionario [Link] a la máquina comprometida a través de wget
Se abre un mini servidor por python desde la maquina atacante:
Script en SSH que se usó para hacer fuerza bruta
Resultado: La contraseña del usuario seller es qwerty
Escalada de privilegios
Usamos comando sudo parámetro -l para saber si tenemos algún privilegio de root.
Descubrimos que podemos ejecutar el comando php como root sin contraseña. Buscamos algún algún binario en
GTFOBINS que nos pueda ayudar
Lo adaptamos a nuestro contexto, y ahora somo usuario root:
Pivoting
Una vez comprometida la primera máquina, comenzamos a trabajar en el pivoting para avanzar dentro de la red.
Como primer paso, ejecutamos el comando hostname para identificar en qué red o redes estamos conectados desde
esa máquina.
Al no contar con Nmap en la máquina comprometida para descubrir otros hosts en la red, decidimos crear una
herramienta sencilla en Bash que nos permita realizar un escaneo básico y detectar qué IPs están activas.
Gracias a esta script, pudimos descubrir un dispositivo activo en la red con la dirección IP [Link].
Desde Parrot (nuestra máquina atacante con IP [Link]), donde ya habíamos descargado previamente Chisel y
Socat, transferimos Chisel a la primera máquina comprometida.
Para ello, iniciamos un servidor HTTP con Python en Parrot y usamos wget desde la máquina comprometida para
descargar la herramienta.
Parrot:
Máquina comprometida:
Entonces abrimos un cliente-servidor usando chisel:
Parrot:
Máquina comprometida:
En la máquina Parrot, modificamos el archivo de configuración de ProxyChains ubicado en /etc/[Link]
para enrutar el tráfico a través del túnel que estableceremos con Chisel.
Al final del archivo, añadimos la siguiente línea para definir un proxy local:
socks5 [Link] 1080
Esto indica que el túnel estará disponible a través de localhost en el puerto 1080.
Además, descomentamos la directiva dynamic_chain y comentamos strict_chain para permitir una mayor
flexibilidad en el uso de proxies y evitar posibles errores de conexión durante el pivoting
]
Durante la configuración, me encontré con algunos inconvenientes:
Fue necesario habilitar el servicio Tor, a pesar de estar utilizando un túnel con Chisel y no directamente la red
Tor. Esto posiblemente esté relacionado con cómo ProxyChains maneja conexiones SOCKS5 si no detecta un
servicio activo.
También me aseguré de que los puertos utilizados por Chisel estuvieran permitidos por el firewall (UFW), ya
que inicialmente estaban bloqueados, impidiendo la creación del túnel.
Una vez solucionado esto, realizamos un escaneo de red utilizando Nmap a través del túnel, anteponiendo la palabra
proxychains al comando para forzar el uso del proxy configurado:
El resultado del escaneo reveló que los puertos 80 (HTTP) y 22 (SSH) estaban abiertos en el host [Link].
Para visualizar el servidor web expuesto en la IP [Link] desde un navegador, es necesario enrutar el tráfico a
través del túnel SOCKS5 previamente configurado con Chisel.
En este caso, utilicé una extensión de proxy en Firefox que permite configurar una conexión SOCKS5 apuntando a
[Link] en el puerto 1080 .
Esto permitió acceder al servidor web remoto como si estuviéramos conectados directamente a la red interna.
Resultado:
Continuamos con el reconocimiento del servidor web realizando un nuevo descubrimiento de directorios con
Gobuster, esta vez a través del túnel SOCKS5.
Para ello, utilizamos el parámetro --proxy para indicarle a Gobuster que enrute el tráfico a través del proxy local
configurado:
Como resultado, descubrimos un archivo interesante en el servidor: /[Link] .
A partir de la información encontrada en /[Link] , inferimos que mario podría ser un usuario válido con acceso
SSH en el host [Link].
Para comprobarlo, realizamos un ataque de fuerza bruta utilizando Hydra, en combinación con ProxyChains para
enrutar el tráfico a través del túnel SOCKS5.
El comando utilizado fue:
sudo proxychains hydra -l mario ssh://[Link] -P /usr/share/wordlists/[Link] -VV
Tras ejecutar el ataque de fuerza bruta, logramos identificar las credenciales válidas para acceder vía SSH:
Usuario: mario
Contraseña: chocolate
Con estas credenciales, accedimos exitosamente al sistema [Link] mediante SSH.
Una vez dentro, nuestro siguiente objetivo fue escalar privilegios. Para ello, nos apoyamos en el repositorio
GTFOBins, el cual recopila técnicas de escalamiento utilizando binarios comunes presentes en sistemas Unix.
Con acceso privilegiado en la máquina comprometida, nuestro siguiente paso fue identificar a qué otras direcciones IP
tenía alcance dentro de la red interna.
Como no contábamos con herramientas avanzadas como Nmap, optamos por crear un script en Bash que nos
permitiera realizar un escaneo básico de red y descubrir nuevos hosts activos.
Gracias al script de escaneo, descubrimos una nueva dirección IP activa en la red: [Link].
Para continuar con el pivoting hacia esta nueva máquina, desde la máquina con IP [Link], transferimos
nuevamente Chisel utilizando wget , esta vez hacia la máquina con IP [Link]
Desde la máquina con IP [Link] no tenemos acceso directo a la IP [Link]. Sin embargo, sí existe
comunicación entre [Link] y [Link], así como entre [Link] y [Link]. Aprovechando esta ruta
intermedia, decidimos utilizar la herramienta Socat, ya que nos permite redirigir conexiones de una red a otra a través
de máquinas puente.
La idea es que desde la máquina [Link], se establezca una conexión con Chisel apuntando a la IP [Link].
Luego, en [Link], utilizamos Socat para redirigir esa conexión hacia [Link]*, una máquina que controlamos
directamente. De esta manera, el túnel que se inicia en [Link]** logra alcanzarnos, aunque no haya
conectividad directa.
Para lograrlo, primero transferimos Socat desde nuestra máquina atacante a [Link], ya que esta tiene visibilidad
hacia [Link]. Luego, desde [Link], transferimos Chisel hacia [Link], aprovechando la conexión intermedia
disponible.
Aunque esta configuración puede parecer confusa, el objetivo es claro: establecer un túnel desde [Link] hacia
[Link], donde Socat lo redirige finalmente hacia nuestra red de origen ([Link]). Así conseguimos acceso
completo al segmento donde se encuentra la IP [Link], permitiéndonos continuar con tareas de reconocimiento o
explotación desde nuestra máquina atacante.
En la máquina con IP [Link] configuraremos Socat para redirigir todas las conexiones entrantes hacia la IP
[Link], que corresponde a nuestra máquina atacante.
Esta configuración convierte a la máquina [Link] en un intermediario o puente que canaliza el tráfico recibido hacia
nuestro equipo, permitiendo así que las conexiones iniciadas desde otros segmentos de la red lleguen a nosotros a
través de este salto intermedio.
De esta forma, facilitamos el acceso y la comunicación entre redes aisladas, haciendo posible el pivoting hacia la
máquina atacante desde distintas partes de la infraestructura comprometida.
Desde la máquina con IP [Link] recibimos la conexión que proviene de la [Link], a la cual originalmente no
teníamos acceso directo.
Gracias a la redirección configurada en [Link] mediante Socat y al túnel establecido con Chisel, logramos superar
las restricciones de red y comunicarnos con ese segmento previamente inaccesible.
Aquí podemos ver una representación gráfica que ilustra de manera más clara y visual el flujo de conexiones y la
topología de red involucrada.
Con la conexión establecida, modificamos el archivo [Link] para cambiar el puerto del proxy a 1111, que
es el que estamos utilizando actualmente.
Luego, realizamos un escaneo con Nmap a través de este proxy y detectamos que el puerto 80 se encuentra abierto en
el host objetivo.
Configuramos un proxy en el navegador para poder acceder y visualizar el servidor web de manera remota.
Y finalmente, pudimos visualizar:
En la máquina con IP [Link] configuramos Socat para redirigir todas las conexiones entrantes por el puerto 9001
hacia nuestra máquina atacante ([Link]) por el mismo puerto. Esto garantiza que cuando enviemos una reverse
shell desde la [Link], la conexión pase primero por la máquina intermedia y luego nos llegue a nosotros.
Es importante mencionar que mantenemos abiertas las sesiones de Socat y Chisel establecidas previamente para
asegurar la continuidad del túnel y la redirección del tráfico.
A continuación, generamos la reverse shell utilizando Reverse Shell Generator, configurando la IP destino como
[Link] (la máquina desde la cual tenemos acceso a nuestro objetivo final, [Link]) y el puerto 9001 que
acabamos de redirigir con Socat.
La reverse shell será ejecutada en la máquina [Link] (que también responde a la IP [Link]). Desde ahí,
usaremos Socat para reenviar la conexión entrante hacia la máquina [Link] a través del puerto 9001.
La conexión recibida en la máquina [Link] será reenviada nuevamente hacia la máquina atacante con IP
[Link], utilizando Socat por el puerto 9001.
Desde la máquina atacante [Link], nos ponemos a la escucha con netcat en el puerto 9001 para recibir la
conexión entrante de la reverse shell.
Luego, subimos el archivo PHP que contiene la reverse shell al directorio uploads del sitio (directorio que habíamos
descubierto previamente con Gobuster).
Al abrir este archivo desde el navegador, la página quedará cargando, lo que indica que la conexión ha sido recibida
exitosamente por netcat en nuestra máquina atacante.
Verificamos que la conexión haya sido recibida correctamente, confirmando así que la reverse shell está activa y lista
para interactuar con el sistema objetivo.
Ejecutamos el comando sudo -l para verificar si contamos con permisos de root y descubrimos que podemos ejecutar
el binario env con privilegios de superusuario.
Aprovechando esta posibilidad, realizamos la escalada de privilegios con éxito, lo que nos permitió obtener acceso root
en el sistema objetivo.
De esta forma, concluimos el laboratorio alcanzando nuestro objetivo principal: comprometimos la máquina con IP
[Link] partiendo desde nuestra máquina atacante en [Link].
