SECURITY INFLUENCERS BLOG

Security influencers provide real-world insight and “in-the-trenches” experiences on topics ranging from application security to DevOps and risk management

START FREE TRIAL

Why the Java serialization vulnerability makes Heartbleed look tame - explained

I've been receiving questions from some of you to provide a bit more detail on why this Java vulnerability is so critical to fix...

Basically, why is this such a big deal? 

It’s a big deal because many enterprise applications are vulnerable. It’s not fully automated, but it’s still pretty easy to find and exploit this problem in applications.  And it allows the attacker to completely take over the entire server the application is hosted on.  They could steal or corrupt any data accessible from that server, steal the application's code, change the application, or even use that server as a launching point for further attacks now that they are inside the data center.

What exactly is the vulnerability all about?

Programmers use “serialization" to transfer complex data structures between computers. It’s an easy way to take a whole bunch of “objects” and turn them into a single data stream that can be “deserialized” at the other end.   In this attack, special objects are serialized that cause the standard Java deserialization engine to run code of the attacker’s choosing.  It’s not exactly a problem in Java, or in any particular libraries.  It’s just a powerful functionality that organizations shouldn’t expose to untrusted users.

What are the implications for enterprises?

They should immediately find all the places where they are using deserialization on untrusted data, as there is a high likelihood that it is exploitable.  Searching their code is only a partial solution, because frameworks and libraries that they are including in their applications might also create this exposure.

How can it be mitigated?

The deserialization vulnerability is tricky to mitigate because it can occur anywhere in your stack — your app server, framework, libraries, or custom code.  The best way to solve this problem is to use something called Runtime Application Self-Protection (RASP).  You add an agent to your Java environment that hardens everywhere that uses the deserialization engine and prevents it from being exploited.

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast. Previously, Jeff was co-founder and CEO of Aspect Security, a successful and innovative application security consulting company acquired by Ernst & Young. Jeff is also a founder and major contributor to OWASP, where he served as the Chair of the OWASP Board for 8 years.

SUBSCRIBE TO THE BLOG

Learn how to unify security strategy across & development operations. See how to set up a CAS program with only eight activities!

Download the Handbook