.NET SOAPwn-fout opent de deur voor het schrijven van bestanden en het uitvoeren van externe code via frauduleuze WSDL

Nieuw onderzoek heeft exploitatieprimitieven in het .NET Framework blootgelegd die kunnen worden ingezet tegen bedrijfsapplicaties om code-uitvoering op afstand te bewerkstelligen.

WatchTowr Labs, dat de codenaam “ongeldige cast-kwetsbaarheid” heeft gegeven SOAPwnzei dat het probleem gevolgen heeft voor Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM) en Umbraco 8. Maar het aantal getroffen leveranciers zal waarschijnlijk groter zijn gezien het wijdverbreide gebruik van .NET.

De bevindingen werden vandaag gepresenteerd door watchTowr-beveiligingsonderzoeker Piotr Bazydlo op de Black Hat Europe-veiligheidsconferentie, die in Londen wordt gehouden.

Met SOAPwn kunnen aanvallers misbruik maken van de import van Web Services Description Language (WSDL) en HTTP-clientproxy’s om willekeurige code uit te voeren in producten die zijn gebouwd op de fundamenten van .NET vanwege fouten in de manier waarop ze omgaan met Simple Object Access Protocol (SOAP)-berichten.

“Het is meestal misbruikbaar via SOAP-clients, vooral als ze dynamisch worden gemaakt op basis van de door de aanvaller bestuurde WSDL”, zegt Bazydlo.

Als gevolg hiervan kunnen .NET Framework HTTP-clientproxy’s worden gemanipuleerd om bestandssysteemhandlers te gebruiken en willekeurig bestanden te schrijven door als URL zoiets als “file:// door te geven” in een SOAP-clientproxy, wat uiteindelijk leidt tot het uitvoeren van code. Tot overmaat van ramp kan het worden gebruikt om bestaande bestanden te overschrijven, aangezien de aanvaller het volledige schrijfpad beheert.

In een hypothetisch aanvalsscenario zou een bedreigingsacteur dit gedrag kunnen gebruiken om een ​​Universal Naming Convention (UNC)-pad op te geven (bijvoorbeeld “file://attacker.server/poc/poc”) en ervoor te zorgen dat het SOAP-verzoek wordt geschreven naar een SMB-share onder zijn controle. Hierdoor kan een aanvaller de NTLM-uitdaging onderscheppen en kraken.

Dat is niet alles. Uit het onderzoek is ook gebleken dat een krachtigere exploitatievector kan worden ingezet in toepassingen die HTTP-clientproxy’s genereren op basis van WSDL-bestanden met behulp van de ServiceDescriptionImporter-klasse, door gebruik te maken van het feit dat deze de URL die wordt gebruikt door de gegenereerde HTTP-clientproxy niet valideert.

Bij deze techniek kan een aanvaller een URL opgeven die verwijst naar een WSDL-bestand dat hij beheert naar kwetsbare applicaties, en externe code-uitvoering verkrijgen door een volledig functionele ASPX-webshell of extra payloads zoals CSHTML-webshells of PowerShell-scripts te laten vallen.

Na verantwoorde openbaarmaking in maart 2024 en juli 2025 heeft Microsoft ervoor gekozen het beveiligingslek niet op te lossen, waarbij het stelt dat het probleem voortkomt uit een applicatieprobleem of gedrag, en dat “gebruikers geen onbetrouwbare invoer mogen gebruiken die code kan genereren en uitvoeren”.

De bevindingen illustreren hoe verwacht gedrag in een populair raamwerk een potentieel exploitpad kan worden dat leidt tot NTLM-relaying of het willekeurig schrijven van bestanden. Het probleem is sindsdien verholpen in Barracuda Service Center RMM versie 2025.1.1 (CVE-2025-34392, CVSS-score: 9,8) en Ivanti EPM versie 2024 SU4 SR1 (CVE-2025-13659, CVSS-score: 8,8).

“Het is mogelijk om SOAP-proxy’s SOAP-verzoeken in bestanden te laten schrijven in plaats van ze via HTTP te verzenden”, zegt Bazydlo. “In veel gevallen leidt dit tot uitvoering van code op afstand via webshell-uploads of PowerShell-scriptuploads. De exacte impact hangt af van de applicatie die de proxyklassen gebruikt.”

Thijs Van der Does