Tras un análisis de puertos, encontramos la siguiente información.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ sudo nmap -sT -Pn -p- 10.129.5.202 # Indica puertos 22,80$ sudo nmap -sT -Pn -p22,80 -sVC 10.129.5.202 # Indica "Did not follow redirect to http://snapped.htb/". Lo añadimos a /etc/hosts$ sudo nmap -sT -Pn -p22,80 -sVC snapped.htb
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.15 (Ubuntu Linux; protocol 2.0)| ssh-hostkey:
| 256 4b:c1:eb:48:87:4a:08:54:89:70:93:b7:c7:a9:ea:79 (ECDSA)|_ 256 46:da:a5:65:91:c9:08:99:b2:96:1d:46:0b:fc:df:63 (ED25519)80/tcp open http nginx 1.24.0 (Ubuntu)|_http-title: Snapped \xE2\x80\x94 Infrastructure. Orchestration. Control.
|_http-server-header: nginx/1.24.0 (Ubuntu)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 9.55 seconds
# En UDP nada relevante: dhcpc (68) y zeroconf (5353) open|filtered.
22/tcp (OpenSSH 9.6p1): Algunas vulnerabilidades pero no relevantes, lo consideramos no vulnerable.
80/tcp (nginx 1.24.0): Versión descatalogada con algunas vulnerabilidades, pero no relevantes.
Como nmap nos ha indicado que nginx sirve páginas distintas en función del (sub)dominio, de ahí el “Did not follow redirect to http://snapped.htb/”, probamos a analizar subdominios.
Antes de ir a por el subdominio, entramos a la página principal para ver qué hay.
Parece una página que ofrece servicios de infrastructura de red. Pese a que se habla mucho de lo que hace la empresa, no hay ni un solo botón que haga algo, lo que ya apuntaría a que deberíamos buscar algo más, como el subdominio encontrado antes.
Nada más entrar, vemos que se trata de Nginx UI, una interfaz para gestionar servidores web Nginx, de código abierto.
Si miramos el código fuente, vemos que no hay gran cosa porque el contenido de la página se manda por partes, solo aparece el fondo en html, pero nada más. Para ver todo lo demás, analizamos las solicitudes con Burpsuite.
Recargamos la página, y en una de las solicitudes (a /assets/index-DoHxQupa.js), vemos que aparece lo siguiente:
Puede verse un match con el keyword “version” del elemento ./version-BWPlJ0ga.js
El endpoint /mcp-message aplica una lista blanca que por defecto está vacía, y Nginx UI interpreta esto como un “permitir todo”. Esto significa que pueden crearse y eliminar archivos de config., reiniciar Nginx, forzar recargas de configuraciones, etc.
Cuando Nginx UI crea un backup, mete los archivos de config. en un zip y lo cifra, luego calcula los hashes de los archivos y los mete en un documento hash_info.txt, que cifra también. Al acabar, entrega la clave de cifrado al usuario.
Cuando se intenta restaurar un backup, como Nginx UI no se ha generado ni guardado ninguna firma propia para garantizar que el backup es “bueno”, le sirve con que los hashes de hash_info.txt coincidan con los de los archivos. Esto permite subir un backup manipulado habiendo modificado las configuraciones y recalculado los hashes, que Nginx UI tomará como bueno.
Para poder ir descartando, descargo un script que comprueba si un servidor es vulnerable al primer CVE:
En un README del reporte del CVE-2026-27944 en VulnHub encontramos otro script que, además de comprobar si el servidor es vulnerable, permite explotar la vulnerabilidad si está presente.
Vemos que efectivamente funciona, el servidor es vulnerable. Además, hemos obtenido dos usuarios con sus respectivos hashes de contraseña, que tras una búsqueda resultan ser bcrypt.
Miramos puertos en local, solo están Nginx UI también hosteado en local (127.0.0.1:9000) y CUPS (127.0.0.1:631):
1
2
3
4
5
6
7
$ netstat -tunlp | grep 127.0.0.1
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)tcp 00 127.0.0.1:9000 0.0.0.0:* LISTEN -
tcp 00 127.0.0.1:631 0.0.0.0:* LISTEN -
# Si solicitamos con curl a cada una veremos que son Nginx UI y CUPS respectivamente.
Se está ejecutando CUPS 2.4.7. Si buscamos la versión, vemos que no es estrictamente vulnerable a nada que permita escalar privilegios, pero si cups-browsed está activado y su versión es menor a la 2.0.2, es posible iniciar una cadena de vulnerabilidades que nos consiga llegar a root.
Para esto comprobamos si cups-browsed está activo y su versión:
1
2
3
4
5
6
7
8
$ cups-browsed --version
cups-browsed version 2.0.0
$ systemctl status cups-browsed
● cups-browsed.service - Make remote CUPS printers available locally
Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; enabled; preset: enabled) Active: active (running) since Fri 2026-05-29 05:30:17 EDT; 14h ago
...
Es potencialmente vulnerable, así que probamos con un script que comprueba si realmente lo es:
1
2
3
4
5
6
7
$ python3 cosa.py --targets 127.0.0.1 --callback 127.0.0.1:1337
[2026-05-29 20:00:22] starting callback server on 127.0.0.1:1337
[2026-05-29 20:00:22] callback server running on port 127.0.0.1:1337...
[2026-05-29 20:00:22] starting scan
[2026-05-29 20:00:22] scanning range: 127.0.0.1 - 127.0.0.1
[2026-05-29 20:00:22] scan done, use CTRL + C to callback stop server
# No llega nada pasado un rato
Como debería llegar un callback desde el servicio vulnerable, pero no llega nada, podemos deducir que posiblemente esta build específica no sea vulnerable, y si cups-browsed es el primer paso en la cadena de vulnerabilidades, y no es vulnerable, no hay mucho que podamos hacer, así que vamos a otra cosa.
Vemos que estamos en el directorio personal de jonathan, en /home, y que parece un directorio bastante normal. Tiene lo que suele haber en un directorio personal en Linux:
$ ls -al
total 76-rw-r--r-- 1 root jonathan 0 Mar 20 12:28 .bash_history
-rw-r--r-- 1 jonathan jonathan 220 Mar 312024 .bash_logout
-rw-r--r-- 1 jonathan jonathan 3771 Mar 312024 .bashrc
drwx------ 9 jonathan jonathan 4096 Mar 20 11:38 .cache
drwx------ 12 jonathan jonathan 4096 Mar 20 11:38 .config
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Desktop
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Documents
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Downloads
drwx------ 4 jonathan jonathan 4096 Mar 20 11:38 .local
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Music
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Pictures
-rw-r--r-- 1 jonathan jonathan 807 Mar 312024 .profile
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Public
drwx------ 3 jonathan jonathan 4096 Mar 20 11:38 snap
drwx------ 2 jonathan jonathan 4096 Mar 20 11:38 .ssh
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Templates
-rw-r----- 1 root jonathan 33 May 29 05:29 user.txt
drwxr-xr-x 2 jonathan jonathan 4096 Mar 20 11:38 Videos
Si miramos lo que hay en cada directorio de estos, vemos que todos, salvo snap/ están vacíos (y .ssh, evidentemente.). Además, antes no había buscado vulnerabilidades de la versión del kernel, pero si buscamos esto en Internet:
$ snap --version
snap 2.63.1+24.04
snapd 2.63.1+24.04
... # Versión válida$ ls -al /usr/lib/snapd/snap-confine
-rwsr-xr-x 1 root root 159016 Aug 202024 /usr/lib/snapd/snap-confine
# SUID Bit puesto$ snap list | grep -iE 'firefox|snap-store'firefox 129.0.2-1 4793 latest/stable/… mozilla** -
snap-store 0+git.e3dd562 1173 2/stable/… canonical** -
# Ambos ejemplos instalados (bastaría cualquiera de ellos o uno diferente)$ systemctl is-active systemd-tmpfiles-clean.timer
active
# Temporizador activo$ which busybox
/usr/bin/busybox
# Busybox instalado
Cumplimos todo lo que se pide, así que es bastante probable que el exploit funcione. En este caso vamos a usar la variante SUID proporcionada por el exploit porque es la indicada para Ubuntu 24.04.
Antes de nada, el exploit indica que el tiempo hasta conseguir el shell como root depende del período del timer de systemd-tmpfiles-clean, que puede tardar por defecto entre 10 y 30 días. Convendría comprobar que no vamos a tardar un mes en explotar esto.
