CVE-2018-2628

Falha de desserialização insegura (CWE-502) no protocolo T3 do Oracle WebLogic Server, que permite a um atacante não autenticado com acesso de rede à porta T3 (7001 por padrão) executar código arbitrário e assumir controle total do servidor. É crítica porque não exige credenciais, não exige interação do usuário e o protocolo T3 costuma estar acessível em ambientes corporativos que expõem WebLogic para integração entre servidores.

O WLS Core Components do WebLogic aceita, via protocolo proprietário T3 (usado para RMI/comunicação entre instâncias), objetos Java serializados enviados pelo cliente sem validação de tipo ou origem antes de desserializá-los. Isso é uma instância clássica de desserialização de dados não confiáveis (CWE-502): o servidor reconstrói objetos a partir de um stream controlado integralmente pelo atacante, e bibliotecas presentes no classpath do WebLogic (Commons Collections e outras, dependendo da versão) contêm cadeias de gadgets que, ao serem reconstruídas, disparam execução de código nativo do sistema operacional.

O fluxo de exploração passa por um handshake T3 inicial (negociação de versão de protocolo) seguido do envio de um objeto serializado malicioso dentro de uma requisição que o WebLogic interpreta como parte da comunicação RMI legítima. O atacante controla integralmente o conteúdo desse objeto — ou seja, controla qual gadget chain é reconstruído e, por consequência, qual comando é executado no contexto do processo do servidor de aplicação.

O Oracle corrigiu a falha original com blacklists de classes no processo de desserialização, mas essa abordagem baseada em lista negra se mostrou incompleta: pesquisadores (caso documentado em análise da 360 ESG Codesafe Team, referenciada no PoC de patch-bypass no Exploit-DB) encontraram cadeias de gadgets alternativas que não estavam bloqueadas, resultando em CVEs subsequentes (como CVE-2018-3245) que contornam a correção original usando a mesma superfície T3.

O vetor é rede pura: o atacante não precisa de conta no WebLogic, apenas de conectividade TCP até a porta onde o listener T3 está exposto (7001 é o padrão, mas pode ser outra). A exploração pública documentada usa a ferramenta ysoserial para gerar o objeto serializado e, em várias variantes, um listener JRMP (via `ysoserial.exploit.JRMPListener`) que serve a cadeia de gadget quando o WebLogic, ao desserializar, tenta resolver uma referência RMI remota — técnica que permite contornar filtros de blacklist ao deslocar o payload malicioso para uma segunda etapa buscada sob demanda.

Existem múltiplos PoCs públicos (Exploit-DB 44553, 46513) e um módulo Metasploit (EDB 45193) com ranking manual, que automatizam o handshake T3, o envio do objeto serializado e a entrega de payload (incluindo variantes PowerShell para alvos Windows). A complexidade técnica de reproduzir o ataque é baixa para quem tem as ferramentas certas — daí o CVSS AC:L — mas construir o PoC do zero sem essas ferramentas exigiria conhecimento de formatos de serialização Java e do protocolo T3.

A CISA confirmou exploração ativa em campo (entrada no catálogo KEV desde setembro de 2022, com prazo de correção definido), e o EPSS extremamente alto (~99,4%) reflete a observação contínua de tentativas de exploração massiva contra hosts WebLogic expostos, um padrão recorrente desde 2018 em campanhas de mineração de criptomoeda e comprometimento inicial de rede corporativa.

A correção oficial da Oracle está no Critical Patch Update de abril de 2018 (cpuapr2018). Aplique esse CPU nas versões afetadas (10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3). Importante: a blacklist de classes usada nessa correção foi posteriormente contornada por pesquisadores usando cadeias de gadget alternativas sobre o mesmo vetor T3 (documentado publicamente, resultando em CVEs subsequentes como CVE-2018-3245); portanto aplicar apenas o patch de abril de 2018 não é suficiente para blindar contra toda a família de falhas de desserialização T3 do WebLogic — é necessário manter o WebLogic atualizado com os CPUs subsequentes da Oracle.

Como paliativo quando a atualização imediata não é viável, a via real de contenção é reduzir a exposição da porta T3: restringir o acesso de rede à porta do listener T3 apenas a hosts confiáveis (firewall/segmentação), já que a exploração exige alcançar essa porta diretamente. Não há mitigação de configuração dentro da própria aplicação WebLogic documentada nas fontes consultadas além do patch oficial — bloqueio de blacklist adicional por conta própria é frágil e não substitui a atualização, dado o histórico de bypass.

Não funciona como mitigação confiável: confiar apenas em WAF de camada HTTP, já que T3 é um protocolo binário próprio, não HTTP — regras de WAF voltadas a tráfego web não inspecionam nem bloqueiam esse canal.

Monitore tráfego destinado à porta do listener T3 (7001 por padrão) partindo de origens não esperadas — a mera presença de conexões T3 de fora da rede de gerência já é um sinal de exposição indevida. No payload, o início característico de um stream de objeto serializado Java (bytes de assinatura 0xACED0005/ACED0005 em hexadecimal) enviado logo após o handshake T3 é um indicador técnico de tentativa de exploração dessa classe de vulnerabilidade, presente em todos os PoCs públicos analisados. Não há um log nativo do WebLogic amplamente citado que sinalize inequivocamente a tentativa antes da execução — a detecção mais confiável depende de inspeção de tráfego de rede (IDS/IPS com assinatura para o protocolo T3 e para o magic bytes de serialização Java) e não da telemetria padrão da aplicação.