NetDataContractSerializer, comme DataContractSerializer, est utilisé pour sérialiser et désérialiser les données envoyées dans les messages Windows Communication Foundation (WCF). Il existe une différence importante entre les deux : NetDataContractSerializer inclut le CLR et prend en charge la précision des types en ajoutant des informations supplémentaires et en enregistrant des références aux types CLR, contrairement à DataContractSerializer. Par conséquent, NetDataContractSerializer ne peut être utilisé que si le même type CLR est utilisé du côté de la sérialisation et de la désérialisation. Pour sérialiser un objet, utilisez la méthode WriteObject ou Serialize, et pour désérialiser un flux XML, utilisez la méthode ReadObject ou Deserialize. Dans certains scénarios, la lecture d'un flux XML malveillant entraînera une vulnérabilité de désérialisation, réalisant ainsi une attaque RCE à distance. L'auteur de cet article l'a présenté et reproduit du point de vue des principes et de l'audit du code.
L'interface IFormatter implémentée par la classe SoapFormatter définit la méthode Serialize de base, qui peut être très pratique pour convertir entre des objets .NET et des flux SOAP, et peut enregistrer des données sous forme de fichiers XML, le fonctionnaire propose deux méthodes de construction.
Utilisons un cas ancien pour illustrer le problème. Définissez d'abord l'objet TestClass
Définissez trois membres et implémentez une méthode statique ClassMethod pour démarrer le processus. La sérialisation attribue des valeurs aux membres en créant respectivement des instances d'objet
Normalement, Serialize est utilisé pour obtenir le flux SOAP sérialisé et l'assembly d'origine est conservé en utilisant l'espace de noms XML. la classe TestClass dans la figure ci-dessous est générée à l'aide de xmlns pour limiter, concentrez-vous sur l'espace de noms a1
<envelope> <body> <testclass> <classname>360</classname> <name>Ivan1ee</name> <age>18</age> </testclass> </body> </envelope>
Le processus de désérialisation de la classe SoapFormatter consiste à convertir le flux de messages SOAP en un objet en création d'un nouvel objet Il est implémenté en appelant plusieurs méthodes surchargées de Deserialize. Vérifiez la définition et découvrez que les interfaces IRemotingFormatter et IFormatter sont implémentées
Regardez la définition de l'interface IRemotingFormatter et découvrez qu'elle hérite également de IFormatter
.
L'auteur crée un nouvel objet Pour le code d'implémentation spécifique de l'appel de la méthode Deserialize, veuillez vous référer à ce qui suit
La valeur du membre Name de la classe TestClass est obtenue après désérialisation.
En plus du constructeur dans la définition de la classe SoapFormatter, il existe également un attribut SurrogateSelector qui est le sélecteur de proxy. L'avantage de sérialiser le proxy est qu'une fois que le formateur en a besoin. Pour désérialiser une instance du type, la méthode personnalisée par l'objet proxy est appelée. Découvrez l'interface ISurrogateSelector, qui est définie comme suit
Étant donné que le type de proxy de sérialisation doit implémenter l'interface System.Runtime.Serialization.ISerializationSurrogate, ISerializationSurrogate est défini dans la Framework ClassLibrary comme suit :
Le code détermine si la propriété IsSerializing de l'analyseur de type est disponible. Si elle est disponible, la classe de base directe est renvoyée. Si elle n'est pas disponible, le type de la classe dérivée System.Workflow.ComponentModel. Serialization.ActivitySurrogateSelector est obtenu, puis transmis à l'Activator pour créer une instance, puis renvoie Dans le corps de la méthode GetObjectData, afin de contrôler entièrement les données sérialisées, vous devez implémenter l'interface Serialization.ISeralisable, qui est définie comme suit :
Pour plus d'introduction, veuillez vous référer à ".NET Advanced Code Audit Leçon 2 Json.Net Response Serialization vulnérabilité", lors de l'implémentation d'une classe de désérialisation personnalisée, la classe PocClass fournie par l'attaquant est lue via la méthode constructeur
La figure suivante définit la classe PayloadClass pour implémenter l'interface ISerializing, puis déclare la collection générique List pour recevoir des données de type octet dans la méthode GetObjectData
Ajoutez l'objet PocClass à la collection List et déclarez le générique pour utiliser la collection IEnumerable map_type reçoit le Type reflété par l'assembly et renvoie le type IEnumerable Enfin, il utilise Activator.CreateInstance pour créer une instance et l'enregistrer dans e3. .
L'image ci-dessus remplit la variable e3 dans la source de données de contrôle de pagination. Vérifiez la définition de la classe PageDataSource pour la voir clairement
De plus, le type renvoyé par System.Runtime.Remoting.Channels.AggregateDictionary. prend en charge IDictionary, puis Object DesignerVerb instancié et attribue des valeurs à volonté. Cette classe est principalement utilisée pour remplir la valeur de l'attribut de propriétés de classe MenuCommand, et attribue enfin des valeurs aux compartiments qualifiés dans la table de hachage.
Ensuite, utilisez la collection pour ajouter la source de données DataSet. Les objets DataSet et DataTable héritent de la classe System.ComponentModel.MarshalByValueComponent, qui peut sérialiser les données et prendre en charge le traitement à distance. NET qui prend en charge le traitement à distance. Objets traités et conservés au format binaire.
Modifiez la valeur de la propriété DataSet.RemotingFormat en SerializationFormat.Binary, modifiez la propriété DataSet.CaseSensitive en false, etc., puis appelez BinaryFormatter pour sérialiser la collection List, comme indiqué ci-dessous.
Étant donné que l'attribut RemotingFormat est spécifié comme Binary, le formateur BinaryFormatter est introduit et l'attribut SurrogateSelector agent est spécifié comme classe MySurrogateSelector personnalisée. Après la sérialisation, le SOAP-XML est obtenu, puis la méthode Deserialize de l'objet SoapFormatter est utilisée pour analyser les données de flux du contenu du fichier lu, et la calculatrice apparaît avec succès CVE-2017-8565 (exécution de code à distance Windows PowerShell). Vulnérabilité) a été corrigé et l'exploit a échoué, je n'en discuterai donc pas en profondeur ici. Les amis intéressés peuvent faire leurs propres recherches. Pour des informations détaillées sur le correctif, veuillez vous référer à : https://support.microsoft.com/zh-cn/help/4025872/windows-powershell-remote-code-execution-vulnerability
XML Load
Il s'agit d'un extrait de code extrait d'une application Lors de l'audit, il vous suffit de faire attention à savoir si la variable de chemin transmise dans la méthode DeserializeSOAP est contrôlable.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!