Security researchers have revealed a .NET security flaw thought to affect a host of enterprise-grade products that they say Microsoft refuses to fix.

Piotr Bazydło, principal vulnerability researcher at watchTowr, unveiled the findings at Black Hat Europe on Wednesday, claiming that several vendor and in-house solutions could be vulnerable to remote code execution (RCE) attacks due to errors in the way applications built on Microsoft’s .NET framework handle Simple Object Access Protocol (SOAP) messages.

The researcher identified the SoapHttpClientProtocol class as the primary culprit, explaining that it can be exploited in different ways to achieve an attacker’s goals.

The class inherits from HttpWebClientProtocol, as do other client proxy types, but watchTowr highlighted SoapHttpClientProtocol as it is by far the most common across codebases.

Bazydło said in a blog post shared with The Register before publication: "Its name and the official documentation both paint a simple picture: it should handle SOAP messages transported over HTTP. Straightforward. Predictable. Safe. Reality is less cooperative."

The class is responsible for setting the target URL of the SOAP service and defining a SOAP method, but the vulnerability arises when attackers can manipulate that target URL and the way SoapHttpClientProtocol creates clients.

Despite being designed to handle HTTP requests, SoapHttpClientProtocol uses a generic creation method that supports multiple protocols, including HTTP/HTTPS, FTP, and FILE.

If an attacker can set the target URL to a file system instead of an HTTP web address, the class will ignore the error and then write the SOAP request (which uses the POST method) directly into the file.

Bazydło wrote: "Wait, what. Why should a SOAP proxy be able to ‘send’ SOAP requests to a local file? Nobody on this planet expects to receive a valid SOAP response from the filesystem."

This unintended behavior can be abused by attackers to arbitrarily write files, including the XML data in the SOAP request. Or, less impactfully, NTLM relay attacks.

The researcher brought this issue to Microsoft at the time via the Zero Day Initiative (ZDI). Microsoft reportedly told Bazydło it would not be fixing the bug since developers should not be allowing untrusted inputs.

"Predictably, Microsoft treated the behavior as a feature rather than a vulnerability," Bazydło said. "The response blamed developers and users.

"According to Microsoft, the URL passed to SoapHttpClientProtocol should never be user-controlled, and it was the developer’s responsibility to validate inputs.

"Of course, all developers regularly decompile .NET Framework assemblies and read the internal implementation, so they obviously know that an ‘HTTP client proxy’ can be convinced to write data to the filesystem. How could anyone think otherwise?"

A year later, the folks at watchTowr started investigating Barracuda Service Center, which it described as "a widely deployed RMM platform," and one of the (now-fixed) enterprise-grade products vulnerable to the .NET exploits.

They soon found that its SOAP API method could be accessed with no authentication, leading them to an alternate exploitation path: through importing Web Services Description Language (WSDL) files.

Attackers can feed a URL that points to a WSDL file they control to vulnerable applications, which then generate an HTTP client proxy from it.

Bazydło said he found two ways to achieve remote code execution using this method: through uploading ASPX webshells; or dropping payloads (CSHTML webshells or PowerShell scripts) via the namespace of a SOAP request’s body.

He said that there are likely more ways to exploit the vulnerability, but the namespace technique was sufficient to exploit Ivanti Endpoint Manager and Umbraco 8 CMS.

These were the products mentioned in the watchTowr report as being affected, but the total number is thought to be much higher.

"Given the wide usage of .NET, and the limitations of hours in a day, the list of affected products should be considered anecdotal. There are most definitely numerous affected vendor and in-house solutions affected, but bluntly, we believe we’ve made our point with the above list," Bazydło said.

The watchTowr team reported the second exploit path to Microsoft in July, but were met with a similar response as they had received through the ZDI a year earlier.

Microsoft told the researchers again that it was not its fault that users were accepting untrusted inputs.

They received a near-identical response in follow-up reports to Microsoft, made in the context of Microsoft’s own products, some of which were also affected by the bug.

Although the issue relates to application behavior, "users should avoid consuming untrusted input that could generate and execute code," Microsoft said.

Clearly delighted with the response, Bazydło wrote: "So first we blame the application. If that is not an option, because it would require fixing Microsoft’s own code, we blame the user.

"The neanderthal user should have manually verified the WSDL file and realized that it could write SOAP requests to files instead of sending them over HTTP. Sigh." ®