Data serialization and deserialization are integral parts of any business operating java applications, but they also present an easy target for attackers. As code is converted from readable text to binary code and back again, attackers can hide malicious payloads in the datastream. This process can be exploited to bypass authentication, levy a denial of service attack (DoS attack), or acquire access to remote code execution within the receiving application. As a result, insecure deserialization has become a popular target for modern attackers. Some of the past decade’s most notable attacks exploited deserialization as a means of gaining initial access, including the infamous 2017 Equifax breach.
In order to adapt to become resilient to insecure deserialization attacks, security practitioners must turn towards automation. This process involves incorporating security controls and policies into the software development process, allowing for automated testing and enforcement of security policies, and making it easier to detect and fix security issues.
The Waratek Java Security Platform can be used to monitor the entire software development lifecycle and ensure that developers are aware of and following best practices for securing the deserialization process.
By the Numbers — How Bad Is Insecure Deserialization?
It is difficult to determine an exact percentage of total compromise that comes from insecure deserialization. But trends in reports do suggest that insecure deserialization is a significant contributor to data breaches and cyber attacks. One study by the SANS Institute found that in a sample of 50 web applications, 40% were vulnerable to insecure deserialization attacks. The researchers also found insecure deserialization vulnerabilities present in 34 percent of Java applications.
Given that these attacks tend to have success and that security programs don’t have a fantastic way of rooting out these vulnerabilities, it is an avenue of attack that is gaining momentum.
What’s more, reports estimate that the average cost of a data breach caused by insecure deserialization is $3.86 million. While that may be simply an expensive annoyance for an enterprise giant, early revenue companies can ill afford that kind of a price tag.
Why is Insecure Deserialization so difficult to get a handle on?
By its nature, serialized data is difficult to scan for threats. Deserialization is a complex process, and it is difficult to identify vulnerabilities in the code that could be exploited. Different programming languages and frameworks handle deserialization differently, making it difficult to develop a one-size-fits-all solution for secure deserialization. Meanwhile, developers may assume that they are protected against deserialization attacks because they are not actively using serialization in their code. However, even if serialization is not used, libraries and frameworks can still deserialize data, and this can lead to a false sense of security.
Even as attackers continue to focus on insecure deserialization as a means of gaining a foothold in target systems, mainstream security solutions are struggling to overcome these challenges and provide an easy means of weeding out these threats.
When these vulnerabilities can be identified, implementing effective mitigation strategies presents another challenge. For example, input validation and whitelisting can be difficult to implement effectively, and using a secure serialization library may not be possible if the application is using a legacy framework. Meanwhile, even when these are found, patching often breaks backwards compatibility with a given library. Patching in these instances would often break an application’s functionality.
Current Solutions are Not Working
Insecure Deserialization has been on the OWASP Top 10 for several years and in 2021, it was moved under the new larger category of Software and Data Integrity Failures. Insecure deserialization owes its dominant reign in these categories almost entirely to its opacity. Scanning for threats is not an option when you cannot see what is in the data.
In fact, if you look over the history of suggestions on how to address this vulnerability, some of them are pretty drastic and not at all realistic for the real world. One of the fixes involves disabling classes known to be used in attacks (creating an ongoing whack-a-mole game). Another fix as suggested by CERT is to simply have developers “re-architect their applications”. Oh, is that all? Better call your spouse and tell them you’ll be late for dinner, because re-architecting even a single application can take days.
What’s more, re-architecting an application is only a temporary fix. Since the application would ostensibly still perform data deserialization as a function, an attacker would need only to reintroduce new malware using the same methodology and own your newly architected application all the same.
How Can We Help?
This is where Waratek’s Java Security Platform comes in. The platform uses code to manage and automate security tasks at the application layer rather than the network layer, such as configuration management and compliance checking. This approach can help reduce costs for security teams by automating repetitive tasks, reducing errors, and allowing for more efficient use of resources. It also enables teams to more easily scale and manage security across multiple systems and environments.
The platform uses immutable rules which are incorporated into the application at the development stage to protect against insecure deserialization attacks. By using machine-readable definition files to automatically check for and remediate known and unknown vulnerabilities, including Java deserialization attacks. This level of protection is achieved by creating a dynamic, restricted compartment inside your application. This compartment is activated for the duration of each deserialization operation and afterward during garbage collection. This functionality allows any legitimate functionality to run normally, but prohibits any exploit from abusing and comprising the application, resulting in a massive decrease to your attack surface, without any changes to the behavior of your application.
While a lot of the solutions on the market would have you working nights and weekends, Waratek’s dev-stage application security guardrails are designed to reduce the burden of work on security personnel. These protocols act without the need for oversight, and are built in as early as possible in the life-cycle of an application. By operating automatically from day one, these immutable security guardrails make entire classes of java attacks (including insecure deserialization) functionally impossible for the lifecycle of the application.
To get started securing your java apps against insecure deserialization, click here.
