Beispielanalyse einer SoapFormatter-Deserialisierungsschwachstelle

1. Einführung

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.

2. SoapFormatterSerialisierung

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:

Eine weitere Einführung finden Sie unter „.NET Advanced Code Audit Lesson 2 Json.Net Response Serialization Schwachstelle“. Bei der Implementierung einer benutzerdefinierten Deserialisierungsklasse wird die vom Angreifer bereitgestellte PocClass-Klasse über die Konstruktormethode gelesen

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
# 🎜🎜#

Fügen Sie das PocClass-Objekt zur List-Auflistung hinzu, deklarieren Sie den generischen Typ und verwenden Sie die IEnumerable-Auflistung „map_type“, um den von der Assembly reflektierten Typ zu empfangen und das IEnumerable zurückzugeben Geben Sie ein und erstellen Sie schließlich eine Instanz mit Activator.CreateInstance. Was in e3 gespeichert wird, ist ein Iterator der aufgezählten Sammlung.

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-Laden

Finden 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:

Die Angriffskosten dieser Art von Sicherheitsanfälligkeit für Verschmutzungspunkte sind sehr gering Die eingehende Zeichenfolgenparameterquelle Sie können problemlos Deserialisierungs-Schwachstellenangriffe implementieren und den Taschenrechner öffnen.

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!