Identifying Vulnerable Functions

Introduction

Now that we have TeeTrove decompiled (either with dotPeek or ILSpy), we can start looking through the source code for potential vulnerabilities; in the case of this module that means we will be looking exclusively for potential deserialization vulnerabilities in the code base.

(Potentially) Vulnerable Functions

There are many different data serializers available for C#/.NET, including those dealing with binary, YAML, and JSON schemes. Luckily for us (attackers), many of these serializers can be vulnerable and may be exploited in a very similar fashion.

Below is a table of common .NET serializers (listed alphabetically), with respective examples of calls to their deserialization functions (and links to documentation). When conducting a penetration test with access to source code, searching for the example functions can be a good way to quickly identify potential deserialization vulnerabilities.

Serializer	Example	Reference
BinaryFormatter	.Deserialize(...)	Microsoft
fastJSON	JSON.ToObject(...)	GitHub
JavaScriptSerializer	.Deserialize(...)	Microsoft
Json.NET	JsonConvert.DeserializeObject(...)	Newtonsoft
LosFormatter	.Deserialize(...)	Microsoft
NetDataContractSerializer	.ReadObject(...)	Microsoft
ObjectStateFormatter	.Deserialize(...)	Microsoft
SoapFormatter	.Deserialize(...)	Microsoft
XmlSerializer	.Deserialize(...)	Microsoft
YamlDotNet	.Deserialize<...>(...)	GitHub

ViewState

Aside from the functions listed above, there is a feature called ViewState which some ASP.NET applications use to maintain the state of a page. The process involves storing a serialized parameter in a cookie called __VIEWSTATE and it is sometimes possible to exploit this if the server is misconfigured. Attacks exploiting ViewState will not be covered in this module, but for the interested reader, the following resources cover the basics:

• Exploiting Deserialization in ASP.NET via ViewState
• Exploiting ViewState Deserialization using blacklist3r and YSoSerial.NET

Black-Box

Depending on the type of engagement, we might not always have access to the application's source code or binary file. Therefore, to identify potential deserialization functions, we need to search for specific bytes or characters (referred to as magic bytes) in the data sent from the web client to the server.

For .NET Framework applications, we can keep an eye out for the following:

• Base64-encoded strings beginning with AAEAAAD/////
• Strings containing $type
• Strings containing __type
• Strings containing TypeObject

Not Always Vulnerable

It is important to keep in mind that not every use of a deserialization library function may be vulnerable! Suppose we want to create a class named ExampleClass that implements the function Deserialize. This function utilizes JavaScriptSerializer to deserialize a Person object (defined below) provided to the function as a string.

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

One way a developer might implement ExampleClass is like this:

using System.Web.Script.Serialization;

public class ExampleClass
{
    public JavaScriptSerializer Serializer { get; set; }

    public Person Deserialize<Person>(string str)
    {
        return this.Serializer.Deserialize<Person>(str);
    }
}

Another developer may decide to implement the function slightly differently, and instantiate a new JavaScriptSerializer each time like this:

using System.Web.Script.Serialization;

public class ExampleClass
{
    public Person Deserialize<Person>(string str)
    {
        JavaScriptSerializer serializer = new JavaScriptSerializer();
        return serializer.Deserialize<Person>(str);
    }
}

In this case, the difference is very small, and yet the first example is potentially vulnerable, while the second is completely safe. The reason for this is that in the first case, an attacker may be able to control the instantiation of the object's Serializer. If the SimpleTypeResolver is used when instantiating a JavaScriptSerializer, then the subsequent deserialization will be susceptible to exploitation.

ExampleClass example = new ExampleClass();
example.Serializer = new JavaScriptSerializer(new SimpleTypeResolver());
example.Deserialize("...[Payload]...");

This is just one example (based on Microsoft's code analysis rule CA2322) of a slight difference in implementation leading to a potential vulnerability, but many others are affecting the various serializers. The main point to take away from this example is that deserialization libraries are not inherently vulnerable. Oftentimes, the context (in this case the type of Resolver) is important in determining the security of a code snippet.

Hunting for Deserialization

At this point, we have TreeTrove's decompiled source code and a better understanding of what we want to look for to identify potential deserialization vulnerabilities.

We can either search through the assembly right inside dotPeek/ILSpy, or through the exported decompiled code using tools such as IDEs or scripting languages. For example, let's use the Select-String PowerShell cmdlet to search for .Deserialize( like so.

PS C:\> Select-String -Pattern "\.Deserialize\(" -Path "*/*" -Include "*.cs"

As you can see below, we already found two spots that are potentially vulnerable to deserialization attacks.

In the upcoming sections, we will determine whether the deserialized objects are controlled by user input, and whether the use of the deserialization functions is indeed vulnerable.