CVE-2020-14644

Falha de desserialização insegura (CWE-502) no componente Core do Oracle WebLogic Server, explorável sem autenticação através dos protocolos T3 e IIOP. Um atacante com acesso de rede à porta do WebLogic pode enviar um objeto serializado malicioso que, ao ser desserializado pelo servidor, executa código arbitrário — resultado prático: takeover completo do servidor de aplicação. Está no catálogo KEV da CISA como exploração confirmada em campo, apesar de ter sido corrigida em 2020; isso indica que instâncias não corrigidas continuam sendo alvo até hoje.

O WebLogic Server troca objetos Java serializados durante o handshake dos protocolos T3 (RMI proprietário da Oracle) e IIOP (CORBA), inclusive antes de qualquer autenticação de sessão. Desde 2015 esses protocolos são um vetor recorrente de RCE em WebLogic porque o servidor desserializa dados de entrada usando classes presentes no classpath (incluindo bibliotecas de terceiros como Commons Collections, Coherence, Groovy, etc.), permitindo que gadget chains construam efeitos colaterais arbitrários — de escrita em disco a execução de comando.

A partir de 2018 a Oracle passou a mitigar esse padrão com uma blacklist de classes proibidas na desserialização (filtro estilo JEP 290, implementado em weblogic.rjvm/weblogic.iiop). CVE-2020-14644 pertence à mesma família de CVEs do CPU de julho de 2020 (junto a diversas outras do mesmo boletim) que corrigem novos bypasses dessa blacklist: pesquisadores encontraram classes ainda presentes no classpath do WebLogic que não estavam cobertas pelo filtro e que, encadeadas, reproduzem o efeito das cadeias já bloqueadas anteriormente.

O advisory da Oracle não detalha a gadget chain específica corrigida, e não há um write-up técnico oficial público e definitivo associado apenas a este CVE — ele aparece agrupado com outras correções de desserialização T3/IIOP no mesmo CPU. O ponto central e confirmado é: pré-autenticação, via rede, atingindo o componente Core que processa handshake dos dois protocolos.

O CVSS 3.1 de 9.8 reflete justamente isso: AV:N (rede), AC:L (baixa complexidade), PR:N (sem privilégio), UI:N (sem interação do usuário), com impacto total em confidencialidade, integridade e disponibilidade — porque o resultado é execução de código no contexto do processo WebLogic, geralmente rodando com privilégios elevados no host.

O vetor é rede pura: o atacante só precisa alcançar a porta de listener do WebLogic (T3 tipicamente na porta configurada para o canal, comumente 7001, e IIOP na porta configurada para esse protocolo) e enviar um payload de desserialização durante o handshake do protocolo. Não é necessária autenticação, conta de usuário válida, nem interação de vítima — é isso que torna o CVSS 9.8 realista e não inflado, ao contrário de muitas CVEs 'críticas' que exigem pré-condições incomuns.

A exploração é considerada de baixa complexidade porque a mecânica geral (handshake T3/IIOP + payload serializado) é bem documentada publicamente desde CVEs anteriores da mesma família, existem PoCs públicos circulando e template Nuclei disponível, o que reduz drasticamente a barreira técnica para tentativa de exploração em massa — inclusive por scanners automatizados que testam lotes de IPs expostos.

A presença no catálogo KEV da CISA (adicionada em setembro de 2024, com prazo de correção em outubro de 2024) confirma exploração ativa observada, mesmo a CVE tendo 4 anos na data da inclusão — típico de vulnerabilidades WebLogic antigas que continuam sendo escaneadas e exploradas porque instâncias legadas expostas à internet raramente são atualizadas. O resultado final de um ataque bem-sucedido é execução de código no processo do WebLogic, geralmente usada para implantar webshell, minerador, ransomware ou pivô para a rede interna.

A correção definitiva é aplicar o patch do Critical Patch Update (CPU) de julho de 2020 da Oracle para o ramo afetado (12.2.1.3.0, 12.2.1.4.0 ou 14.1.1.0.0). A Oracle não distribui esse tipo de correção como um novo número de versão simples — o patch é obtido via My Oracle Support como Patch/PSU aplicado sobre a instalação existente do ramo correspondente; não há uma versão '12.2.1.4.x corrigida' isolada divulgada nas fontes consultadas, então confirme o Patch ID correto no CPU de julho/2020 antes de aplicar.

Se não for possível patchear imediatamente, o paliativo historicamente eficaz contra toda a família de CVEs de desserialização T3/IIOP do WebLogic é bloquear o acesso de rede a essas portas: desabilitar o protocolo IIOP no console de administração quando não usado, restringir T3 a hosts confiáveis via connection filters (weblogic.security.net.ConnectionFilterImpl) ou firewall/ACL, e nunca expor a porta do listener administrativo à internet. Esse controle reduz a superfície mas não corrige a causa raiz — qualquer host com acesso à porta ainda está vulnerável.

Não funciona como mitigação: apenas trocar a porta padrão do WebLogic, ou confiar em WAF genérico de camada HTTP — o vetor é o protocolo binário T3/IIOP na camada de socket, não uma requisição HTTP interceptável por regras web comuns. Também não basta atualizar bibliotecas de terceiros isoladamente (ex.: Commons Collections) sem o patch da Oracle, pois o bypass está na cobertura da blacklist do próprio WebLogic, não apenas na presença de uma lib vulnerável específica.

Não há assinatura confiável e única para esta CVE especificamente, porque o payload de exploração varia conforme a gadget chain usada e não há um PoC canônico documentado nas fontes revisadas. Sinais úteis e mais gerais para toda a família T3/IIOP: conexões TCP à porta do WebLogic iniciando com o magic bytes 't3 ' seguido de handshake anômalo vindo de IPs não esperados, processos java do WebLogic gerando processos filhos inesperados (cmd.exe, powershell.exe, sh, bash), gravação de arquivos .jsp/.class em diretórios de deploy fora do fluxo normal de administração, e picos de conexões IIOP/T3 de origem externa quando esses protocolos deveriam estar restritos a hosts internos. Presença de template Nuclei público para esta CVE indica que scanners automatizados a testam ativamente — tráfego correspondente ao padrão do template é um indício direto de tentativa.