> For the complete documentation index, see [llms.txt](https://propus.gitbook.io/hackbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://propus.gitbook.io/hackbook/writeups/dockerlabs/vulnvault.md).
# 🟩 Vulnvault
🧠Dificultad: Fácil | 🔓16/10/2025
## 🕵️ Reconocimiento
Comenzamos con un escaneo de puertos con `nmap`:
```bash
nmap -sC -sV -Pn $IPTARGET | tee nmap
```
Como hay un servicio `HTTP` activo, hacemos un escaneo de directorios:
```bash
ffuf -w /usr/share/wordlists/SecLists-2025.2/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt:FUZZ -u http://$IPTARGET/FUZZ -e .html,.php,.txt,.xml,.js
```
En el directorio `/index.php` hay un apartado llamado `Acerca de` donde nos da a entender que la función de generar reportes puede ser vulnerable a `Command Injection`:
El apartado para generar nuestros reportes es el siguiente:
Si probamos a introducir en algún campo la siguiente cadena:
```plaintext
; echo "Prueba"
```
Vemos que se ha ejecutado el comando.
## 🚪 Ganando acceso
Vamos a intentar inyectar una reverse shell. Para ello, vamos a ver algunos binarios que hay disponibles en el sistema con el comando `which`:
Tenemos `python3`, `bash` y `sh`. Aunque no aparezca en la captura, también tenemos `php` y otros binarios que nos pueden servir.
Probamos a mandar la reverse shell:
Pero a nuestra máquina no nos llega ninguna petición. Intentando con distintas reverse shells, vemos que no funciona correctamente. Es posible que el código `php` esté escapando algunos caracteres.
Vamos a intentar ver qué usuarios hay en el sistema:
Existe un usuario llamado `samara`. Curiosamente tenemos permisos para ver su `/home`:
Podemos obtener el `id_rsa` de `samara` para acceder por `ssh`:
Lo copiamos a nuestra máquina y le damos permisos de lectura/escritura:
```bash
chmod 600 id_rsa
```
Ahora si podemos acceder por `ssh` con el `id_rsa`:
## 💥 Escalada de privilegios
Una vez dentro de la máquina, listamos los servicios que están corriendo.
Nos fijamos que se está ejecutando el script localizado en `/usr/local/bin/echo.sh` como `root`. Para este script, tenemos permisos de escritura, por lo que podemos modificarlo.
En mi caso, voy a hacer que el binario `/bin/bash` tenga el bit `SUID` activado para obtener una shell con `root` fácil.
Si esperamos, vemos que ahora el binario efectivamente tiene el bit `SUID` activado. Ejecutamos `/bin/bash -p` para lanzar una shell con permisos del propietario (`root`):
