Dificultad | Very Easy |
|---|---|
Plataforma | Hack The Box (Starting Point - Tier 0) |
SO objetivo | Linux |
Servicios | Redis |
Técnicas | Enumeración con nmap - Acceso no autenticado a Redis |
Flag | Flag única (no requiere escalada) |
Tiempo estimado | 10 minutos |
Introducción
Redeemer es una de las máquinas del Starting Point de Hack The Box, pensada para quienes recién empiezan en pentesting. A diferencia de otras máquinas del mismo nivel, no trabaja con SMB ni con un servidor web: aquí el protagonista es Redis, un motor de bases de datos en memoria que, si queda mal configurado, puede exponer toda su información sin pedir ni una sola credencial.
La máquina combina dos ideas simples pero fundamentales: un escaneo de puertos completo (no basta con revisar los primeros 1000) y la explotación de un servicio que confía por defecto en cualquiera que se conecte a él. No hay explotación de una vulnerabilidad de código ni escalada de privilegios; el "fallo" es puramente de configuración.
Reconocimiento
Como en cualquier máquina, el primer paso es lanzar un escaneo de puertos con nmap (herramienta que identifica qué puertos están abiertos y qué servicios corren detrás de ellos) para entender la superficie de ataque disponible.
- -p-: escanea los 65535 puertos (no solo los 1000 más comunes)
- -sC: ejecuta scripts básicos de reconocimiento de nmap
- -sV: intenta identificar la versión del servicio en cada puerto abierto
- -O: intenta detectar el sistema operativo del objetivo
- -T4: ajusta la velocidad del escaneo a "agresiva" para ganar tiempo
nmap -p- -sC -sV -O -T4 10.129.154.254
El resultado es revelador: de los 65535 puertos, solo uno está abierto.
La imagen muestra que únicamente el puerto 6379/tcp está abierto, corriendo Redis key-value store 5.0.7. También se aprecia que nmap identifica el sistema como Linux (kernel 4.15 - 5.19), lo cual encaja con la naturaleza "very easy" de la máquina: un único servicio, un único vector de entrada.
Este hallazgo ya marca el camino a seguir: en vez de enumerar directorios web o recursos compartidos de red, la investigación se centra por completo en Redis.
Enumeración
Redis (Remote Dictionary Server) es una base de datos en memoria muy usada como caché o como almacén de sesiones por su velocidad. Por defecto, muchas instalaciones no exigen usuario ni contraseña para conectarse, lo que la convierte en un objetivo interesante cuando queda expuesta a internet o a una red sin restricciones.
Para interactuar con el servicio se usa redis-cli, el cliente de línea de comandos oficial de Redis.
-h: indica el host al que nos queremos conectar
redis-cli -h 10.129.154.254
Al conectarnos, no se pide ninguna credencial, lo que ya confirma que el servicio está abierto sin autenticación. Una vez dentro, el comando info permite obtener estadísticas y detalles generales del servidor.
info: devuelve información y estadísticas del servidor Redis (versión, modo, uptime, etc.)
10.129.154.254:6379> info
Aquí se confirma la versión (redis_version:5.0.7), que el modo es standalone (una única instancia, sin clúster ni réplicas) y que el sistema operativo detrás es Linux. Esta información no es crítica para resolver el reto, pero ayuda a entender qué tipo de instancia se está atacando.
Bajando en la misma salida aparece la sección # Keyspace, que es la que realmente importa: db0:keys=4 indica que la base de datos con índice 0 contiene 4 claves almacenadas. Esa es la pista de que hay datos guardados y potencialmente accesibles sin restricción.
Con esa información, el siguiente paso lógico es seleccionar esa base de datos y listar qué claves contiene. En Redis, los datos se organizan en varias bases numeradas (0, 1, 2...), por lo que primero hay que "pararse" sobre la que interesa con select, y luego listar su contenido con keys.
- select 0: cambia el contexto a la base de datos con índice 0
10.129.154.254:6379> select 0
- keys *: lista todas las claves almacenadas en la base de datos seleccionada
10.129.154.254:6379> keys *
El comando devuelve cuatro claves: numb, stor, temp y flag. El nombre de la última no deja mucho a la imaginación: probablemente contenga la flag del reto.
Explotación (obtención de la flag)
Aquí no hay una vulnerabilidad técnica que explotar en el sentido clásico (no hay un exploit ni un CVE de por medio). La "explotación" consiste simplemente en aprovechar que el servicio no exige autenticación para leer directamente el contenido de una clave con el comando get.
- get flag: recupera el valor almacenado bajo la clave "flag"
10.129.154.254:6379> get flag
El servidor responde con el valor de la clave, que es directamente la flag del reto:
03e1d2b376c37ab3f5319922053953eb.
La causa raíz del problema es sencilla: Redis fue diseñado originalmente para usarse en redes internas y confiables, por lo que su configuración por defecto no obliga a establecer usuario ni contraseña. Si una instancia así queda accesible desde una red no confiable (o desde internet), cualquiera puede leer, modificar o incluso eliminar los datos almacenados sin ninguna barrera.
Flag
Al tratarse de un reto de la sección Starting Point, Redeemer solo pide una única flag: no hay una fase separada de "user flag" seguida de escalada de privilegios hasta "root flag" como en máquinas más completas. Todo el objetivo se resuelve enumerando y leyendo directamente el contenido de Redis.
Lecciones aprendidas
Escanear todos los puertos, no solo los comunes. Si el escaneo se hubiera limitado al top 1000 de nmap, este servicio se habría encontrado igual, pero conviene tener siempre el hábito de correr -p- cuando el objetivo lo permite, ya que servicios como bases de datos, colas de mensajes o paneles de administración suelen vivir fuera de ese rango.
La autenticación por defecto (o su ausencia) importa. Muchos servicios pensados para entornos internos, como Redis, MongoDB o Memcached, no exigen credenciales de fábrica. Si se despliegan sin ajustar esa configuración y quedan expuestos, cualquiera con acceso de red puede leer o manipular sus datos.
Desde la perspectiva defensiva, la solución es simple pero esencial: habilitar autenticación (requirepass en el archivo de configuración de Redis), restringir el acceso por firewall solo a los hosts que realmente lo necesitan, y evitar exponer este tipo de servicios directamente a internet o a redes no confiables.
Como aprendizaje general, esta máquina es un buen recordatorio de que no todas las vías de acceso pasan por una vulnerabilidad de código: muchas veces el punto débil es simplemente una configuración por defecto que nadie se tomó el tiempo de asegurar.