CVE-2010-5326

Falha de controle de acesso no Invoker Servlet do SAP NetWeaver Application Server Java: esse componente permite invocar diretamente classes Java/EJB do servidor via URL, sem passar pelas checagens de autenticação e autorização definidas normalmente em web.xml. O resultado é execução remota de código por um atacante não autenticado, apenas com acesso HTTP(S) ao sistema. A CVE foi publicada só em 2016, seis anos depois da SAP ter emitido a correção (2010), porque pesquisadores da Onapsis encontraram evidências de exploração ativa contínua entre 2013 e 2016 contra pelo menos 36 organizações — o que motivou o alerta TA16-132A do US-CERT e, mais tarde, a inclusão no catálogo KEV da CISA.

O Invoker Servlet é um recurso legado do SAP NetWeaver AS Java que permite chamar qualquer classe/método exposto na aplicação através de uma URL construída dinamicamente, sem que essa rota passe pelos mapeamentos de segurança declarados no deployment descriptor da aplicação. Isso é uma falha de controle de acesso ausente (CWE-306/CWE-284): o servlet ignora as restrições de autenticação e autorização configuradas pelo desenvolvedor, porque a invocação acontece por um caminho de despacho diferente do que os filtros de segurança da aplicação esperam interceptar.

O atacante controla o caminho da URL, que codifica o nome da classe e do método a ser invocado no lado do servidor. Se qualquer classe sensível estiver acessível pelo classpath da aplicação — administração de usuários, execução de comandos, manipulação de arquivos, componentes de aplicações de negócio SAP como ERP, CRM, BW, PI/XI, Solution Manager, entre outros citados pela SAP e pela Onapsis — o atacante pode acioná-la diretamente, sem sessão, sem credenciais e sem passar pela lógica de autorização da aplicação.

A gravidade não vem de um bug de memória ou de injeção clássica: é um desenho de funcionalidade que expõe, por padrão, uma superfície de invocação irrestrita sobre a camada de aplicação Java do NetWeaver, que serve de base para praticamente toda a pilha de produtos de negócio da SAP. Por isso o impacto declarado pelo fornecedor e por pesquisadores é controle administrativo total do sistema, e potencialmente de sistemas conectados via interfaces de confiança SAP.

O vetor é uma requisição HTTP ou HTTPS comum contra o servidor NetWeaver AS Java com o Invoker Servlet habilitado — que era o comportamento padrão em versões anteriores à correção. Não é necessário usuário SAP válido, sessão autenticada ou qualquer configuração fora do padrão além de o servlet estar ativo (o que, segundo a Onapsis, era e continuava sendo comum em sistemas não corrigidos ou com a configuração revertida). Segundo a Onapsis, basta um navegador web e o hostname/IP do sistema alvo para iniciar a exploração.

A Onapsis documentou, a partir de 2016, indicadores de exploração dessa falha datados de 2013 em um fórum público registrado na China, afetando pelo menos 36 organizações globais de grande porte. Não há evidência de atribuição a um grupo específico ou a atividade estatal — os pesquisadores enfatizam que não fazem essa correlação. A falha está no catálogo KEV da CISA desde novembro de 2021 (prazo de correção definido para maio de 2022), o que confirma exploração ativa reconhecida por agência federal, embora não conste como usada em campanhas de ransomware conhecidas.

O resultado prático da exploração é acesso administrativo completo à aplicação SAP afetada — controle sobre dados de negócio, processos e, dependendo da topologia de integração, possível salto para sistemas SAP e não-SAP conectados por relações de confiança.

A correção do fornecedor é a SAP Security Note 1445998, publicada em 2010, que orienta desabilitar o Invoker Servlet globalmente (não é um patch binário de versão, é uma alteração de configuração no servidor de aplicação). Isso é o paliativo real e a mitigação recomendada tanto pela SAP quanto pelo US-CERT/CISA. O custo dessa mitigação: aplicações customizadas que dependem do mecanismo de invocação direta via Invoker Servlet param de funcionar, exigindo revisão e ajuste dessas aplicações antes de desabilitar o recurso em produção.

Como a vulnerabilidade já tinha correção disponível desde 2010 e mesmo assim foi explorada ativamente até 2016, o problema real relatado pelos pesquisadores não é ausência de patch, mas sistemas que nunca aplicaram a nota de segurança ou que tiveram a configuração revertida/nunca definida corretamente — inclusive em ambientes de nuvem pública, privada ou híbrida. Não confie apenas em auditorias antigas: é necessário verificar ativamente, no sistema em produção, se o parâmetro que desabilita o Invoker Servlet está de fato aplicado, e não apenas assumir que 'já foi corrigido há anos'.

Não há mitigação eficaz via WAF genérico documentada nas fontes — a falha opera na camada de despacho de servlets da aplicação, não em um padrão de payload HTTP facilmente filtrável sem conhecimento profundo da topologia de classes expostas.

As fontes não trazem uma assinatura de rede ou padrão de log oficialmente publicado para essa exploração específica. O indício mais concreto citado pela Onapsis é a observação de indicadores de comprometimento durante engajamentos de forense e resposta a incidentes em clientes SAP, combinados com resultados de scans que identificam o Invoker Servlet habilitado — ou seja, a detecção prática depende de auditoria de configuração do próprio sistema (verificar se o servlet está ativo) somada a análise de logs de acesso HTTP por padrões de URL que invocam classes fora do fluxo normal da aplicação, e de auditoria de usuários e autorizações por atividade anômala. Não há indicador de rede único e confiável descrito nas fontes analisadas.