Arquitetura (visão geral)

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)

1. Clone o repositório:

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

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.

3. (Opcional) Edite o .env para ajustar o comportamento (habilitar/desabilitar recursos, definir IP do listener do atacante, etc.).

4. Inicie o laboratório (modo completo):

5. 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

6. Para parar e remover os contêineres:

Para remover volumes (destrutivo):

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)

1. Inicie o laboratório (consulte Início rápido).
2. 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).
3. 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.
4. 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

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:

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

Detecção e registro de logs

• O pipeline do Logstash é fornecido em configs/logstash/logstash.conf para encaminhar logs ao Elasticsearch. A regra Sigma incluída rules/sigma/cve-2026-27483.yml é um exemplo simples que sinaliza padrões suspeitos de path traversal (requisições contendo ..). Use-a como ponto de partida e refine para reduzir falsos positivos.

• Crie painéis no Kibana para visualizar:

  • URIs de upload/requisição contendo padrões de traversal
  • User agents e IPs de origem anômalos
  • Alterações em logs relacionados ao sistema de arquivos

Solução de problemas (problemas comuns)

• Falhas de autenticação no Postgres: isso geralmente ocorre devido a divergência na senha do banco entre .env e docker-compose.yml. Garanta que ambos concordem com o mesmo segredo.
• Erros/500s no MindsDB: verifique docker compose logs -f mindsdb para rastreios de pilha e erros de conectividade com o banco.
• Elasticsearch com OOM ou não iniciando: aumente a RAM do host ou reduza ES_JAVA_OPTS no docker-compose.yml (exemplo: -Xms256m -Xmx256m) para hosts pequenos.
• Healthcheck do nginx falhando: garanta que a configuração do proxy aponte para o host interno correto (mindsdb:47334) e que o contêiner mindsdb esteja saudável.

Se precisar de ajuda para depurar, execute o teste de fumaça e compartilhe smoke_compose_logs.txt.

Segurança e legal

• O laboratório inclui componentes intencionalmente vulneráveis. Use apenas em ambientes isolados e não produtivos.
• Não implante este laboratório em infraestrutura roteável publicamente.
• Mantenha código de exploração fora de commits públicos; se incluir etapas de PoC, saneie-as e siga práticas de divulgação responsável.

Contribuição

Contribuições são bem-vindas. Formas sugeridas de ajudar:

• Melhore a documentação em docs/ (implantação, desafios, detecção, resposta a incidentes)
• Adicione scripts de desafio saneados em exploits/ com guias de aprendizado passo a passo
• Adicione testes de fumaça e fluxos de trabalho de CI para validar o laboratório em push/PR

Abra PRs contra main e siga as diretrizes de CONTRIBUTING ao adicionar material educacional de exploração.

Créditos

• Descoberta da vulnerabilidade: XlabAITeam
• PoC original: Lohitya Pushkar (thewhiteh4t)
• Desenvolvimento do laboratório: Comunidade de Pesquisa em Segurança

Feito com ❤️ para a comunidade de segurança.