CVE-2018-2380

Vulnerabilidade de path traversal (CWE-22) no console administrativo de logging do SAP CRM (componente ISA B2B, rodando sobre SAP NetWeaver AS Java), que permite a um usuário já autenticado como administrador reconfigurar o destino de um arquivo de log para um caminho arbitrário dentro do sistema de arquivos, incluindo diretórios de deploy de aplicações web. O CVSS 6.6 soa modesto, mas pesquisadores demonstraram que a falha é encadeada com injeção de conteúdo no log para gravar um web shell JSP e obter execução remota de código — o impacto real é bem maior do que a nota sugere.

O parâmetro que define o destino do arquivo de log na tela /b2b/admin/logging.jsp (campo selDest) não valida sequências de travessia de diretório nem impede caminhos absolutos. Um atacante com sessão administrativa consegue apontar o log para qualquer local gravável pelo processo Java do NetWeaver, incluindo o diretório de deploy de aplicações (cluster/apps/sap.com/.../servlet_jsp/_default/root), efetivamente contornando o isolamento que deveria manter os logs em um diretório fixo controlado pelo servidor.

O segundo elemento da cadeia é injeção de log: como o mecanismo de logging grava no arquivo qualquer texto recebido em determinado parâmetro de requisição (visto no PoC via /b2b/init.do), o atacante consegue controlar o conteúdo escrito no arquivo, não só o caminho. Combinando os dois — caminho controlado + conteúdo controlado — é possível criar um arquivo .jsp válido dentro da área servida pela aplicação, com código Java arbitrário (por exemplo Runtime.getRuntime().exec()), pronto para ser executado ao ser acessado via HTTP.

O vetor CVSS informado (PR:H, S:C) reflete a exigência de privilégio administrativo prévio e o escopo alterado (Scope Changed), já que o impacto extrapola o componente vulnerável e chega ao runtime do servidor de aplicação. As classificações de impacto C:L/I:L/A:L no vetor não capturam bem o resultado prático demonstrado publicamente, que é execução de código no contexto do processo Java do NetWeaver — o que na prática equivale a comprometimento total do sistema.

O pré-requisito central, e o mais frequentemente ignorado ao ler apenas a manchete, é acesso autenticado com privilégio administrativo ao console /b2b/admin do módulo ISA (Internet Sales) do SAP CRM — não é uma falha pré-autenticação. O PoC público (ERPScan, também disponível no Exploit-DB) automatiza a cadeia completa: obtém o token de sessão (j_salt), autentica com credenciais de administrador, reconfigura o destino do log via logging.jsp para um caminho dentro do diretório de aplicações do cluster J2EE, injeta um payload JSP através de uma requisição para /b2b/init.do, e por fim restaura o caminho original do log para reduzir vestígios.

Depois de escrito o arquivo .jsp malicioso, o atacante o acessa diretamente por HTTP(S) na porta do NetWeaver AS Java, executando comandos do sistema operacional com os privilégios do processo do servidor de aplicação — controle total sobre o host, não apenas sobre dados do CRM.

A vulnerabilidade está no catálogo KEV da CISA com confirmação de exploração ativa (adicionada em novembro de 2021, prazo de correção maio de 2022), o que indica campanhas reais usando essa cadeia contra instâncias SAP expostas — historicamente comum em ambientes SAP legados acessíveis pela internet ou por redes internas insuficientemente segmentadas, onde credenciais administrativas padrão ou fracas facilitam a etapa de autenticação prévia.

Aplicar a correção da SAP referenciada na SAP Security Note 2547431 (SAP Security Patch Day de fevereiro de 2018) é a mitigação definitiva. A nota exige acesso ao SAP Support Portal para obter o patch exato por versão; a numeração de build específica não foi coletada nesta pesquisa e não deve ser presumida — confirme junto ao Launchpad da SAP a versão de correção aplicável ao seu Support Package.

Como controle compensatório enquanto o patch não é aplicado: restringir o acesso à interface /b2b/admin a redes de gerência e IPs confiáveis (VPN/jump host), remover ou desabilitar contas administrativas padrão e reforçar a política de credenciais dos usuários com acesso a esse console, já que a exploração depende inteiramente de uma sessão administrativa válida. Monitorar e restringir permissões de escrita do processo Java do NetWeaver sobre os diretórios de deploy de aplicações reduz o impacto mesmo que a etapa de path traversal seja bem-sucedida.

Não funciona como mitigação: WAF genérico bloqueando apenas sequências clássicas de "../" no campo selDest, pois o vetor documentado usa caminho absoluto (ex.: C:\usr\sap\...), não necessariamente travessia relativa — um filtro que só procura "../" não impede o ataque demonstrado publicamente. Restringir a exposição externa do NetWeaver também não resolve o risco de um insider ou de uma conta administrativa comprometida por outra via (phishing, reuso de senha).

Nos logs de acesso HTTP do NetWeaver AS Java, procurar requisições POST para /b2b/admin/logging.jsp com o parâmetro selDest contendo caminhos absolutos fora do diretório padrão de logs (especialmente apontando para subdiretórios de cluster/apps/.../servlet_jsp/_default/root), e requisições subsequentes para /b2b/init.do com strings incomuns em parâmetros de query (indicativas de payload Java/JSP). Também vale auditar o diretório de deploy de aplicações por arquivos .jsp criados fora do processo normal de deployment, com nomes aleatórios (padrão observado no PoC: prefixo tipo "ERPScan_shell_" seguido de número), e revisar logins administrativos no console /b2b/admin fora do padrão de uso operacional. Não há assinatura de rede única e confiável, pois o payload de exploração pode variar livremente — a ausência de tentativas visíveis não garante que o sistema não tenha sido comprometido antes da instrumentação de logging estar em vigor.