CVE-2020-2551

Falha de desserialização insegura no WLS Core Components do Oracle WebLogic Server, explorável sem autenticação via protocolo IIOP. Um atacante com acesso de rede à porta do WebLogic pode comprometer totalmente o servidor sem qualquer interação do usuário ou credencial válida — daí o CVSS 9.8 e a inclusão no catálogo KEV da CISA por exploração confirmada em ambiente real.

A Oracle classificou a falha oficialmente como 'unspecified vulnerability' no componente WLS Core Components, sem detalhar a causa raiz em seu advisory. O vetor de ataque é o protocolo IIOP (Internet Inter-ORB Protocol), que o WebLogic expõe junto com T3 na mesma porta de administração/cluster para comunicação de objetos remotos Java (RMI/CORBA).

Essa CVE pertence a uma família recorrente de falhas do WebLogic (junto com CVE-2020-2555, CVE-2019-2725, entre outras) em que o servidor desserializa objetos Java recebidos via IIOP ou T3 antes de qualquer verificação de autenticação. Quando classes presentes no classpath do WebLogic (incluindo bibliotecas de terceiros empacotadas, como Coherence) contêm métodos exploráveis durante a desserialização — os chamados 'gadgets' —, um objeto malicioso construído pelo atacante pode disparar execução de código arbitrário no momento em que é processado pelo servidor.

O atacante controla o payload serializado enviado na conexão IIOP; o servidor controla apenas a decisão de aceitar e desserializar esse objeto. Não há necessidade de autenticação prévia (PR:N) nem interação do usuário (UI:N), e a complexidade de ataque é baixa (AC:L), o que explica o CVSS máximo em Confidencialidade, Integridade e Disponibilidade.

O pré-requisito real é acesso de rede à porta em que o WebLogic expõe IIOP — normalmente a mesma porta usada para T3/administração, que em muitos ambientes está acessível na rede interna e, em implantações mal segmentadas, exposta diretamente à internet. Não é preciso credencial, token de sessão ou qualquer configuração não padrão além de o listener IIOP estar habilitado, o que é o padrão de fábrica em várias instalações do WebLogic.

A exploração consiste em estabelecer uma conexão IIOP com o servidor e enviar um objeto serializado malicioso que, ao ser processado pela cadeia de desserialização do servidor, aciona execução de código com os privilégios do processo WebLogic — tipicamente o usuário de serviço da aplicação, com acesso a dados de negócio, credenciais de banco configuradas no domínio e, em muitos casos, movimento lateral na rede interna.

Há PoC pública e template Nuclei conhecidos, o que baixa a barreira técnica para quem já tem acesso de rede ao serviço. O registro no catálogo KEV da CISA confirma exploração ativa observada, embora a CISA não classifique esta CVE como associada a campanhas de ransomware conhecidas ('Unknown' no campo correspondente do catálogo).

A correção oficial veio no Critical Patch Update de janeiro de 2020 da Oracle (CPU Jan 2020). A Oracle não publica números de versão pós-patch no formato x.y.z para WebLogic — a correção é distribuída como patch dentro do CPU e deve ser aplicada ao Oracle Home da versão instalada (10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 ou 12.2.1.4.0). Consulte o advisory oficial para identificar o patch/PSU correspondente à sua versão e aplique-o via Oracle Support; a numeração exata do patch não está disponível nas fontes consultadas.

Se a atualização não puder ser aplicada imediatamente, o paliativo real e amplamente adotado nessa família de CVEs do WebLogic é desabilitar o IIOP quando não utilizado pela aplicação (via console de administração, desmarcando 'Enable IIOP' no protocolo do servidor) e, quando possível, também restringir ou desabilitar T3 e bloquear acesso à porta de administração em firewall/segmentação de rede, permitindo apenas origens confiáveis. Esse controle reduz drasticamente a superfície de ataque, mas tem custo: pode quebrar integrações legadas que dependem de IIOP/RMI para comunicação entre servidores WebLogic ou com clientes CORBA.

O que não funciona como mitigação: apenas colocar um proxy HTTP/WAF na frente do WebLogic não protege, porque o ataque ocorre no protocolo IIOP/T3, que normalmente não passa pelo mesmo caminho de um WAF de camada de aplicação web. Segmentação de rede que ainda permite acesso à porta de administração a partir de redes não confiáveis também não mitiga o risco.

Monitorar conexões na porta de administração/cluster do WebLogic (onde IIOP e T3 são expostos) originadas de IPs não confiáveis ou fora da rede de gerência é o sinal mais direto de tentativa de exploração, já que a falha não exige tráfego HTTP e não aparece em logs de aplicação web convencionais. Ferramentas de varredura com o template Nuclei público para esta CVE geram um padrão de conexão IIOP identificável que pode ser correlacionado com IDS/IPS de rede configurados para inspecionar esse protocolo.

Não há um indicador de comprometimento universal e confiável documentado publicamente para esta CVE específica — como a Oracle classificou a falha como 'unspecified', análises de causa raiz publicadas por terceiros são a principal fonte de assinaturas de detecção, e a ausência de logs de aplicação (por não passar por autenticação) dificulta a detecção retroativa em ambientes sem captura de tráfego de rede na porta administrativa.