Microsoft ignora falha RCE no .NET e joga a culpa nos devs

Em uma decisão que está gerando um debate acalorado na comunidade de segurança, a Microsoft se recusou a corrigir uma vulnerabilidade de execução remota de código (RCE) em seu framework .NET. A falha, detalhada pelo pesquisador de vulnerabilidades Piotr Bazydło, da empresa de segurança watchTowr, durante a conferência Black Hat Europe em 10 de dezembro de 2025, permite que atacantes escrevam arquivos arbitrariamente em sistemas vulneráveis. A justificativa da gigante de Redmond? A responsabilidade é dos desenvolvedores, que não deveriam permitir entradas não confiáveis em suas aplicações. Uma lógica que, para muitos, soa como vender um carro com freios defeituosos e culpar o motorista por não checá-los antes de cada viagem.

O "Recurso" Inesperado do .NET

Vamos dissecar a lógica. O problema reside em uma classe chamada SoapHttpClientProtocol. Pelo nome, a premissa é simples: se uma classe se chama 'SoapHttpClientProtocol', então ela deve lidar com mensagens SOAP transportadas via protocolo HTTP. Direto. Previsível. Seguro. Como Bazydło apontou em um post de blog compartilhado com o The Register, "a realidade é menos cooperativa".

A vulnerabilidade surge porque, apesar do nome, a classe utiliza um método de criação genérico que suporta múltiplos protocolos, incluindo não apenas HTTP/HTTPS, mas também FTP e, crucialmente, FILE. Isso significa que, se um atacante conseguir manipular a URL de destino para apontar para um caminho no sistema de arquivos local (como file:///C:/caminho/para/arquivo.txt) em vez de um endereço web, a classe não gera um erro. Em vez disso, ela 'envia' a requisição SOAP, que usa o método POST, diretamente para o arquivo especificado. Nas palavras do pesquisador: "Espere, o quê? Por que um proxy SOAP deveria ser capaz de 'enviar' requisições SOAP para um arquivo local? Ninguém neste planeta espera receber uma resposta SOAP válida do sistema de arquivos."

Essa funcionalidade inesperada abre a porta para que um invasor escreva arquivos arbitrariamente no sistema, incluindo os dados XML contidos na requisição SOAP. Isso pode ser usado para soltar webshells ASPX, que dão ao atacante controle sobre o servidor, ou para realizar ataques de retransmissão NTLM.

A Lógica da Microsoft: A Culpa é Sua

Quando Piotr Bazydło reportou a falha à Microsoft através da Zero Day Initiative (ZDI) há mais de um ano, a resposta foi, no mínimo, decepcionante. Segundo o pesquisador, "Previsivelmente, a Microsoft tratou o comportamento como um recurso em vez de uma vulnerabilidade. A resposta culpou os desenvolvedores e os usuários."

A lógica da Microsoft é a seguinte: a URL passada para a classe SoapHttpClientProtocol nunca deveria ser controlada pelo usuário, e é responsabilidade do desenvolvedor validar todas as entradas. Bazydło rebateu essa lógica com uma dose de sarcasmo: "Claro, todos os desenvolvedores descompilam regularmente os assemblies do .NET Framework e leem a implementação interna, então eles obviamente sabem que um 'proxy de cliente HTTP' pode ser convencido a escrever dados no sistema de arquivos. Como alguém poderia pensar o contrário?"

A recusa em corrigir a falha cria um precedente perigoso, transferindo todo o ônus da segurança para os desenvolvedores que utilizam o framework, mesmo quando o comportamento de um componente é contraintuitivo e não documentado.

Exploração na Prática: De Ivanti a Umbraco

Um ano após a primeira recusa, a equipe da watchTowr encontrou um segundo vetor de exploração enquanto investigava o Barracuda Service Center, uma plataforma de RMM. Eles descobriram que era possível explorar a falha através da importação de arquivos WSDL (Web Services Description Language). Um atacante poderia fornecer uma URL para um arquivo WSDL malicioso sob seu controle, fazendo com que a aplicação vulnerável gerasse um proxy de cliente HTTP que poderia ser abusado.

Usando essa técnica, os pesquisadores demonstraram a execução remota de código com sucesso em produtos de grande escala, como o Ivanti Endpoint Manager e o Umbraco 8 CMS. Eles conseguiram fazer upload de webshells CSHTML ou scripts PowerShell através do namespace do corpo da requisição SOAP. Bazydło ressalta que a lista de produtos afetados é apenas "anecdótica" e que, dada a ampla utilização do .NET, "existem, sem dúvida, inúmeras soluções de fornecedores e internas afetadas".

Quando a watchTowr reportou este segundo caminho de exploração para a Microsoft em julho, a resposta foi praticamente idêntica. Mesmo quando o problema foi reportado no contexto de produtos da própria Microsoft que também estavam vulneráveis, a empresa dobrou a aposta: a culpa é do usuário. "Os usuários devem evitar consumir entradas não confiáveis que possam gerar e executar código", afirmou a empresa. A ironia não passou despercebida por Bazydło: "Então, primeiro culpamos a aplicação. Se isso não for uma opção, porque exigiria consertar o próprio código da Microsoft, culpamos o usuário... Suspiro."

A Batata Quente da Responsabilidade

A decisão da Microsoft joga uma batata quente no colo de todo o ecossistema .NET. A questão fundamental que emerge deste caso é sobre a responsabilidade compartilhada na segurança de software. É lógico esperar que um desenvolvedor antecipe que um componente projetado para HTTP possa escrever em arquivos locais? Ou a empresa que fornece o framework tem a obrigação de projetar componentes seguros por padrão e com comportamentos previsíveis?

Enquanto a Microsoft se mantém firme em sua posição de que isso é um 'recurso' e a culpa é de quem o usa incorretamente, milhares de aplicações corporativas podem permanecer vulneráveis. Para os desenvolvedores, fica o aviso: ao usar o .NET, a validação de cada entrada não é apenas uma boa prática, é uma necessidade absoluta para evitar que um 'cliente HTTP' decida se tornar um 'escritor de arquivos' sem pedir permissão.