CVE-2020-2555

Falha de deserialização insegura (CWE-502) no componente Caching/CacheStore/Invocation do Oracle Coherence, dentro do Oracle Fusion Middleware, explorável remotamente e sem autenticação via protocolo T3. Como o Coherence é distribuído embutido em outros produtos Oracle (WebLogic, Utilities Framework, Retail Assortment Planning, Commerce, Communications DSR), o alcance real da falha é maior do que a listagem original sugere, e a CISA a mantém no catálogo KEV por exploração confirmada em campo com RCE completo.

A falha está no processamento de objetos Java serializados recebidos por endpoints Coherence expostos via protocolo T3 (o mesmo protocolo RMI-like usado por WebLogic para comunicação entre servidor e cliente). O serviço desserializa dados de entrada sem validar a classe antes de instanciá-la, permitindo que um atacante envie um payload serializado contendo uma cadeia de gadgets (classes presentes no classpath da aplicação, incluindo bibliotecas de terceiros comumente empacotadas com Coherence/WebLogic) que, ao serem reconstruídas pela JVM, disparam execução de código arbitrário antes de qualquer checagem de autorização.

O atacante não controla lógica de negócio diretamente — controla o conteúdo do stream serializado enviado à porta T3. Não há autenticação nem interação do usuário envolvida (PR:N, UI:N no vetor CVSS), e a exploração não depende de configuração exótica: basta a porta T3 (ou, em algumas variantes documentadas pela CISA, HTTP) estar acessível na rede para o serviço vulnerável.

A descrição oficial da Oracle cita apenas Oracle Coherence (versões 3.7.1.0, 12.1.3.0.0, 12.2.1.3.0 e 12.2.1.4.0), mas a entrada da CISA no KEV amplia o escopo prático para Oracle Utilities Framework, Oracle Retail Assortment Planning, Oracle Commerce e Oracle Communications Diameter Signaling Router (DSR) — todos consomem a mesma biblioteca Coherence vulnerável internamente.

O vetor é rede direta: o atacante envia um payload serializado malicioso para a porta T3 exposta pelo componente Coherence (ou pelo WebLogic que o empacota). Não é necessário nenhum tipo de credencial, sessão prévia ou interação humana — o processo de desserialização ocorre no handshake/protocolo antes de qualquer verificação de identidade, o que explica a facilidade de exploração (AC:L) e o score 9.8.

O pré-requisito real que reduz o risco em ambientes bem segmentados é a exposição da porta T3 (tipicamente 7001/7002 em instalações WebLogic, ou portas específicas de Coherence) à rede do atacante. Em ambientes onde essa porta está restrita a uma rede interna de gerenciamento, a superfície de ataque cai drasticamente mesmo que o software esteja desatualizado.

A CISA confirma exploração ativa (presença no catálogo KEV desde novembro/2021) e existem módulo Metasploit e provas de conceito públicas, incluindo writeups técnicos (PacketStorm) descrevendo a cadeia de RCE via desserialização no WebLogic/Coherence. Isso indica que scanners automatizados e ferramentas de exploração em massa já incorporam este CVE — não é um ataque de nicho, é tráfego de varredura oportunista comum na internet.

A correção definitiva é aplicar o patch da Critical Patch Update (CPU) de janeiro de 2020 da Oracle, que trata esta CVE no Oracle Fusion Middleware/Coherence, e as CPUs subsequentes (julho/2020, janeiro/2021, julho/2021) que reaplicam a correção para os demais produtos afetados (Utilities Framework, WebCenter Portal, Retail Assortment Planning, Commerce, Communications DSR). As fontes disponíveis não especificam números de versão de build corrigidos além dos advisories da CPU — o procedimento correto é consultar o advisory da CPU correspondente ao produto específico instalado e aplicar o patch listado para a sua combinação de versão/plataforma.

Como controle compensatório quando o patch não pode ser aplicado imediatamente, restringir o acesso à porta T3 (e a outras portas de gerenciamento Coherence/WebLogic) apenas a hosts de administração confiáveis via firewall ou segmentação de rede reduz a exploração a atacantes já dentro do perímetro. A própria Oracle historicamente recomendou desabilitar o protocolo T3 quando não utilizado, ou restringi-lo, como mitigação para esta família de vulnerabilidades de deserialização.

Não funciona como mitigação: apenas trocar a porta padrão do T3, ou confiar em obscuridade de rede sem controle de acesso real — scanners de exploração testam portas não padrão e o protocolo é identificável pela assinatura do handshake. Da mesma forma, WAFs genéricos de camada 7 tendem a não inspecionar tráfego T3 (binário, não HTTP), então proteção de borda HTTP não cobre a maior parte dos vetores desta CVE.

Não há assinatura de detecção confiável documentada nas fontes apuradas especificamente para esta CVE. Como indicador geral de tentativas de exploração de deserialização via T3, vale monitorar conexões de rede à porta T3 (ou HTTP, conforme nota da CISA) originadas de IPs não administrativos, e inspecionar payloads binários com cabeçalho de protocolo T3 seguido de streams de objeto Java serializado (assinatura 0xAC 0xED) contendo nomes de classe associados a cadeias de gadget conhecidas. A presença de módulo Metasploit e PoCs públicas sugere que scanners de rede em massa geram tráfego de sondagem contra a porta T3 sem necessariamente completar a exploração — esse tráfego de sondagem por si só já é sinal de interesse ativo no alvo.