Introduction
By early 2015, the Java world was introduced to a new form of attack; an attack that affected more than 70 open-source Java libraries and made every Java developer and user worried. Web attacks were not a new thing in the Java world, or in any other language, but the advent of deserialization attacks at this time brought about what the world perceived as the Java Apocalypse. The fear was based on the reality that thousands of users of the affected libraries would be subject to Remote Code Execution. By 2017, the .NET world would also come to realize that Deserialization vulnerabilities were not only a Java problem, but rather the entire .NET world would also suffer the same fate.
Therefore, this article is going to cover real-world .NET examples of Deserialization.
Background
Today’s business systems are complex and highly distributed. You find the necessity to move data between services and store that information for business use. This process involves turning this data into a format that allows it to be transferred (serialization) using necessary protocols and there is a need to return this data in its original state (deserialization) for business use every once in a while. The problem we face is that not all serialized data can be trusted hence there is a need for developers to take extra caution against deserializing data from users/untrusted sources since this could cause costly disadvantages to the unsuspecting victims.
Attackers may have a way to manipulate serialized data at deserialization and this may pave a way for them to have access to sensitive information through Remote Code Executions on servers or user-personal computers. In 2015-2016 this was believed to be a Java Apocalypse when the world believed this was entirely a Java problem until 2017, when researchers discovered that deserialization in the .NET framework faced the very same risks.
Some real-world applications were affected through deserialization and researchers revealed:
- Breeze – a back-end data management framework that had a JSON flaw.
- NancyFX – a .Net web framework based on Ruby’s Sinatra which had a JSON deserialization flaw.
Secure Deserialization Recommendations
First and foremost, the OSWAP Insecure Deserialization cheat sheet advises developers not to accept objects from insecure sources such as general user input. On the other hand, it strongly advises developers to validate user input. Attackers may use cookies as objects to manipulate an application’s performance or gain access and promote their user privileges. The cheat sheet also advises developers to prevent deserialization of domain objects perform all deserialization with limited access privileges as this will limit the attacker's manipulation of the application.
In .NET, it is encouraged that developers do not allow datastream to define the type of object that they intend to deserialize. Rather, they should opt for DataContractSerializer or XmlSerializer. When using JSON, they should set the TypeNameHandling to “None” such that the attacker does not have a way to manipulate the object which they are deserializing.
Example - C#
- TypeNameHandling=TypeNameHandling.None
It is also necessary to restrict types that can be deserialized especially when you are deserializing data streams that define their own types.
Example
Developers should also try to avoid using references that allow arbitrary methods to be executed, such as:
Example
- using System.Windows.Data.ObjectDataProvider;
Conclusion
This article is aimed at showing real-world attacks perpetrated through Insecure Deserialization and tries to show ways of securely deserializing objects in the .NET Framework. It brings out clearly that Insecure Deserialization is not just a Java problem, but also affects .NET applications. .NET developers should also be cautious when deserializing objects such that organizational applications may not fall prey to attacks in the form of Remote Code execution, Denial-of-Service attacks, etc...