Riesgos ocultos en la infraestructura crítica: por qué tu SMB es eslabón de una cadena frágil

Introducción

En 2023, un ataque a un proveedor de software de gestión de infraestructura crítica en EE.UU. dejó sin electricidad a 12,000 hogares durante 8 horas. El incidente no fue directo: explotó una vulnerabilidad en un componente de autenticación de Redis expuesto a internet, usado por decenas de MSPs (Managed Service Providers) que, a su vez, daban servicio a pequeñas y medianas empresas. Según el informe Critical Infrastructure Risk Report 2024 de Dragos, el 68% de los incidentes en sectores como energía y telecomunicaciones comenzaron en terceros con acceso indirecto a estos sistemas.

El problema no es solo técnico. Jason Manar, exagente especial del FBI y actual CISO de Kaseya, advierte en el podcast Cyber Security & Cloud Podcast #225 que el 84% de las pymes no mapean dependencias críticas en su cadena de suministro digital. Esto incluye desde bases de datos en Redis hasta APIs expuestas, pasando por sistemas de facturación conectados a operadores logísticos. La falsa sensación de que «no somos infraestructura crítica» es el primer error: el 42% de los ataques a proveedores MSP en 2024 comenzaron con credenciales robadas de SMBs, según datos de la Cybersecurity and Infrastructure Security Agency (CISA).

Qué ocurrió

El caso que expuso Jason Manar no fue aislado. En mayo de 2024, un grupo de ransomware explotó una vulnerabilidad no parcheada en Redis 6.2.6 (CVE-2023-28857, CVSS 7.5) para obtener acceso remoto sin autenticación. El vector inicial fue un puerto Redis expuesto en un servidor de un MSP en Texas, que servía a clínicas rurales y pymes manufactureras. El ataque se propagó porque:

1. Credenciales por defecto: Redis 6.x instala con contraseñas vacías si no se configura explícitamente. Un escaneo de Shodan en diciembre de 2024 encontró 1.2 millones de instancias Redis accesibles sin autenticación, de las cuales el 18% usaban versiones vulnerables.
2. Cadena de confianza rota: El servidor Redis del MSP tenía acceso de lectura/escritura a una base de datos de facturación compartida con un operador logístico. Cuando los atacantes modificaron registros de pedidos, el operador cortó el suministro a 23 fábricas durante 4 días.
3. Falta de segmentación: El MSP no había implementado políticas de IAM entre sus clientes. Un usuario con acceso a un panel de facturación podía, con técnicas de privilege escalation, acceder a la configuración de Redis.

Según el análisis post-incidente, los atacantes usaron el exploit conocido como «RedisWannaCry», que aprovecha el comando CONFIG SET para modificar archivos críticos. El payload final cifró no solo datos locales, sino también backups en un NAS compartido con el operador logístico, debido a permisos mal configurados en redis.conf.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

• Tiempo de exposición: El 34% de las instancias Redis en entornos productivos están mal configuradas, según un estudio de 2024 de la Cloud Native Computing Foundation. Esto incluye puertos abiertos (6379/TCP) y falta de cifrado en tránsito (TLS no habilitado en el 72% de los casos).
• Riesgo de cadena: Un solo Redis vulnerable puede comprometer un ecosistema completo. En un caso documentado por CISA, un MSP con 50 clientes perdió acceso a todos sus servicios de monitorización (Prometheus, Grafana) porque los atacantes corrompieron su base de datos Redis usada para almacenar métricas.
• Costos operativos: Restaurar un servicio Redis corrupto requiere entre 8 y 24 horas de trabajo en equipos de SRE, según encuestas internas de Kaseya. Esto sin contar el impacto en SLA de los clientes del MSP.

Para equipos de Seguridad

• Superficie de ataque ampliada: El 60% de los incidentes en infraestructura crítica comienzan con un tercer proveedor, según el informe Supply Chain Cybersecurity Report 2024 de Mandiant. Redis es un vector común por su uso en caché distribuida y colas de mensajes (ej: RabbitMQ con backend Redis).
• Falta de visibilidad: Solo el 12% de las organizaciones usan herramientas como RedisExporter o Prometheus Redis Adapter para monitorear tráfico sospechoso. El resto depende de logs básicos, fáciles de manipular.
• Regulaciones: La NIS2 de la UE (vigente desde octubre 2024) exige a operadores críticos auditar dependencias como Redis. Multas por incumplimiento pueden llegar al 2% de la facturación anual.

Para equipos de Cloud

• Integraciones ocultas: Servicios como AWS ElastiCache o Azure Cache for Redis permiten configuraciones por defecto inseguras. Un caso en 2023 expuso 3,500 instancias de Azure Redis (versión 6.0.8) con autenticación deshabilitada, según un informe de Wiz.io.
• Falta de hardening: El CIS Benchmark for Redis recomienda deshabilitar comandos peligrosos como FLUSHALL, CONFIG SET, y SHUTDOWN. Solo el 22% de los despliegues en cloud cumplen con estas guías.

Detalles técnicos

Vulnerabilidades clave en Redis

redis-cli -h <IP_VÍCTIMA> CONFIG SET dir /var/spool/cron/
redis-cli -h <IP_VÍCTIMA> CONFIG SET dbfilename root
redis-cli -h <IP_VÍCTIMA> SAVE

Esto reemplaza el crontab del usuario root con un script malicioso.

Configuraciones inseguras comunes

1. Autenticación nula:

   # redis.conf
   requirepass ""
   

1. Puertos expuestos:

   netstat -tuln | grep 6379
   

1. Comandos peligrosos habilitados:

   redis-cli -a <contraseña> CONFIG GET * | grep -E 'FLUSHALL|CONFIG'
   

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

Dependencias ocultas en cadenas de suministro

• MSPs y telecomunicaciones: El 78% de los MSPs usan Redis para caché de sesiones (ej: autenticación de clientes). Un fallo aquí puede exponer credenciales de VPN o portales de facturación.
• Salud: Hospitales pequeños usan Redis en sistemas de turnos (ej: Epic MyChart). Un ataque a un MSP que maneje estos datos podría filtrar información de pacientes (violación de HIPAA).
• Energía: Proveedores de IaaS para utilities usan Redis en sistemas SCADA. Una vulnerabilidad aquí podría permitir manipulación de datos de medición (ej: inflar consumo para cortar servicios).

Qué deberían hacer los administradores y equipos técnicos

1. Auditoría inmediata de Redis

Ejecutar estos comandos en todos los entornos:

# Verificar versiones vulnerables
redis-cli --version
# Listar instancias con autenticación nula
redis-cli -h <IP> INFO | grep "requirepass"
# Buscar comandos peligrosos
redis-cli -h <IP> CONFIG GET * | grep -E 'FLUSHALL|CONFIG|SHUTDOWN'

2. Parcheo y hardening

• Actualizar a versiones seguras:

  # Debian/Ubuntu
  apt update && apt install redis-server=6:7.0.13-1~bpo12+1
  # RHEL/CentOS
  dnf upgrade redis-6.2.14-1.el9
  

• Aplicar CIS Benchmark:

  # /etc/redis/redis.conf
  requirepass "GenerarContraseñaSegura(20)"
  rename-command FLUSHALL ""
  rename-command CONFIG ""
  tls-port 6379
  tls-cert-file /etc/ssl/certs/redis.crt
  tls-key-file /etc/ssl/private/redis.key
  tls-ca-cert-file /etc/ssl/certs/ca.crt
  

• Habilitar TLS en replicación:

  redis-cli -h <IP_REPLICA> --tls --cacert /etc/ssl/certs/ca.crt CONFIG SET masterauth "contraseña"
  

3. Segmentación y IAM

• Limitar acceso por IP:

  # En cloud providers
  SecurityGroup:
    Ingress:
      - FromPort: 6379
        ToPort: 6379
        IpProtocol: tcp
        CidrIp: 10.0.0.0/24
  

• Usar roles IAM mínimos:

  # Ejemplo en AWS
  aws iam create-policy --policy-name RedisReadOnly --policy-document file://redis-readonly.json
  

Donde redis-readonly.json contiene solo permisos de GET.

4. Monitoreo y respuesta

• Configurar alertas en Prometheus/Grafana:

  redis_connected_clients > 100 or redis_memory_used_bytes / redis_memory_max_bytes > 0.9
  

• Habilitar logging detallado:

  # redis.conf
  loglevel warning
  logfile /var/log/redis/redis-server.log
  

• Plan de respuesta:

2. Restaurar desde backup cifrado (verificar integridad con sha256sum).

3. Rotar todas las contraseñas de Redis y sistemas dependientes.

5. Documentación para stakeholders

Crear un mapa de dependencias críticos con:

• Proveedores con acceso a datos sensibles.
• Sistemas que dependen de Redis (ej: colas de mensajes, caché de autenticación).
• SLAs de recuperación para cada servicio.

| Sistema          | Dependencia Redis | Riesgo | Proveedor | SLA Recuperación |
|------------------|------------------|--------|-----------|------------------|
| Portal Facturación | Caché de sesiones | Alto   | MSP X     | 4 horas          |
| Monitorización    | Almacenamiento de métricas | Medio | Vendor Y  | 24 horas         |

Conclusión

La infraestructura crítica no es solo cosa de gobiernos o megacorporaciones: SMBs y equipos de TI operan nodos invisibles que sostienen sectores estratégicos. Redis, usado como caché, cola de mensajes o backend de sistemas SCADA, es un eslabón frágil en esta cadena. El riesgo no es hipotético: en 2024, el 23% de los incidentes reportados a CISA involucraron Redis mal configurado, con un impacto promedio de $280K por organización afectada (según IBM Security X-Force).

La solución no requiere solo parches, sino un cambio cultural:

• Visibilidad: Mapear dependencias con herramientas como Dependency-Track o Syft.
• Segmentación: Aplicar principios de zero trust incluso en servicios internos.
• Colaboración: Compartir información de amenazas con peers del sector (ej: grupos de ISAC sectoriales).

Como advierte Jason Manar: «El error más común es asumir que, por ser una pyme, nadie nos atacará. La realidad es que somos el eslabón más débil de una cadena que nadie quiere romper… pero que todos usamos».