CVE-2026-27483 Lab - Ambiente de Aprendizado de Vulnerabilidades Empresariais

Um laboratório completo, realista e em estilo empresarial baseado em Docker para aprender, testar e se defender contra o CVE-2026-27483 (Path Traversal → RCE no MindsDB). Este repositório fornece uma topologia de laboratório implantável, configurações, imagens de contêiner mínimas, regras de detecção e scripts auxiliares para que você possa iniciar com segurança um ambiente isolado para praticar descoberta, exploração (saneada) e defesa.

IMPORTANTE: Este laboratório inclui intencionalmente uma versão vulnerável do MindsDB para fins educacionais. Execute apenas em ambientes isolados e sem conexão com a internet e nunca o exponha a redes públicas.

Conteúdo

Arquitetura e componentes
Início rápido (como executar)
Perfis e opções de recursos (mínimo / monitoramento)
Como o laboratório funciona (fluxo de dados detalhado e componentes)
Como usar o laboratório (contêiner do atacante, desafios, detecção)
Testes de fumaça e solução de problemas
Segurança e uso seguro
Contribuição

Arquitetura (visão geral)

Internet (Atacante)
    ↓
Proxy Reverso (nginx)
    ↓
┌─────────────────────────────────┐
│  MindsDB (Vulnerável)           │  Porta 47334
│  - Vulnerável ao CVE-2026-27483 │
└─────────────────────────────────┘
    ↓
┌─────────────────────────────────┐
│  Banco de Dados PostgreSQL      │  Porta 5432 (interna)
│  - Armazena dados do MindsDB    │
└─────────────────────────────────┘
    ↓
┌─────────────────────────────────┐
│  Pilha ELK (Registro de Logs)   │
│  - Elasticsearch, Logstash      │  Portas 9200, 5000
│  - Painel Kibana                │  Porta 5601
└─────────────────────────────────┘

Os serviços são conectados em uma rede Docker bridge dedicada (172.20.0.0/16 por padrão). Um contêiner do atacante é incluído para executar tentativas de exploração controladas contra o serviço MindsDB isolado.

Portas (host → contêiner)

80 → proxy nginx
443 → proxy nginx (se SSL estiver habilitado)
8080 → painel do proxy reverso
47334 → MindsDB (API/web)
47335 → MindsDB (API/auxiliar)
5432 → Postgres (interno, não recomendado expor)
9200 → Elasticsearch
5601 → Kibana
1025/8025 → Mailhog (SMTP/web)

Por padrão, o Postgres não deve ser exposto à internet pública. O arquivo compose mapeia serviços internos para uso local no laboratório.

Início rápido (local)

Pré-requisitos:

Docker (v20+) e Docker Compose v2+ (docker compose)
Pelo menos 8 GB de RAM recomendados para uma implantação completa (Elasticsearch + Kibana exigem memória)

Clone o repositório:

git clone https://github.com/nabhan-mohy/cve-2026-27483-lab.git
cd cve-2026-27483-lab

Copie o arquivo de ambiente de exemplo e revise os segredos:

cp .env.example .env
# Abra o .env e confirme o DB_PASSWORD e outros valores

Importante: Garanta que o DB_PASSWORD no .env corresponda à senha que o arquivo compose espera. Há um valor padrão em docker-compose.yml (${DB_PASSWORD:-P@ssw0rd123!}). Defina DB_PASSWORD=P@ssw0rd123! no .env ou edite o docker-compose.yml para usar a senha de sua preferência. Se houver divergência, o MindsDB falhará ao conectar ao Postgres e os serviços não iniciarão corretamente.

(Opcional) Edite o .env para ajustar o comportamento (habilitar/desabilitar recursos, definir IP do listener do atacante, etc.).
Inicie o laboratório (modo completo):

docker compose up -d --build

Verifique estes endpoints assim que os serviços estiverem saudáveis:

MindsDB: curl http://localhost:47334/api/status
Kibana: http://localhost:5601
Painel do proxy reverso: http://localhost:8080

Para parar e remover os contêineres:

docker compose down

Para remover volumes (destrutivo):

docker compose down -v

Perfis e opções de recursos

O README menciona perfis mínimo e de monitoramento. Para suportá-los, você pode:

Usar chaves profiles: no docker-compose.yml para separar os serviços em perfis minimal e monitoring, ou
Criar um arquivo compose de substituição, como docker-compose.minimal.yml, que desabilita componentes pesados (Elasticsearch/Kibana/Wazuh) para testes com poucos recursos.

Uma abordagem mínima sugerida para testes é comentar ou pular Elasticsearch/Kibana/Wazuh e executar apenas: mindsdb, postgres, nginx-proxy e attacker.

Como o laboratório funciona (detalhado)

Proxy reverso (nginx-proxy): atua como o endpoint voltado para o exterior e roteia o tráfego do atacante para o serviço MindsDB vulnerável. O proxy também fornece uma porta de painel simples (8080) para verificações rápidas.
MindsDB (imagem vulnerável): empacotado a partir da versão vulnerável referenciada no README. Ele armazena dados no Postgres e fornece endpoints de API que são intencionalmente vulneráveis em versões mais antigas.
Postgres: armazena a configuração e artefatos do MindsDB. O SQL de inicialização e os dados de seed são fornecidos em configs/postgres/*.sql.
Pilha ELK (Elasticsearch, Logstash, Kibana): coleta logs do proxy e da aplicação para que você possa criar regras de detecção e painéis.
Wazuh (opcional): agente e gerenciador de monitoramento de segurança. Incluído como um espaço reservado para demonstrar integração; certificados TLS e credenciais na configuração são espaços reservados e devem ser provisionados para funcionalidade completa.
Contêiner do atacante: um ambiente com utilitários (curl, netcat, python) e a pasta exploits/ montada para executar scripts de desafio de dentro da mesma rede Docker (isolada da rede do host, se desejado).
Serviço de backup: contêiner de exemplo para demonstrar fluxos de trabalho empresariais realistas (backups puxando dumps do banco de dados do Postgres).

Como usar o laboratório (fluxo de prática)

Inicie o laboratório (consulte Início rápido).
A partir do seu host, ou entrando no contêiner do atacante (docker compose exec -it attacker /bin/bash), execute reconhecimento contra o proxy (porta 80/8080) e a API do MindsDB (47334).
Progrida pelos níveis de aprendizado (reconhecimento → path traversal → RCE → persistência → defesa). Este repositório intencionalmente não inclui código de exploração armamentizado. Se você quiser scripts de desafio ou etapas de PoC saneadas, podemos adicioná-los em exploits/ e docs/challenges/ com orientação e verificações seguras.
Observe os logs no ELK e use a regra Sigma incluída (rules/sigma/cve-2026-27483.yml) como ponto de partida para detecções. Crie visualizações no Kibana para destacar caminhos de upload suspeitos, requisições anômalas e atividade inesperada no sistema de arquivos.

Exemplo: execute um reconhecimento básico a partir do contêiner do atacante

# entre no contêiner do atacante
docker compose exec -it attacker /bin/bash
# escaneie a rede ou faça curl nos endpoints
curl -v http://nginx-proxy:80/
curl -v http://mindsdb:47334/api/status

Testes de fumaça

Um script de teste de fumaça é fornecido em scripts/smoke_test.sh (se presente). Ele executa as seguintes verificações:

Compila e inicia a pilha compose
Aguarda o /api/status do MindsDB responder
Verifica se o proxy reverso nginx responde na porta 8080
Verifica o endpoint de status do Kibana
Aguarda a saúde do cluster Elasticsearch (yellow|green)
Verifica a prontidão do Postgres com pg_isready

Execute localmente:

chmod +x scripts/smoke_test.sh
./scripts/smoke_test.sh

Se o teste de fumaça falhar, colete os logs em smoke_compose_logs.txt e compartilhe-os para depuração:

docker compose logs --no-color > smoke_compose_logs.txt

cve-2026-27483-lab

Mais Populares