Unpatched .NET RCE Flaw Lets Attackers Write Files via SOAP—Microsoft Blames Developers
Security researchers have disclosed a .NET vulnerability that could affect a wide range of enterprise products and lead to remote code execution. The issue stems from how Microsoft .NET–based applications process SOAP messages, and, according to the researchers, Microsoft has declined to fix it, shifting responsibility instead to developers and end users.
The finding was presented at Black Hat Europe by Piotr Bazydło of watchTowr. He explained that numerous commercial and in-house solutions are exposed to remote code execution (RCE) attacks due to flaws in SOAP message handling within .NET applications.
At the heart of the issue lies the SoapHttpClientProtocol class. Bazydło noted that attackers can abuse this class in multiple ways depending on their objectives. While it inherits from HttpWebClientProtocol like other client proxies, SoapHttpClientProtocol appears far more frequently in real-world codebases, which is why watchTowr focused its analysis on it.
On paper, everything appears innocuous. Both the class name and the official documentation suggest it is meant to handle SOAP messages over HTTP—a “simple, predictable, and safe” use case, as Bazydło remarks with irony. In practice, however, the reality is far more complex.
The class is responsible for setting the target URL of a SOAP service and invoking SOAP methods. The vulnerability emerges when an attacker can influence this URL and the way SoapHttpClientProtocol instantiates the client. Although it is ostensibly designed for HTTP requests, under the hood it relies on a generalized mechanism that supports multiple protocols, including HTTP/HTTPS, FTP, and even FILE.
If an attacker supplies a URL pointing to the local file system instead of a web address, the class does not raise an error. Instead, it quietly writes the SOAP request—sent via POST—directly to a file. “Why should a SOAP proxy ever ‘send’ requests to a local file? No sane person expects to receive a valid SOAP response from a file system,” Bazydło observes.
This behavior can be abused for arbitrary file writes, including writing XML data from SOAP requests. Less destructive, yet still problematic, scenarios include NTLM relay attacks.
Bazydło initially reported the issue to Microsoft through the Zero Day Initiative (ZDI). According to him, Microsoft responded that it would not address the bug, arguing that developers should never allow untrusted input in the first place.
“Predictably, Microsoft classified this as a ‘feature’ rather than a vulnerability,” he writes. “The response blamed developers and users. According to Microsoft, the URL passed to SoapHttpClientProtocol should never be user-controlled, and input validation is entirely the developer’s responsibility.”
Bazydło adds, with biting sarcasm, that of course “all developers regularly decompile .NET Framework assemblies and study their internal implementation, fully aware that an ‘HTTP client proxy’ can be coerced into writing data to disk. How else could it be?”
A year later, the watchTowr team analyzed Barracuda Service Center, described as a “widely used RMM platform,” and found it vulnerable to the same technique. Researchers discovered that its SOAP API could be invoked without authentication and then identified an alternative exploitation path via the import of WSDL (Web Services Description Language) files.
In this scenario, an attacker supplies a URL pointing to a WSDL file under their control. The vulnerable application generates an HTTP client proxy based on that description, after which Bazydło demonstrated remote code execution in two ways: by uploading an ASPX web shell to the server, or by embedding a payload—such as a CSHTML web shell or a PowerShell script—within the namespace of the SOAP request body.
According to Bazydło, this namespace-based technique was successfully used to exploit Ivanti Endpoint Manager and Umbraco CMS 8. While these products are explicitly named in the watchTowr report, the researchers stress that the true list of affected solutions is far broader.
“Given the scale of .NET adoption and the fact that there are only 24 hours in a day, our list of affected products should be seen as illustrative,” Bazydło concludes. “It is almost certain that many other commercial and internal systems are vulnerable as well.”
The second exploitation vector, involving WSDL, was reported to Microsoft in July. The response, the researchers say, was nearly identical to the one received a year earlier: once again, Microsoft asserted that users were at fault for consuming untrusted data.
A similar reaction followed subsequent reports concerning Microsoft’s own products exhibiting the same behavior. In an official statement, the company said that while the issue relates to application behavior, “users should avoid consuming untrusted data that could lead to code generation and execution.”
Bazydło does not hide his irony: “First we blame the application. If that won’t work—because it would require Microsoft to fix its own code—we blame the user. The poor caveman user should have manually inspected the WSDL file and somehow realized it could write SOAP requests to files instead of sending them over HTTP. Alas.”
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
