dungsocool/cve-2017-10271Guia de laboratório passo a passo para explorar o CVE-2017-10271 (desserialização RCE do WebLogic XMLDecoder) com construção manual de payload, bypass de RCE cego e técnicas de pós-exploração, incluindo verificação de privilégios e exfiltração de dados.
AdminServer pertencente ao base_domain rodando em Development Mode).7001.http, t3, iiop, ldap, snmp.t3 na porta 7001. Essa configuração padrão apresenta alto risco se a versão do WebLogic não estiver corrigida contra vulnerabilidades relacionadas à desserialização de objetos Java via RMI (Remote Method Invocation).http na porta 7001, o que a torna suscetível à varredura de diretórios em busca de endpoints sensíveis como /console/login/LoginForm.jsp.Uma vez identificadas as portas abertas do alvo, usaremos o nmap para escanear a porta e determinar o serviço em execução.
Assim, o alvo está executando um serviço HTTP com a versão Oracle WebLogic Server 10.3.6.0 — um conhecido servidor de aplicações Java empresarial, famoso por uma série de CVEs críticas (como desserialização, bypass de autenticação). No entanto, essa informação por si só não é suficiente para concluir a qual vulnerabilidade específica o sistema está suscetível. Precisamos escanear mais profundamente os componentes de serviço web que o acompanham.
Vamos prosseguir para identificar seus endpoints sensíveis usando a ferramenta dirsearch. Como o WebLogic roda na plataforma Java, arquivos .jsp e .xml são os alvos mais sensíveis. Vamos nos concentrar nos endpoints que retornam o código de status 200.
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp: O portal de login da interface web do Console de Administração do WebLogic. Este é um alvo importante para cenários de força bruta com credenciais padrão ou vulnerabilidades de bypass de autenticação (como CVE-2020-14882)./bea_wls_internal/: O diretório padrão de aplicações web internas do WebLogic Server. Este componente permite o acesso e a interação com arquivos de sistema estáticos./wls-wsat/CoordinatorPortType: Esta é a descoberta mais crítica. A presença deste caminho com o código de status 200 OK confirma que o componente Web Services Atomic Transactions (wls-wsat) está habilitado e pronto para receber dados./uddiexplorer e /uddi/uddilistener: Este é o componente UDDI Explorer (Universal Description, Discovery, and Integration) integrado por padrão no WebLogic Server para gerenciar e registrar Web Services. Este componente é extremamente famoso pela vulnerabilidade SSRF (Server-Side Request Forgery) - CVE-2014-4210. Um atacante pode explorar a interface pública de pesquisa de registros do UDDI no endpoint /uddiexplorer/SearchPublicRegistries.jsp para forçar o servidor WebLogic a enviar requisições HTTP arbitrárias para a rede interna do backend.⇒ Pensamento: A coexistência de /wls-wsat (risco de RCE via XMLDecoder) e /uddiexplorer (risco de SSRF) indica que a superfície de ataque deste servidor WebLogic é extremamente ampla.
Após identificar duas superfícies de ataque independentes coexistindo no servidor WebLogic 10.3.6.0, analisamos as duas direções:
/uddiexplorer:
/wls-wsat:
⇒ Decisão: No modelo de Cyber Attack Chain, RCE é sempre o objetivo final porque fornece controle direto e completo do sistema (Full System Compromise). Uma vez obtida a capacidade de RCE, explorar SSRF através do aplicativo UDDI torna-se redundante. Isso porque, a partir de um shell RCE, podemos realizar consultas na rede interna de forma ativa, direta, flexível e mais poderosa (usando comandos do sistema como curl, wget) sem estarmos restritos pelos parâmetros da interface UDDI.
Portanto, em termos de lógica de priorização de exploração, decidimos excluir o caminho secundário (SSRF em /uddiexplorer) e focar inteiramente na pesquisa: Execução Remota de Código (RCE) via vulnerabilidade de Desserialização XMLDecoder em /wls-wsat/CoordinatorPortType.
A vulnerabilidade raiz da CVE-2017-10271 ocorre porque a classe WorkContextXmlInputAdapter do WebLogic usa o objeto java.beans.XMLDecoder para analisar dados na tag <work:WorkContext>. Por padrão, essa classe XMLDecoder instancia automaticamente qualquer classe Java definida na forma de tags XML. A partir daqui, realizamos verificação baseada na interação comportamental do sistema, passo a passo.
Para verificar rapidamente o status ativo real deste servlet, envie uma requisição HTTP GET comum de sondagem:
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
A resposta retorna HTTP/1.1 200 OK juntamente com a classe de implementação CoordinatorPortTypePortImpl, confirmando que o servlet foi carregado com sucesso na memória da JVM.
Como os servlets de Web Services são projetados para processar dados XML SOAP através do método POST, prosseguimos com testes comparativos usando duas requisições POST para demonstrar o pipeline de processamento de dados do sistema:
1. Requisição POST SOAP Padrão
Enviamos um Envelope XML SOAP padrão (com namespaces completos, mas sem conteúdo de execução) para testar a capacidade normal de parsing do parser.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method).Análise:
O servidor possui um leitor XML funcionando corretamente na porta POST, pronto para receber e decodificar toda a estrutura de árvore XML enviada pelo usuário. Isso confirma que o pipeline de dados do cliente até a memória do WebLogic está totalmente operacional.
2. Requisição POST com XML Malformado
Em seguida, quebramos intencionalmente a estrutura XML (por exemplo, omitindo namespaces) para observar o mecanismo de tratamento de exceções do parser.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"