Mitigação de RCE em Node.js: DevOps como a Última Linha de Defesa

Este projeto demonstra uma vulnerabilidade crítica de Execução Remota de Código (RCE) em uma aplicação Next.js (especificamente via Server Actions) e como o endurecimento da infraestrutura neutraliza efetivamente o ataque mesmo quando a vulnerabilidade no código permanece.

Ele contrasta uma implantação padrão "Insegura" (Unsafe) com uma implantação "Segura" (Safe) endurecida usando imagens Distroless e Sistemas de Arquivos Somente Leitura.

🛡️ O Conceito: "Defesa em Profundidade"

Vulnerabilidades de software são inevitáveis. Quando o código falha, sua infraestrutura deve impedir que o atacante expanda seu ponto de apoio.

A Vulnerabilidade

Uma RCE Crítica (CVE-2025-55182, também conhecida como React2Shell) existe na implementação dos Componentes de Servidor React (RSC) usada pelo Next.js.

• CVSS: 10.0 (Crítica)
• Causa Raiz: A desserialização insegura do protocolo "Flight" permite que um atacante manipule objetos internos (via poluição de protótipo ou mecanismos similares) durante o processamento de Server Actions.
• Impacto: Isso permite a execução arbitrária de código (como spawnSync) sem autenticação.

Os Vetores de Ataque

1. Living off the Land (LotL): Usar ferramentas já presentes no SO (curl, wget, ls, cat) para roubar segredos ou baixar malware.
   • Mecanismo: O exploit usa child_process.spawnSync() do Node.js. Isso executa binários diretamente, sem precisar de um shell (/bin/sh).
2. Bring Your Own Land (BYOL): Se as ferramentas padrão estiverem ausentes, o atacante envia seu próprio binário (ex: um executável Go compilado), marca-o como executável (chmod +x) e o executa.

🏗️ Comparação de Arquitetura

📝 Análise dos Logs da Aplicação

Os logs a seguir demonstram como as tentativas de ataque parecem da perspectiva da aplicação. Esse contraste destaca vividamente a eficácia das medidas de segurança.

Logs do App Seguro (logs/server.safe.log)

Os logs mostram falhas repetidas (ENOENT).

• Por quê? spawnSync tenta executar ls, id, curl. A imagem Distroless simplesmente não possui esses binários. Não é apenas a ausência de um shell; as próprias ferramentas desapareceram.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.safe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"2. Verify Binary was Written","verification":{...},"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"","stderr":"","error_obj":{"message":"spawnSync /tmp/hello_test EACCES","code":"EACCES"},"success":true}`'

Logs do App Inseguro (logs/server.unsafe.log)

Os logs confirmam a execução bem-sucedida de comandos e a manipulação do sistema de arquivos.

[Instrumentation] Logging initialized. Writing to: /app/logs/server.unsafe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"Hello from Go binary!\\n","stderr":"","error_obj":null,"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"id","args":[],"stdout":"uid=0(root) gid=0(root) ...","stderr":"","status":0,"signal":null}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"cat","args":["/app/.env"],"stdout":"","stderr":"cat: can\'t open \'/app/.env\': No such file or directory\n","status":1,"signal":null}`'

(Nota: Nos logs inseguros, cat /app/.env falha acima porque o arquivo está nomeado como .env na raiz, mas ls -la nos logs completos revelaria a estrutura do diretório.)

💥 Resultados do POC

1. RCE Padrão (Living off the Land)

Tentativa de executar comandos shell padrão.

• Inseguro: ✅ Sucesso. O atacante pode executar id, ls, cat .env e acessar dados sensíveis.
• Seguro: ❌ Bloqueado. spawnSync /bin/sh ENOENT. Não há shell para executar comandos.

2. Ataque Avançado (Bring Your Own Land)

Tentativa de contornar a "falta de ferramentas" enviando um binário personalizado.

• Inseguro: ✅ Sucesso.
  1. O atacante divide um binário em partes (para contornar limites de carga útil).
  2. Escreve em /tmp/malware.
  3. Executa chmod +x.
  4. Executa o binário.
• Seguro: ❌ Bloqueado.
  • Falha na Escrita: EROFS: read-only file system.
  • O atacante não pode depositar arquivos em lugar algum, neutralizando efetivamente o ataque BYOL.

3. Análise de Execução "Verdadeiramente sem Arquivo" (Fileless)

Pode um atacante carregar um binário em uma variável e executá-lo diretamente da memória?

• Conceito: Concatenar partes de um binário em uma variável JavaScript global (ex: global.payload = "..."), e então executá-lo.
• Realidade: Falhou.
  • As funções child_process do Node.js (spawn, exec) exigem um caminho de arquivo. Elas não podem executar um buffer ou string diretamente.
  • Para contornar isso no Linux, é necessário memfd_create (uma chamada de sistema para criar um arquivo anônimo na RAM).
  • A Barreira: Node.js não expõe memfd_create nativamente. Acessá-lo exigiria um addon C++ (como ffi-napi) pré-instalado em node_modules.
  • Impacto do Distroless: Como a imagem carece de compiladores (gcc, make), um atacante não pode construir esse addon rapidamente.

🔐 Melhores Práticas Demonstradas

1. Use Imagens Distroless

Imagens "Distroless" contêm apenas sua aplicação e suas dependências de tempo de execução. Elas não contêm gerenciadores de pacotes, shells ou ferramentas UNIX padrão.

• Por quê? Se um atacante obtém RCE, ele não pode bisbilhotar (ls), baixar arquivos (curl) ou escalar privilégios facilmente.

2. Sistemas de Arquivos Somente Leitura

Configure seu runtime de contêiner para montar o sistema de arquivos raiz como somente leitura.

• Por quê? Isso impede que atacantes baixem (BYOL) ou modifiquem o código da sua aplicação (persistência).
• Como? No docker-compose.yml:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # CRÍTICO: bloqueie explicitamente a execução!
  

  Observação: Com esta configuração, nosso POC mostra que o atacante pode escrever o binário em /tmp (escrita bem-sucedida), mas a execução falha com EACCES (Permissão Negada) por causa da flag noexec. Isso equilibra funcionalidade (tmp gravável) com segurança.

3. Variáveis de Ambiente Nativas (O Espaço "Export")

Não envie arquivos .env em suas imagens de contêiner. Se um atacante puder ler arquivos (ex: cat .env), seus segredos estão comprometidos.

• Abordagem Segura: Injete variáveis diretamente no ambiente do processo em tempo de execução (ex: via Kubernetes Secrets, AWS Parameter Store, ou a chave environment do Docker).
• Por quê? Torna muito mais difícil para um atacante despejar todos os segredos de uma vez em comparação com a leitura de um único arquivo.

🚀 Como Executar

1. Inicie o Ambiente: Ambas as aplicações segura e insegura estão definidas em um único arquivo docker-compose.yml.

   root@kitploit:~

   docker compose up --build -d
   

2. Execute os Exploits: Você pode executar os exploits contra as portas específicas para ver a diferença.

   • Mirando o App Inseguro (Porta 3001):

     root@kitploit:~

     # 1. Standard RCE (LotL) - SUCCEEDS
     python exploit/poc.py http://localhost:3001
     
     # 2. Advanced Attack (BYOL) - SUCCEEDS
     python exploit/poc_advanced.py http://localhost:3001
     

   • Mirando o App Seguro (Porta 3000):

     root@kitploit:~

     # 1. Standard RCE (LotL) - FAILS (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. Advanced Attack (BYOL) - FAILS (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. Limpeza:

   root@kitploit:~

   docker compose down