Security-as-Code: The Solution to Insecure Deserialization

On September 7, 2017, Equifax announced it had suffered one of the most significant data breaches in history, with 147 million consumers impacted.

This data breach was made possible through data exchanged via an API.

When you think about the data your applications collect from your users, such as email addresses, passwords, and names, security problems arise when your systems receive the data and attempt to deserialize it to process it.

Insecure Deserialization

Deserialization is a topic that few people talk about due to its complexity. At its core, it means parsing data into meaningful values of various types for your applications to use.

This flexibility is its biggest downfall: Data streams can contain binary data and expected inputs. In the case of Equifax, a malicious manipulation of the XML resulted in the attacker performing RCE on the Equifax server.

OWASP refers to this attack vector as “deserialization of untrusted data,” which describes “Data which is untrusted cannot be trusted to be well-formed. Malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code when deserialized.”

Outside of refactoring your applications, there’s traditionally not much that can be done about it. Existing mitigations have many limitations:

1. They are known to be easily bypassed
2. They don’t protect deferred attacks where the execution of the payload is executed after deserialization (ex. via the finalize() method)
3. They will not mitigate any DoS deserialization attacks
4. They require yet another type of whitelist to be created and maintained

A declarative solution

There is a need for a better solution to address this critical vulnerability. In this whitepaper, you’ll learn about insecure deserialization, the limits of known mitigations, and how Security-as-Code is ideal for solving this problem by:

• Requiring zero code changes
• Protecting against golden gadget chains
• Producing zero false positives or false negatives

Waratek offers this solution through our Security-as-Code platform. Turning on declarative “Deserial” rules wholly and automatically protects the entire application stack against Java deserialization attacks, known or unknown (zero-day).

Waratek achieves this level of protection by creating a dynamic, restricted compartment inside its platform. This restricted compartment is active for the duration of each deserialization operation and afterward, such as during garbage collection.

The restricted compartment allows any legitimate functionality to run normally but prohibits any gadget chain from abusing and compromising the system. The feature enables the InvokerTransformer to be used generally by systems that depend on this functionality without compromising the system by any malicious gadget chains.