Le chercheur prévient que de nombreuses applications .NET pourraient être vulnérables aux écritures de fichiers arbitraires, car les classes proxy client HTTP de .NET acceptent également les URL non HTTP, un comportement contre lequel les développeurs sont tenus de se prémunir – mais auquel il est peu probable qu’ils s’attendent.
Les chercheurs ont découvert un comportement inattendu des proxys clients HTTP lorsqu’ils sont créés dans du code .NET, permettant potentiellement aux attaquants d’écrire du code malveillant dans des fichiers arbitraires. Cela peut à son tour ouvrir des voies d’attaque par exécution de code à distance (RCE) via des shells Web et des scripts PowerShell malveillants dans de nombreuses applications .NET, y compris des produits commerciaux.
Microsoft ne prévoit pas de résoudre ce problème dans le .NET Framework lui-même, affirmant que les développeurs d’applications sont responsables de ne pas transmettre d’URL non fiables et contrôlées par l’utilisateur aux classes de code qui initialisent les proxys clients HTTP.
« L’impact dépend de la manière dont chaque application utilise les classes proxy, mais en pratique, nous avons atteint le RCE dans presque tous les produits que nous avons étudiés », a déclaré Piotr Bazydlo, chercheur de la société de sécurité watchTowr, dans un rapport. Bazydło est également l’auteur d’un livre blanc technique qu’il a présenté mercredi lors de la conférence Black Hat Europe.
En tirant parti de ce comportement inattendu de .NET, le chercheur a découvert des problèmes RCE dans Barracuda Service Center, Ivanti Endpoint Manager, Umbraco 8 CMS, Microsoft PowerShell et Microsoft SQL Server Integration Services. Cependant, il estime que de nombreux autres produits et applications d’entreprises privées sont probablement vulnérables.
« Le chemin d’exploitation le plus puissant apparaît lorsque les applications génèrent des proxys clients HTTP à partir de fichiers WSDL fournis par l’attaquant à l’aide du ServiceDescriptionImporter classe », a-t-il déclaré. « Ce mécanisme à lui seul a permis une exploitation réussie dans les produits de Barracuda, Ivanti, Microsoft et Umbraco, et il n’a fallu que quelques jours d’examen pour trouver des cas fonctionnels. »
Les proxys clients HTTP peuvent gérer des protocoles non HTTP
Le .NET Framework et ASP.NET font partie des langages de programmation les plus populaires pour les applications d’entreprise. Lorsqu’un développeur souhaite que son application communique avec un service Web XML via HTTP, il doit créer une classe proxy dérivée de la classe proxy intégrée. HttpWebClientProtocol classe.
Le Framework fournit également trois classes de proxy : SoapHttpClientProtocol, HttpGetClientProtocolet HttpPostClientProtocol – qui permettent la prise en charge de SOAP, HTTP-GET et HTTP-POST, respectivement. Le SoapHttpClientProtocolqui permet d’exécuter des requêtes SOAP dans des applications .NET, est particulièrement populaire, car SOAP est un protocole largement utilisé pour échanger des messages au format XML entre des services Web via HTTP.
C’est là que réside le cœur du problème : comme l’indiquent les noms de ces classes – et leur documentation officielle –, elles sont destinées à être utilisées pour la communication HTTP. Cependant, ce que Bazydło a découvert, c’est que transmettre des URL avec le file:// système à ces classes de proxy entraînera le FileWebRequest gestionnaire étant appelé au lieu de HttpWebRequest.
« Attendez, quoi ? Pourquoi un proxy SOAP doit-il pouvoir « envoyer » des requêtes SOAP à un fichier local ? » dit-il. « Personne sur cette planète ne s’attend à recevoir une réponse SOAP valide du système de fichiers. »
Parce qu’il n’y a aucune mention dans la documentation que ces classes fonctionnent également avec les schémas de protocole FILE ou FTP, et qu’il n’y a aucune raison raisonnable de s’attendre à ce qu’elles le fassent, de nombreux développeurs ne sont probablement pas conscients de ce comportement et n’ont pas pris de mesures supplémentaires pour empêcher cela.
Un chemin vers l’exploitation
Bien que ce comportement étrange permette l’exploitation, il ne la garantit pas. Premièrement, un attaquant devrait être capable de contrôler l’URL transmise à l’une de ces classes dans le code de l’application. Bien que Microsoft semble suggérer que cela ne devrait pas se produire, dans la pratique, de nombreux développeurs d’applications exposent les points de terminaison de l’API SOAP dans leurs applications, parfois sans authentification.
Un exemple trouvé par Bazydło était celui de Barracuda Service Center, une plate-forme de surveillance et de gestion à distance (RMM) d’entreprise populaire. Le problème, désormais suivi comme CVE-2025-34392, a été corrigé dans le correctif 2025.1.1.
En étant capable de transmettre une URL arbitraire à un point de terminaison d’API SOAP dans une application .NET affectée, un attaquant peut déclencher une fuite de défi NTLM. Par exemple, un file:// Une URL pointant vers un serveur SMB distant contrôlé par un attaquant amènera le système à envoyer ses informations d’identification NTLM sous forme cryptée à ce serveur. L’attaquant peut alors soit tenter de les pirater, soit les utiliser dans une attaque par relais NTLM.
Cependant, pour provoquer une écriture de fichier arbitraire local plus puissante, l’attaquant doit également être capable de contrôler les arguments envoyés à la méthode SOAP, ce qui signifie que des chaînes arbitraires peuvent être insérées dans la sortie XML écrite sur le chemin contrôlé sur le disque. Contrôler cela suffira souvent à écrire un web shell au format CSHTML (server-side templates) sur le serveur hébergeant l’application vulnérable.
Mais cela ne s’arrête pas là. Une autre façon d’exploiter cela consiste à importer du langage de description de services Web (WSDL). WSDL est un langage Web basé sur XML utilisé pour fournir des informations sur leurs fonctionnalités et les interfaces disponibles. Un service peut fournir un fichier WSDL à une application client, qui l’analyse ensuite pour créer automatiquement des requêtes SOAP valides au service.
La génération de proxys SOAP clients à partir d’importations WSDL est une fonctionnalité assez courante dans les applications .NET. Elle est obtenue en analysant les fichiers WSDL à l’aide de l’outil ServiceDescriptionImporter classe. Comme Bazydło l’a découvert, ServiceDescriptionImporter ne valide pas que la définition du service dans le fichier WSDL est HTTP ou HTTPS.
« Pour résumer, les importations WSDL créent un chemin d’exploitation très puissant pour le problème de distribution non valide dans HttpWebClientProtocol« , a-t-il déclaré. « Si un attaquant contrôle le WSDL importé, il contrôle également : L’URL cible, qui permet au proxy d’interagir avec le système de fichiers ; les noms des méthodes SOAP ; les noms et les types d’arguments de méthode.
C’était le cas de la vulnérabilité Barracuda Service Center, mais également du CMS Umbraco 8 — l’un des systèmes de gestion de contenu les plus populaires écrit en .NET — et d’Ivanti EPM. Umbraco 8 est arrivé en fin de vie en février et ne reçoit donc plus de correctifs de sécurité.
« À un niveau élevé, l’histoire est simple », a déclaré le chercheur de watchTowr. « Le .NET Framework permet à ses proxys clients HTTP d’interagir avec le système de fichiers. Avec les bonnes conditions, ils écriront volontiers les requêtes SOAP dans des chemins locaux au lieu de les envoyer via HTTP. Dans le meilleur des cas, cela se traduit par un relais NTLM ou une capture de défi. Dans le pire des cas, cela devient une exécution de code à distance via des téléchargements WebShell ou des suppressions de scripts PowerShell. «
