Heim > Artikel > Betrieb und Instandhaltung > Beispielanalyse einer SoapFormatter-Deserialisierungsschwachstelle
NetDataContractSerializer wird wie DataContractSerializer zum Serialisieren und Deserialisieren von in Windows Communication Foundation (WCF)-Nachrichten gesendeten Daten verwendet. Es gibt einen wichtigen Unterschied zwischen den beiden: NetDataContractSerializer enthält die CLR und unterstützt die Typgenauigkeit durch das Hinzufügen zusätzlicher Informationen und das Speichern von Verweisen auf CLR-Typen, während DataContractSerializer dies nicht tut. Daher kann NetDataContractSerializer nur verwendet werden, wenn auf der Serialisierungs- und Deserialisierungsseite derselbe CLR-Typ verwendet wird. Um ein Objekt zu serialisieren, verwenden Sie die Methode „WriteObject“ oder „Serialize“ und zum Deserialisieren eines XML-Streams verwenden Sie die Methode „ReadObject“ oder „Deserialize“. In einigen Szenarien führt das Lesen eines bösartigen XML-Streams zu einer Deserialisierungsschwachstelle, wodurch ein Remote-RCE-Angriff erreicht wird. Der Autor dieses Artikels hat ihn aus der Perspektive der Prinzipien und Codeprüfung vorgestellt und reproduziert.
Die von der SoapFormatter-Klasse implementierte IFormatter-Schnittstelle definiert die Kernmethode Serialize, die sehr praktisch für die Konvertierung zwischen .NET-Objekten und SOAP-Streams sein kann und Daten als XML-Dateien speichern kann. Der Beamte sieht zwei Konstruktionsmethoden vor.
Lassen Sie uns einen alten Fall verwenden, um das Problem zu veranschaulichen. Definieren Sie zunächst das TestClass-Objekt.
Definieren Sie drei Mitglieder und implementieren Sie eine statische Methode ClassMethod, um den Prozess zu starten. Durch die Serialisierung werden den Mitgliedern jeweils Werte zugewiesen.
Normalerweise wird Serialize verwendet, um den serialisierten SOAP-Stream abzurufen, und die ursprüngliche Assembly wird unter Verwendung des XML-Namespace beibehalten Die TestClass-Klasse in der Abbildung unten wird mithilfe von xmlns generiert, um den a1-Namespace einzuschränken und sich auf ihn zu konzentrieren Erstellen eines neuen Objekts. Es wird durch den Aufruf mehrerer überladener Methoden von Deserialize implementiert. Überprüfen Sie die Definition und stellen Sie fest, dass die Schnittstellen IRemotingFormatter und IFormatter implementiert sind. Schauen Sie sich die Schnittstellendefinition IRemotingFormatter an und stellen Sie fest, dass sie auch IFormatter erbt
Der Autor erstellt ein neues Objekt. Den spezifischen Implementierungscode zum Aufrufen der Deserialize-Methode finden Sie im Folgenden: Der Wert des Mitgliedsnamens der TestClass-Klasse wird nach der Deserialisierung erhalten.3.2 Angriffsvektor – ActivitySurrogateSelector
Zusätzlich zum Konstruktor in der Definition der SoapFormatter-Klasse gibt es auch ein SurrogateSelector-Attribut, das der Proxy-Selektor ist Um eine Instanz des Typs zu deserialisieren, wird die vom Proxy-Objekt angepasste Methode aufgerufen. Schauen Sie sich die ISurrogateSelector-Schnittstelle an, die wie folgt definiert ist:
Da der Serialisierungs-Proxytyp die System.Runtime.Serialization.ISerializationSurrogate-Schnittstelle implementieren muss, ist ISerializationSurrogate in der Framework ClassLibrary wie folgt definiert:
Der Code bestimmt, ob die IsSerializable-Eigenschaft des Typparsers verfügbar ist. Wenn sie verfügbar ist, wird die direkte Basisklasse zurückgegeben. Wenn sie nicht verfügbar ist, wird der Typ der abgeleiteten Klasse System.Workflow.ComponentModel zurückgegeben. Serialization.ActivitySurrogateSelector wird abgerufen und dann an den Aktivator übergeben, um eine Instanz zu erstellen, und dann zurückgegeben. Um die serialisierten Daten vollständig zu steuern, müssen Sie im GetObjectData-Methodenkörper die Serialization.ISeralizable-Schnittstelle implementieren, die definiert ist als folgt:
Die folgende Abbildung definiert die PayloadClass-Klasse zum Implementieren der ISerializable-Schnittstelle und deklariert dann die generische List-Sammlung zum Empfangen von Bytetypdaten in der GetObjectData-Methode
# 🎜🎜#
Das obige Bild füllt die Variable e3 in die Paging-Steuerdatenquelle auf einen Blick,
#🎜🎜 #
Darüber hinaus unterstützt der von System.Runtime.Remoting.Channels.AggregateDictionary zurückgegebene Typ IDictionary und instanziiert dann das Objekt DesignerVerb und weist dieser Klasse nach Belieben Werte zu wird hauptsächlich verwendet, um den Wert des Attributs der MenuCommand-Klasse einzugeben. Weisen Sie schließlich den geeigneten Buckets Werte in der Hash-Tabelle zu.
Als nächstes verwenden Sie die Sammlung, um die Datenquelle DataSet hinzuzufügen. Die Objekte DataSet und DataTable erben von der Klasse System.ComponentModel.MarshalByValueComponent und kann Daten serialisieren. Und unterstützt die Remote-Verarbeitung. Die ISerializable-Schnittstelle ist das einzige Objekt unter den ADO.NET-Objekten, das die Remote-Verarbeitung unterstützt und im Binärformat gespeichert wird.
Ändern Sie den Wert der Eigenschaft DataSet.RemotingFormat in SerializationFormat.Binary, ändern Sie die Eigenschaft DataSet.CaseSensitive in false usw. und dann Rufen Sie BinaryFormatter auf, um die Listensammlung zu serialisieren, wie unten gezeigt.
Da das RemotingFormat-Attribut als Binär angegeben ist, wird der BinaryFormatter-Formatierer eingeführt und der Attribut-SurrogateSelector-Agent als benutzerdefinierte MySurrogateSelector-Art angegeben . Nach der Serialisierung wird das SOAP-XML abgerufen und dann die Deserialize-Methode des SoapFormatter-Objekts verwendet, um die Stream-Daten des gelesenen Dateiinhalts zu analysieren, und der Rechner wird erfolgreich angezeigt 🎜#
# 🎜🎜#
3.3 Angriffsvektor – PSObject
Da der Windows-Host des Autors CVE-2017-8565 (Windows PowerShell-Remotecodeausführung) besiegt hat, wurde der Patch für die Sicherheitslücke nicht erfolgreich ausgenutzt Wir werden hier nicht näher darauf eingehen. Interessierte Freunde können ihre eigenen Nachforschungen anstellen. Detaillierte Informationen zum Patch finden Sie unter: https://support.microsoft.com/zh-cn/help/4025872/windows-powershell-remote-code-execution-vulnerability
IV. Code-Audit# 🎜🎜#4.1
XML-LadenFinden Sie den Einstiegspunkt der Schwachstelle aus der Perspektive des Code-Audits, Passen Sie XML an und es kann auch sehr häufig verwendet werden, um darauf zu achten. Dieser Punkt kann auch zu XXE-Schwachstellen führen. Zum Beispiel dieser Code:
4.2 Datei lesen
Dieser Absatz ist ein Auszug aus einem bestimmten Bei der Prüfung von Anwendungscodeausschnitten müssen Sie lediglich darauf achten, ob die in der DeserializeSOAP-Methode übergebene Pfadvariable steuerbar ist.
Das obige ist der detaillierte Inhalt vonBeispielanalyse einer SoapFormatter-Deserialisierungsschwachstelle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!