.NET Framework Information Disclosure Vulnerability

Falha de divulgação de informação no .NET Remoting (tecnologia legada de comunicação entre processos incluída no .NET Framework) que expõe a URI do ObjRef — um identificador de objeto remoto — a um atacante não autenticado pela rede. Segundo a CISA, essa exposição não é o fim em si: ela serve de peça inicial para viabilizar execução remota de código quando combinada com técnicas de desserialização insegura conhecidas do .NET Remoting. Está no catálogo KEV da CISA com exploração confirmada, e o EPSS extremamente alto (0,986) reflete a existência de PoC pública e template Nuclei circulando.

A vulnerabilidade é classificada como CWE-209 (Generation of Error Message Containing Sensitive Information). O .NET Remoting expõe endpoints (via canais HTTP ou TCP) que referenciam objetos remotos através de um ObjRef — uma estrutura serializada que contém, entre outros dados, o caminho absoluto do objeto e metadados de tipo. A falha permite que um atacante, sem autenticação, force o serviço a revelar essa URI/ObjRef através de uma resposta de erro ou comportamento observável do endpoint, quando normalmente ela deveria ser opaca ao cliente.

O problema não é uma falha de desserialização em si — é a divulgação da informação necessária para montar um ataque de desserialização contra o .NET Remoting. Historicamente, serviços de Remoting configurados com BinaryFormatter e níveis de TypeFilterLevel permissivos são vulneráveis a RCE via objetos maliciosos desserializados; para isso o atacante precisa endereçar corretamente o objeto remoto, o que exige conhecer o ObjRef válido. É exatamente esse dado que a CVE-2024-29059 vaza.

O CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N) reflete só o impacto de confidencialidade direto da CVE — a leitura da URI. O salto para execução de código, mencionado pela CISA, depende de uma segunda etapa de exploração (gadget de desserialização) que não faz parte desta CVE isoladamente, mas do encadeamento com falhas/padrões de configuração já conhecidos no .NET Remoting.

O vetor é de rede, sem autenticação e sem interação do usuário (AC:L, PR:N, UI:N), mas a pré-condição real e limitante é a existência de um serviço .NET Remoting exposto e acessível ao atacante — uma tecnologia legada, hoje pouco usada em aplicações novas, mas ainda presente em sistemas corporativos antigos (ERPs, middlewares, integrações internas) que dependem do .NET Framework 2.0 a 4.8.1. Sem um endpoint de Remoting ativo e alcançável, a CVE não se aplica.

Na prática documentada por pesquisadores e refletida na descrição da CISA, o atacante envia requisições ao serviço de Remoting para provocar a divulgação do ObjRef. Com essa informação em mãos, o passo seguinte — não coberto por esta CVE isoladamente — é montar um payload de desserialização (linha de pesquisa já conhecida contra BinaryFormatter/.NET Remoting) para obter execução de código no contexto do processo que hospeda o serviço.

A presença de PoC pública e de template Nuclei, somada à entrada no KEV (adicionada em 2025-02-04, com prazo de correção definido pela CISA para 2025-02-25 para agências federais dos EUA), confirma exploração ativa. A CISA classifica o status de uso em campanhas de ransomware como 'desconhecido' — não há atribuição a esse tipo de operação até a data da entrada no catálogo.

A Microsoft distribuiu atualização de segurança para as versões afetadas do .NET Framework (2.0 SP2, 3.0 SP2, 3.5, 3.5.1, e as combinações 3.5+4.6/4.6.2, 3.5+4.7.2, 3.5+4.8, 3.5+4.8.1). O canal oficial para identificar o KB/build exato correspondente à sua versão e sistema operacional é o MSRC Update Guide da CVE — as fontes consultadas não trazem os números de build específicos, e não devem ser presumidos.

Quando a atualização não pode ser aplicada de imediato, o controle compensatório mais direto é reduzir a superfície: identificar e desativar serviços .NET Remoting expostos à rede (especialmente em segmentos acessíveis externamente), restringir acesso de rede aos endpoints de Remoting via firewall/segmentação, e migrar aplicações que ainda dependem dessa tecnologia legada para mecanismos de comunicação suportados (WCF, gRPC, APIs REST) — migração que tem custo de engenharia real e não é uma correção imediata.

Não funciona como mitigação apenas atualizar bibliotecas de aplicação sem aplicar a atualização do .NET Framework em si, já que a falha está na camada de Remoting do próprio framework. Também não há indicação nas fontes de que desabilitar apenas o BinaryFormatter, sem tratar a exposição da URI/ObjRef, elimine o vetor de divulgação descrito nesta CVE.

As fontes disponíveis não trazem assinatura de log ou padrão de tráfego confiável específico para esta CVE. Como indício geral, monitorar acesso a endpoints de .NET Remoting (portas/canais HTTP ou TCP customizados usados por essa tecnologia) partindo de origens não confiáveis, e volumes anômalos de erros/exceções nesses serviços, é um sinal a investigar — mas não há confirmação nas fontes de que isso seja suficiente para detectar exploração desta falha especificamente.