Publicado: 04 de Mayo de 2025
Autor: José Miguel Romero aka x3m1Sec
Dificultad: ⭐ Fácil
📝 Descripción
Esta máquina Linux explota una vulnerabilidad de ejecución de código arbitrario en la biblioteca Python Searchor para obtener acceso inicial. Posteriormente, se escalan privilegios aprovechando permisos sudo en un script de Python sin la adecuada sanitización.
10.10.11.208 - searcher.htb
🚀 Metodología
graph TD
A[Reconocimiento] --> B[Enumeración Web]
B --> C[Descubrimiento de Searchor v2.4.0]
C --> D[Explotación de Eval]
D --> E[Reverse Shell como svc]
E --> F[Descubrimiento de Credenciales Git]
F --> G[Escalada mediante System-Checkup.py]
G --> H[Shell como Root]
🔭 Reconocimiento
Ping para verificación en base a TTL
❯ ping -c 1 10.10.11.208
PING 10.10.11.208 (10.10.11.208) 56(84) bytes of data.
64 bytes from 10.10.11.208: icmp_seq=1 ttl=63 time=110 ms
--- 10.10.11.208 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 109.839/109.839/109.839/0.000 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.11.208 | grep ^[0-9] | cut -d '/' -f1 | tr '\n' ',' | sed s/,$//)
nmap -sC -sV -p$ports 10.10.11.208
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-21 20:44 -05
Nmap scan report for 10.10.11.208
Host is up (0.12s latency).
Not shown: 65464 closed tcp ports (reset), 69 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nmap done: 1 IP address (1 host up) scanned in 29.96 seconds
Enumeración de servicios
❯ nmap -p 22,80 -sV -sC --min-rate 2000 10.10.11.208 -oN services.txt
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-21 20:45 -05
Nmap scan report for 10.10.11.208
Host is up (0.11s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 4fe3a667a227f9118dc30ed773a02c28 (ECDSA)
|_ 256 816e78766b8aea7d1babd436b7f8ecc4 (ED25519)
80/tcp open http Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://searcher.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: searcher.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
⚠️ Importante: El servicio HTTP redirige a searcher.htb. Debemos agregar este dominio a nuestro archivo hosts.
echo "10.10.11.208 searcher.htb" | sudo tee -a /etc/hosts
🌐 Enumeración Web
Al acceder a la web, descubrimos un motor de búsqueda unificado que genera URLs de consulta para varios motores de búsqueda.
Realizando fuzzing de vhosts descrubirmos un vhost llamado gitea que añadimos también a nuestro fichero /etc/hosts
echo "10.10.11.208 gitea.searcher.htb" | sudo tee -a /etc/hosts
Hallazgo clave
En el pie de página, se revela que la aplicación usa Searchor v2.4.0. Una investigación rápida muestra que esta versión es vulnerable a ejecución de código arbitrario y un exploit público:
❯ nc -lvnp 9001
listening on [any] 9001 ...
connect to [10.10.14.41] from (UNKNOWN) [10.10.11.208] 47898
bash: cannot set terminal process group (1641): Inappropriate ioctl for device
bash: no job control in this shell
svc@busqueda:/var/www/app$ whoami
svc
¡Éxito! Hemos obtenido acceso al sistema como usuario svc.
Verificamos que se está haciendo de una mala práctica de re-utilización de contraseñas y el usuario svc también usa esta contraseña, por lo que podemos ganar acceso a la máquina a través del puerto ssh con el usuario svc y de esta forma ganar persistencia.
ssh svc@10.10.11.208
Permisos sudo
Comprobamos los permisos sudo del usuario svc:
svc@busqueda:~$ sudo -l
[sudo] password for svc:
Matching Defaults entries for svc on busqueda:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty
User svc may run the following commands on busqueda:
(root) /usr/bin/python3 /opt/scripts/system-checkup.py *
Análisis del script vulnerable
Descubrimos que el usuario svc no tiene permisos de escritura ni lectura pero podemos ejecutar system-checkup.py como root:
svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py *
Usage: /opt/scripts/system-checkup.py <action> (arg1) (arg2)
docker-ps : List running docker containers
docker-inspect : Inpect a certain docker container
full-checkup : Run a full system checkup
Uso del parámetro docker-ps del script system-checkup.py
Podemos utilizar {{json .}} como el argumento de formato requerido por el argumento docker-inspect del script.
Para leer la salida JSON convenientemente, podemos utilizar jq para analizar la salida JSON en un formato legible. jq
puede ser instalado utilizando el siguiente comando, sin embargo, ya está presente en la máquina de destino.
Ejecutamos el script con los parámetros adecuados sobre el conteendor de gitea:
Esta contraseña nos permite autenticarnos en el vhost http://gitea.searcher.htb como usuario Administrator y acceder al repositorio de script, pudiendo de esta forma analizar su contenido:
Al revisar el script comprobamos que si pasamos como argumento la opción "full-checkup" ejecuta el script ./full-checkup.sh:
Explotación del script
Aprovechamos la referencia relativa a full-checkup.sh ejecutando el script system-checkup desde otro directorio que contendrá nuestro propio script malicioso full-checkup.sh.
Creamos una reverse shell con el siguiente contenido:
Por útimo, lanzamos de nuevo el script desde el directorio /tmp para que abusando de la ruta relativa se ejecute el script full-checkup.sh malicioso con nuestra reverse shell:
