Missing Authorization check in SAP NetWeaver (Visual Composer development server)

Falha de upload de arquivo sem restrição (CWE-434) no componente Visual Composer do SAP NetWeaver, especificamente no endpoint /developmentserver/metadatauploader, que aceita uploads sem qualquer verificação de autenticação. Um atacante remoto sem credenciais pode depositar um webshell JSP executável e obter execução de código completa no servidor. É crítica de verdade: CVSS 10.0, está na KEV da CISA com exploração confirmada em massa desde pelo menos março de 2025, e afeta um componente historicamente habilitado em muitos ambientes SAP mesmo sem uso ativo.

O Visual Composer é um framework do NetWeaver usado por especialistas de processo de negócio para montar componentes de aplicação sem programar. Parte dessa funcionalidade é o Metadata Uploader, um servlet exposto no path /developmentserver/metadatauploader, que deveria exigir autenticação e autorização antes de aceitar arquivos. O problema é que essa verificação simplesmente não existe (ou é insuficiente) nessa versão do componente — qualquer requisição HTTP não autenticada consegue enviar um arquivo para o servidor.

O atacante controla o conteúdo e, em grande medida, o caminho de destino do arquivo enviado. Na exploração observada, o payload é um webshell JSP colocado em um diretório publicamente acessível do servidor de aplicação Java. Como o servidor de aplicação interpreta arquivos .jsp automaticamente, basta uma requisição GET subsequente para o arquivo enviado para disparar execução de código arbitrário no contexto do processo NetWeaver — sem exploit de memória, sem bypass de autenticação elaborado, só abuso de uma funcionalidade legítima de upload que não checa quem está chamando.

Em 13 de maio de 2025, pesquisa da Onapsis levou a SAP a publicar a Nota de Segurança 3604119, referente à CVE-2025-42999 (CVSS 9.1, deserialização insegura), que a fabricante descreve como a correção da causa raiz por trás da exploração de CVE-2025-31324. Ou seja: o problema de autorização ausente no upload é a porta de entrada, mas a cadeia completa de comprometimento observada em campo envolve também esse segundo componente, corrigido separadamente.

O Visual Composer não vem instalado por padrão em toda instalação NetWeaver, mas historicamente foi habilitado com frequência porque era peça central do desenvolvimento low-code de componentes de aplicação — daí a superfície de exposição real ser maior do que o nome do componente sugere.

O vetor é HTTP direto contra o endpoint exposto: nenhuma autenticação, nenhuma interação de usuário, nenhuma configuração fora do padrão além de ter o Visual Composer habilitado e acessível na rede (incluindo, em muitos casos, exposto à internet). A ReliaQuest documentou múltiplos clientes comprometidos via upload não autorizado de arquivos, com os atacantes depositando webshells JSP em diretórios públicos e então executando comandos via requisições GET simples ao navegador — sem exigir ferramentas sofisticadas na etapa inicial.

A Onapsis, analisando amostras capturadas em sua rede de sensores, reconstruiu ataques mostrando execução remota de comando completa: comandos RCE foram usados na fase de reconhecimento e os webshells vieram depois, via RCE, não como primeiro passo. Na fase pós-exploração, atores foram vistos usando a ferramenta de red team Brute Ratel, a técnica de evasão Heaven's Gate e injeção de código compilado com MSBuild dentro de dllhost.exe para persistência furtiva — sinal de operador com conhecimento avançado de ambientes SAP, não script kiddie.

Houve exploração massiva e sustentada: reconhecimento identificado entre 20/jan e 10/fev de 2025, exploração ativa relatada por múltiplas IR firms a partir de meados de março, divulgação pública em 22/abr pela ReliaQuest, patch de emergência da SAP em 24/abr, e a CISA adicionou a falha ao catálogo KEV em 29/abr com prazo de correção em 20/mai. A partir de 30/abr, a Onapsis observou uma segunda onda de atacantes oportunistas reutilizando webshells deixados pelo grupo original, que havia sumido — ou seja, mesmo sistemas nunca diretamente alvo do ataque inicial ficaram expostos a quem reaproveitou o acesso já estabelecido.

A correção definitiva é aplicar a SAP Security Note 3594142 (patch de emergência liberado em 24/04/2025, fora do ciclo normal de Patch Day — quem aplicou apenas a atualização regular de abril de 2025, de 08/04, continua vulnerável). A SAP recomenda também aplicar a Nota 3604119 (13/05/2025), referente à CVE-2025-42999, descrita como correção da causa raiz da cadeia de exploração observada em campo.

Se o patch não puder ser aplicado imediatamente, restrinja o acesso ao endpoint /developmentserver/metadatauploader (rede ou proxy reverso) e, se o Visual Composer não estiver em uso ativo, desative o componente inteiramente — esse é o paliativo mais robusto. Atenção: em 12/05/2025 a própria SAP deprecou as mitigações 1 e 2 da Nota 3593336, marcando-as explicitamente como 'Do Not Use' — quem aplicou esses workarounds anteriores precisa revisitar a postura de segurança desses sistemas e priorizar a Opção 0 (o patch real), porque as mitigações alternativas não são mais consideradas suficientes pelo fornecedor.

Antes ou depois de patchear, é essencial varrer o caminho do servlet por arquivos suspeitos (webshells JSP) e revisar logs de acesso a esse endpoint — sistemas já comprometidos continuam vulneráveis a reexploração e reaproveitamento por atores secundários mesmo após a correção do bug original, se o webshell não for removido.

Procure por requisições HTTP (GET/POST) direcionadas ao path /developmentserver/metadatauploader nos logs do servidor de aplicação Java do NetWeaver, especialmente originadas de IPs externos ou não corporativos. Varra os diretórios do servlet path por arquivos .jsp não reconhecidos ou recém-criados fora do processo normal de deploy — esse é o indicador mais direto de comprometimento, já que os webshells foram depositados em diretórios publicamente acessíveis. Em ambientes já comprometidos, procure também por indícios pós-exploração citados pela Onapsis: presença do Brute Ratel, uso da técnica Heaven's Gate, e código injetado via MSBuild dentro do processo dllhost.exe — sinais de que a exploração avançou além do upload inicial para persistência mais furtiva.