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.
.jpg)
