A l’occasion de la Black Hat en Europe qui s’est tenue à Londres du 8 au 11 décembre, Piotr Bazydło  un chercheur de chez WatchTowr, société spécialisée en sécurité, a présenté une vulnérabilité dans les proxy http créés dans du code .NET. Le problème vient d’un comportement inattendu donnant aux attaquants la capacité d’écrire du code malveillant dans les fichiers. Il ouvre aussi la voie à de l’exécution de code à distance via des web shells et des scripts PowerShell malveillants dans de nombreuses applications .NET. En l’espèce, l’expert à dénicher des failles RCE dans Barracuda Service Center, Ivanti Endpoint Manager, Umbraco 8 CMS, PowerShell et SQL Server Integration Services de Microsoft.

Un comportement non prévu du proxy http pour .NET

.NET et ASP.NET figurent parmi les langages de programmation les plus populaires pour les applications d'entreprise. Quand un développeur souhaite faire communiquer son application avec un service web XML via http, il doit créer une classe de proxy dérivée de HttpWebClientProtocol. Le framework fournit trois classes de proxy : SoapHttpClientProtocol, HttpGetClientProtocol et HttpPostClientProtocol, qui prennent respectivement en charge Soap (simple object access protoocol), http get et http post. Le premier est particulièrement populaire, Soap étant un protocole largement utilisé pour l’échange de messages au format XML entre services web via http.

C'est là que réside le cœur du problème : comme le suggèrent les noms de ces classes et leur documentation officielle, elles sont conçues pour la communication http. Cependant, Piotr Bazydło a constaté que le passage d'URL avec le schéma file:// à ces classes proxy entraîne l'appel du gestionnaire FileWebRequest au lieu de HttpWebRequest. Selon lui ce comportement est un non-sens et peut entraîner des risques de sécurité.

La décision de Microsoft passe mal

Interrogée, la firme de Redmond ne prévoit pas de corriger ce problème dans le framework .NET 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 clients proxy http. Une position de principe qui ne satisfait par le chercheur de WatchTwr, car pour lui de nombreux développeurs exposent des API Soap dans leurs applications, parfois sans authentification. Il donne l’exemple de Barracuda Service Center, une plateforme de gestion d’accès à distance qui a corrigé le problème via un correctif.t

Il a par ailleurs trouvé d’autres méthodes d’exploitation dont « la plus efficace consiste à générer des clients proxy HTTP à partir de fichiers WSDL (web services description language) fournis par l'attaquant, en utilisant la classe ServiceDescriptionImporter ». Il ajoute « ce mécanisme a permis à lui seul une exploitation réussie dans des produits de Barracuda, Ivanti, Microsoft et Umbraco, et quelques jours d'analyse ont suffi pour trouver des cas fonctionnels », ajoute-t-il.