Laboratório de Pesquisa CVE-2025-53770

Este repositório parece ser um projeto de pesquisa de prova de conceito para validar um problema de desserialização e processamento de painel de ferramentas do estilo SharePoint em um laboratório controlado. Inclui um driver Python, um aplicativo vulnerável simulado e ativos de contêiner para testes isolados.

[!AVISO] Este projeto deve ser usado apenas em sistemas, contêineres ou redes que você possui ou para os quais está explicitamente autorizado a testar. Não execute este código contra infraestrutura pública, serviços de terceiros, ambientes de produção ou qualquer destino sem permissão por escrito. Testes de segurança não autorizados podem violar leis, contratos, políticas ou termos de uso aceitáveis.

O conteúdo deste repositório deve ser tratado como material de pesquisa de segurança sensível. Se você usar este projeto para trabalho de avaliação, mantenha a execução isolada, registre toda a atividade e coordene com o proprietário do sistema antes de testar.

Escopo do Projeto

O repositório atualmente contém:

• sploit.py: driver Python assíncrono que envia requisições criadas a um endpoint ToolPane.
• lab/mock_vulnerable_app.cs: aplicativo ASP.NET simulado que reflete um marcador de validação e, em sua forma atual, pode executar um comando fornecido dentro do contêiner do laboratório.
• lab/docker-compose.yml: laboratório local de dois contêineres que separa o alvo simulado do terminal do atacante.
• lab/Dockerfile: compilação multi-estágio .NET que publica o aplicativo vulnerável simulado em uma imagem de runtime ASP.NET menor e o executa como um usuário não root.
• lab/attacker.Dockerfile: definição do contêiner atacante Python que pré-instala o conjunto de dependências do script necessário para o terminal do laboratório.
• lab/vulnerable.csproj: arquivo de projeto web .NET 6 para o aplicativo vulnerável simulado.
• lab/genGadget.py: script auxiliar para gerar um payload Base64 compactado para teste de desserialização apenas no laboratório.

Configuração e Uso

Este fluxo de trabalho é destinado apenas ao laboratório local.

Pré-requisitos:

• Docker Engine com suporte a Compose
• Um shell local com permissão para executar comandos Docker

Inicie o laboratório a partir do diretório lab/:

cd lab
docker-compose up --build -d

Se sua configuração do Docker exigir privilégios elevados, execute os mesmos comandos com sudo.

Confirme que ambos os contêineres estão em execução:

docker-compose ps

Registro de logs em caso de problemas ou validação de exploit:

docker logs sp_attacker
docker logs sp_vulnerable_lab

O laboratório está intencionalmente isolado:

• o contêiner alvo é executado na rede interna lab_net;
• nenhuma porta é publicada para o host;
• o contêiner atacante é fornecido como um terminal descartável dentro da mesma rede privada.

Abra um shell no contêiner atacante:

docker exec -it sp_attacker bash

Dentro do contêiner atacante, você pode realizar verificações seguras no laboratório, como confirmar que o alvo está acessível e testar o script no modo de verificação contra o alvo simulado:

python3 sploit.py http://sp_vulnerable_lab/
# Se a resolução de DNS do nome do serviço falhar no seu ambiente, use o IP do laboratório:
# python3 sploit.py http://10.10.10.5
# Se desejar ir além da validação básica, pode incluir comandos desejados.
python3 sploit.py http://sp_vulnerable_lab whoami

Comportamento esperado no ambiente simulado local:

• o alvo deve ser acessível como http://sharepoint-target a partir do contêiner atacante;
• o aplicativo simulado retorna um marcador determinístico para verificação;
• quaisquer artefatos de resultado produzidos pelo script permanecem dentro do espaço de trabalho do laboratório montado.

Notas operacionais:

• mantenha o laboratório desconectado de redes externas e não publique o serviço alvo para o host;
• não reutilize este ambiente para avaliação em produção;
• se você modificar o aplicativo simulado ou as definições do contêiner, reconstrua as imagens antes de testar novamente.

Limpeza

Pare e remova os contêineres e a rede do laboratório:

cd lab
docker-compose down

Se desejar remover também as imagens construídas:

docker-compose down --rmi local

Se desejar uma reinicialização completa dos artefatos do espaço de trabalho do laboratório, remova quaisquer arquivos de resultado gerados após o desligamento:

rm -f vuln.lst

Prática de limpeza recomendada após cada exercício:

1. desligue o laboratório com docker-compose down;
2. remova artefatos de resultado que não devem persistir;
3. reconstrua o laboratório antes da próxima execução se você alterou código, dependências ou configurações do contêiner.

Resumo de Validação

O projeto é estruturalmente válido como um laboratório de pesquisa local, mas não deve ser tratado como um validador seguro para produção em sua forma atual.

O que está funcionando:

• A topologia do laboratório é simples e reproduzível.
• O driver Python pode testar um alvo ou uma lista de alvos.
• O aplicativo simulado fornece indicadores de sucesso determinísticos para verificação em laboratório.

O que requer cautela:

• O script principal inclui comportamento explícito de execução de comandos quando um segundo argumento é fornecido.
• A verificação TLS está desabilitada em requisições de saída.
• Achados positivos são escritos em vuln.lst, o que pode criar dados residuais sensíveis desnecessários.
• O aplicativo simulado executa entrada de shell diretamente e nunca deve ser exposto fora de um laboratório isolado.

Metodologia

Use este projeto apenas para validação controlada de detecção e exposição, não para exploração operacional.

Metodologia recomendada:

1. Construa um ambiente de laboratório isolado sem exposição externa.
2. Valide os limites da rede para que apenas o pesquisador possa alcançar o serviço simulado.
3. Execute o alvo do laboratório e confirme que o aplicativo responde ao endpoint pretendido.
4. Use o driver apenas no modo de verificação não destrutivo para confirmar se o alvo reflete o marcador esperado.
5. Capture artefatos de requisição e resposta para documentação e, em seguida, destrua o ambiente do laboratório após o teste.

Para trabalhos de avaliação no mundo real, o padrão mais seguro é substituir a validação do tipo exploit por um ou mais dos seguintes:

• verificação de versão e nível de patch;
• revisão de configuração autenticada;
• análise de logs da camada web;
• revisão de telemetria de EDR, SIEM e WAF;
• indicadores de comprometimento fornecidos pelo fornecedor e verificações de integridade.

Impacto

Se um alvo for genuinamente vulnerável a uma falha de desserialização em um componente de aplicativo privilegiado, o impacto potencial pode ser grave:

• execução remota de código no contexto de segurança do serviço afetado;
• perda de confidencialidade de dados do aplicativo, credenciais e segredos;
• perda de integridade por meio de adulteração de conteúdo ou configuração;
• degradação de disponibilidade devido a comandos destrutivos ou ações posteriores;
• oportunidades de movimento lateral se o host tiver privilégios amplos de rede ou identidade.

Mesmo em um laboratório, semânticas de execução de comandos aumentam significativamente o risco, pois normalizam fluxos de trabalho que devem ser reservados para investigação estritamente controlada e autorizada.

Mitigações

O caminho de mitigação adequado é defensivo e em camadas.

Ações imediatas:

1. Aplique atualizações de segurança do fornecedor e orientações de emergência para a versão do produto afetado.
2. Remova a exposição pública ou restrinja o acesso à superfície do aplicativo vulnerável.
3. Rotacione credenciais e revise contas de serviço privilegiadas se houver suspeita de comprometimento.
4. Inspecione logs, tarefas agendadas, processos filhos e conexões de saída para atividade pós-exploração.
5. Preserve evidências antes da limpeza se o ambiente já puder estar comprometido.

Ações de endurecimento:

1. Reforce a segmentação de rede em torno do SharePoint ou camadas de aplicativos equivalentes.
2. Coloque o serviço atrás de um proxy reverso, WAF ou controle de filtragem equivalente.
3. Reduza o privilégio da conta de serviço e a capacidade de execução local sempre que possível.
4. Habilite registro centralizado e alertas para requisições suspeitas a /_layouts/15/ToolPane.aspx e caminhos administrativos adjacentes.
5. Monitore a criação inesperada de processos a partir do contexto do worker do aplicativo.

Mitigações específicas para laboratório de pesquisa:

1. Mantenha o laboratório em uma rede de ponte isolada sem publicação de porta do host.
2. Remova o código de execução de comandos do aplicativo simulado, a menos que seja estritamente necessário para uma demonstração controlada.
3. Separe a validação benigna de qualquer funcionalidade perigosa em scripts ou branches diferentes.
4. Evite armazenar listas de alvos positivos, a menos que haja uma necessidade documentada de retenção.
5. Destrua e reconstrua o laboratório após cada exercício.

Aviso Legal

Este README não fornece instruções para explorar sistemas ativos. Ele documenta o repositório como um artefato de pesquisa controlada e descreve práticas mais seguras de validação e mitigação.

Referências

• CVE.org: CVE-2025-53770 - registro CVE canônico com metadados do CNA, faixas de versão afetadas, CVSS e referências vinculadas.
• NVD: CVE-2025-53770 Detail - enriquecimento do NIST, cobertura CPE, mapeamento CWE e agregação de referências.
• Microsoft Security Update Guide: CVE-2025-53770 - aviso principal do fornecedor com impacto, exploração, mitigações e informações de atualização de segurança.
• Microsoft Learn: Configure AMSI integration with SharePoint Server - orientação de endurecimento da Microsoft referenciada pelo aviso do fornecedor para mitigação e validação.
• Microsoft MSRC Blog: Customer guidance for SharePoint vulnerability CVE-2025-53770 - orientação do fornecedor e contexto de resposta para exploração ativa.
• CISA Alert: Microsoft Releases Guidance for Exploitation of SharePoint Vulnerability CVE-2025-53770 - alerta do governo dos EUA e orientação de resposta operacional.
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2025-53770 - confirmação de que a vulnerabilidade foi adicionada ao KEV, juntamente com prazos de remediação e orientações de ação.

Autor

• J4ck3LSyN
• github