CVE-2017-10271

Falha de deserialização insegura no componente WLS Security do Oracle WebLogic Server, explorável sem autenticação via requisições HTTP SOAP ao endpoint web service wls-wsat. Permite execução remota de comando com os privilégios do processo WebLogic, o que na prática equivale a comprometimento total do servidor. Está na KEV da CISA, tem exploração massiva documentada desde 2017-2018 (incluindo campanhas de ransomware e mineração de criptomoeda) e CVSS 7.5 — mas o vetor real de exploração amplamente demonstrado é HTTP, não T3 como consta no vetor CVSS oficial da Oracle.

A causa raiz é CWE-502 (Deserialization of Untrusted Data). O componente wls-wsat (WebLogic Web Services Atomic Transactions) expõe endpoints SOAP como /wls-wsat/CoordinatorPortType, /wls-wsat/RegistrationPortTypeRPC, /wls-wsat/ParticipantPortType e variantes '11'. Esses endpoints aceitam um cabeçalho SOAP WorkContext que é processado internamente com java.beans.XMLDecoder — uma classe Java que desserializa XML arbitrário em chamadas de método Java reais, sem qualquer validação de tipo ou whitelist.

Como o atacante controla o corpo XML enviado no header WorkContext, ele pode instanciar classes arbitrárias e invocar métodos, incluindo java.lang.ProcessBuilder com um array de String representando um comando de shell, seguido de .start(). O resultado é execução de comando no sistema operacional subjacente, no contexto do usuário que roda o processo WebLogic (frequentemente com privilégios elevados em instalações padrão).

A descoberta é atribuída a Alexey Tyurin (ERPScan) e Federico Dotta, conforme referenciado no módulo Metasploit. A falha reaparece na família de CVEs relacionadas ao wls-wsat/Async (CVE-2017-3506, CVE-2019-2725, CVE-2019-2729), todas girando em torno do mesmo padrão: desserialização XML não sanitizada em endpoints de web services do WebLogic.

Há uma divergência relevante entre a descrição oficial da Oracle — que classifica o vetor como 'via T3' — e o que pesquisadores e ferramentas de exploração (incluindo o módulo Metasploit e os PoCs públicos) demonstraram: a exploração documentada e replicada em massa usa requisições HTTP POST comuns ao endpoint wls-wsat, não o protocolo T3 binário usado em outras CVEs do WebLogic (como a família de RCE via T3/IIOP de 2018-2020).

O vetor prático é uma requisição HTTP POST não autenticada para /wls-wsat/CoordinatorPortType (ou outro endpoint do console wls-wsat) com Content-Type text/xml, contendo um payload SOAP com header WorkContext malicioso decodificado por XMLDecoder. Não há necessidade de autenticação, sessão prévia ou interação do usuário — só acesso de rede à porta HTTP/HTTPS do console de administração ou do endpoint de serviços web (tipicamente 7001/7002). É por isso que a falha é classificada como 'facilmente explorável': um único request forjado é suficiente.

Existem múltiplos PoCs públicos (incluindo o exploit Python referenciado e o módulo Metasploit 'weblogic_wsat_deserialization_rce'), scanners automatizados para varredura em massa, e templates Nuclei. A exploração real observada desde o fim de 2017 inclui deploy de mineradores de criptomoeda, webshells e, segundo o catálogo KEV da CISA, uso em campanhas de ransomware — a exploração em massa começou dias após a publicação, e continua ocorrendo contra instâncias não corrigidas expostas à internet.

O único pré-requisito real é que o endpoint /wls-wsat esteja acessível pela rede (o que é o caso em praticamente qualquer instalação padrão do WebLogic com o componente Web Services habilitado) e que a versão não tenha o patch da CPU de outubro de 2017 aplicado. Não há necessidade de conhecimento de credenciais, tokens de sessão ou configuração incomum — isso explica por que a exploração em massa foi tão rápida e persistente.

A correção definitiva é aplicar o Critical Patch Update de outubro de 2017 (CPUOct2017) da Oracle para o branch correspondente do WebLogic Server (10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0 ou 12.2.1.2.0), disponível através do suporte Oracle. O advisory oficial não numera uma 'versão corrigida' separada — o modelo de patch da Oracle aplica um patch sobre a versão existente, então a validação de correção deve ser feita verificando se o patch da CPU de outubro/2017 (ou qualquer CPU posterior, que o inclui cumulativamente) foi instalado, não comparando números de versão.

Se o patch não puder ser aplicado imediatamente, o paliativo documentado e amplamente recomendado por analistas é remover ou desabilitar os endpoints wls-wsat (e o pacote de guerra correspondente, geralmente wls-wsat.war) do deployment, já que Web Services Atomic Transactions raramente é necessário em produção. Isso elimina o vetor de ataque sem exigir patch, mas quebra funcionalidade caso a aplicação dependa de transações atômicas de web services — validar antes de remover. Restringir acesso de rede ao console de administração e aos endpoints de web services via firewall/segmentação reduz a superfície, mas não elimina o risco caso o endpoint precise ficar acessível para clientes legítimos.

Não funciona como mitigação: apenas trocar credenciais de administração ou habilitar autenticação no console — a falha não depende de autenticação, então esse controle não fecha o vetor. Também não basta atualizar apenas o WebLogic para uma versão minor sem confirmar a aplicação da CPU específica, pois o versionamento da Oracle não reflete automaticamente todos os patches de segurança aplicados.

Em logs de acesso HTTP do WebLogic, procurar requisições POST para caminhos contendo /wls-wsat/ (CoordinatorPortType, RegistrationPortTypeRPC, ParticipantPortType, RegistrationRequesterPortType e as variantes '11') com Content-Type text/xml ou application/soap+xml, especialmente vindas de IPs não esperados ou em volume de varredura. No corpo da requisição (se houver captura de payload em WAF/IDS), a presença das strings java.beans.XMLDecoder, java.lang.ProcessBuilder, java.net.URL ou javax.naming dentro de um header WorkContext SOAP é indicador direto de tentativa de exploração — payloads legítimos de transação atômica não contêm essas classes.

No host, processos filhos inesperados gerados pelo processo WebLogic (cmd.exe, powershell.exe, /bin/sh) sem relação com a aplicação de negócio são um sinal forte de exploração bem-sucedida. Como a falha é conhecida e escaneada em massa desde 2017/2018, a ausência de sinal não implica ausência de tentativa — ambientes expostos à internet sem esses logs habilitados historicamente não têm visibilidade retroativa.