Writeup de la Máquina "Fawn" en Hack The Box: Guía Detallada para Principiantes

Introducción

Fawn es una de las primeras máquinas del recorrido Starting Point de Hack The Box. Su propósito no es enseñar exploits complejos, sino que el estudiante internalice el flujo metodológico básico de una prueba de penetración: reconocimiento, enumeración, identificación del vector de ataque y explotación.

La vulnerabilidad principal es la habilitación del acceso anónimo en un servidor FTP (File Transfer Protocol). Aunque simple, este problema sigue apareciendo en auditorías reales de empresas de todos los tamaños. La razón es casi siempre la misma: configuración por defecto que nadie revisó.

Conceptos Previos

¿Qué es FTP?

FTP (File Transfer Protocol) es un protocolo de red diseñado en los años 70 para transferir archivos entre sistemas. Opera en el puerto 21 (control) y el 20 (datos). Su principal debilidad desde el punto de vista de seguridad es que transmite credenciales y datos en texto plano, sin cifrado alguno.

¿Por qué FTP anónimo es peligroso?

Muchos servidores FTP permiten conectarse con el usuario 'anonymous' y una contraseña cualquiera (por convención, suele ser un correo electrónico o simplemente Enter). Esto fue diseñado para distribución pública de archivos, pero en la práctica las malas configuraciones exponen contenido sensible. Algunos ejemplos reales de impacto:

• Filtración de backups de bases de datos en empresas financieras.

• Exposición de archivos de configuración con credenciales de producción.

• Exfiltración de código fuente propietario por actores maliciosos.

¿Qué es vsftpd?

vsftpd (Very Secure FTP Daemon) es el servidor FTP más común en sistemas Linux. La versión 3.0.3 que encontraremos aquí es estable y no tiene vulnerabilidades conocidas de ejecución remota de código; el problema en Fawn no es un CVE, sino una mala configuración deliberada para el ejercicio. Sin embargo, es importante mencionar que la versión 2.3.4 de vsftpd tuvo un backdoor infame (CVE-2011-2523) que escuchaba en el puerto 6200. Un auditor siempre debe verificar la versión exacta del servicio.

Preparación del Entorno

Antes de empezar, verificamos que estamos conectados a la VPN de HTB a través de la interfaz tun0 y creamos una carpeta de trabajo para mantener ordenados los archivos generados durante la sesión.

ip a show tun0
        

mkdir fawn
cd fawn
        

Organizar las evidencias por máquina es un hábito profesional imprescindible. En una auditoría real necesitas reproducir cada paso y presentar la evidencia de forma ordenada al cliente.

Fase 1: Reconocimiento

1.1 — Verificación de Conectividad

Antes de cualquier escaneo, comprobamos que el objetivo responde en la red. Un ping exitoso nos confirma que la máquina está activa y estable, y nos da dos datos adicionales importantes: la latencia y el TTL.

ping -c 4 10.129.20.164
        

Análisis del resultado:

• TTL = 63: Los sistemas Linux/Unix empiezan con TTL 64. Al pasar por un router, el valor disminuye en 1. Un TTL de 63 indica que hay exactamente 1 salto entre nosotros y el objetivo, lo que es consistente con un entorno VPN. Un TTL de 127 indicaría Windows (valor inicial 128).

• 0% packet loss: La conexión es estable. Si hubiera pérdida de paquetes, nuestros escaneos podrían ser poco fiables.

• ~121 ms de latencia: Normal dentro de la VPN de HTB según el servidor al que estemos conectados.

1.2 — Enumeración con Nmap

Nmap (Network Mapper) es la herramienta estándar de la industria para enumeración de redes y servicios. Nuestro objetivo en esta fase es descubrir qué servicios están expuestos y en qué versión, porque la versión determina qué vulnerabilidades pueden existir.

nmap -sV -sC -Pn -oN nmap.txt 10.129.20.164
        

Desglose de parámetros

Análisis de la salida de Nmap

Nmap nos ha dado mucho más de lo que aparece a simple vista. Analicemos cada línea relevante:

• Puerto 21/tcp abierto con vsftpd 3.0.3: El servicio está activo y la versión es conocida. No tiene CVEs críticos en esta versión, así que el vector será la configuración, no una vulnerabilidad de software.

• ftp-anon: Anonymous FTP login allowed (FTP code 230): El código 230 es la respuesta estándar de 'Login successful'. El script NSE ya intentó el acceso anónimo y tuvo éxito. Esto es el hallazgo principal.

• -rw-r--r-- 1 0 0 32 Jun 04 2021 flag.txt: El propio escaneo de Nmap ya listó el contenido del servidor. El archivo tiene 32 bytes, permisos de lectura para todos, y fue creado el 4 de junio de 2021. El propietario con UID 0 es root, lo que indica que el servidor fue configurado deliberadamente así.

• TYPE: ASCII: El modo de transferencia por defecto es ASCII, no binario. Para archivos de texto como flag.txt no importa, pero en una auditoría real hay que cambiar al modo binario para transferir ejecutables o archivos comprimidos sin corrupción.

Fase 2: Explotación

2.1 — Acceso Anónimo por FTP

Con la información de Nmap ejecutamos el cliente FTP nativo de Linux para conectarnos al servidor. No necesitamos herramientas adicionales para este vector.

ftp 10.129.20.164
        

Análisis de la secuencia de conexión:

• Código 220: El servidor está listo y se identifica con su banner (vsFTPd 3.0.3). Los banners son informativos para el atacante; en producción deberían ser genéricos o eliminados.

• Usuario 'anonymous': Este usuario especial está habilitado en la configuración de vsftpd cuando el parámetro anonymous_enable=YES está presente en /etc/vsftpd.conf. Esto es configuración por defecto en muchas instalaciones.

• Código 331: El servidor solicita contraseña, pero no la validará. El protocolo RFC 1635 recomienda proporcionar un email como contraseña por convención, aunque el servidor no lo verifica.

• Código 230: Login exitoso. A partir de aquí tenemos una sesión FTP activa con los privilegios del usuario 'ftp', que en este caso puede leer el directorio raíz del servidor.

• Binary mode: vsftpd 3.0.3 usa modo binario por defecto al conectarse desde clientes modernos, lo que es correcto. En modo ASCII, los caracteres de nueva línea se traducen entre sistemas, lo que podría corromper archivos no textuales.

2.2 — Navegación y Descarga de la Flag

ls
get flag.txt
        

exit
        

Puntos técnicos importantes de esta fase:

• Modo pasivo extendido (EPSV, código 229): FTP tiene dos modos de transferencia de datos. En modo activo, el servidor inicia la conexión de datos hacia el cliente, lo que suele fallar con NAT o firewalls. En modo pasivo, es el cliente quien inicia la conexión de datos hacia un puerto alto del servidor. El modo EPSV es la versión extendida que soporta IPv6. Los clientes modernos usan pasivo por defecto, que es lo que vemos aquí.

• Código 150: El servidor abre la conexión de datos. Es el inicio de la transferencia real.

• Código 226: Transferencia completada con éxito. Si no ves este código, el archivo puede estar corrupto o incompleto.

• 32 bytes: El tamaño confirma que recibimos exactamente lo que esperábamos.

Fase 3: Obtención de la Flag

De vuelta en nuestra máquina local, leemos el contenido del archivo descargado:

cat flag.txt
        

Perspectiva Profesional

¿Cómo se vería esto en un reporte de pentesting real?

Si encontraras este hallazgo en una auditoría a un cliente, lo documentarías aproximadamente así:

Perspectiva del Defensor

Un buen profesional de seguridad entiende tanto el ataque como la defensa. Si fueras el administrador del sistema que quiere detectar o prevenir este acceso:

Prevención

• Deshabilitar acceso anónimo: Editar /etc/vsftpd.conf y establecer anonymous_enable=NO, luego reiniciar el servicio.

• Migrar a SFTP: FTP no cifra el tráfico. SFTP (SSH File Transfer Protocol) es el reemplazo moderno y seguro. Configurable con el servidor OpenSSH ya presente en la mayoría de sistemas Linux.

• Principio de mínimo privilegio: Si FTP es necesario, asegurarse de que el usuario ftp solo tenga acceso a directorios específicos mediante chroot jail.

Detección

• Monitorizar logs de vsftpd (/var/log/vsftpd.log) para conexiones con usuario anonymous.

• Configurar alertas en SIEM para el código de respuesta FTP 230 con usuario anonymous.

• Realizar escaneos periódicos internos con Nmap para detectar servicios con acceso anónimo.

Conclusiones y Lecciones Aprendidas

Fawn demuestra que las vulnerabilidades más críticas no siempre son las más técnicas. Un FTP mal configurado puede exponer datos sensibles de una organización con el mismo impacto que un exploit de día cero, pero con mucho menos esfuerzo por parte del atacante.

Lecciones técnicas de esta máquina

1. La enumeración metódica con Nmap revela vectores de ataque que el ojo humano pasaría por alto. Los scripts NSE como ftp-anon automatizan checks de seguridad básicos.

2. La versión del servicio importa. Siempre busca CVEs asociados a la versión exacta antes de asumir que no hay vulnerabilidades de software.

3. FTP anónimo no es solo un problema teórico: es un hallazgo frecuente en auditorías reales, especialmente en servidores legacy o mal mantenidos.

4. El modo pasivo vs activo de FTP es un concepto que aparecerá constantemente en redes corporativas con firewalls y NAT.

5. Documentar evidencias en tiempo real con -oN en Nmap y guardar outputs es un hábito profesional que marca la diferencia en una auditoría real.

El flujo metodológico fundamental

Este flujo aplica a prácticamente todas las máquinas Very Easy y Easy de HTB y a muchas situaciones de auditoría real. Interiorízalo hasta que sea automático.