Preventing Remote Code Execution Exploits in Java

by Shawn McKinney | Sep 26, 2017 | Application Security, Software Design

Equifax Breach

Recently there’s been a buzz over the Equifax breach — rightly so.  It’s a transformative event and its effects will reverberate for years if not decades.

What’ll Happen Next

Nobody knows for sure, but we can guess.  First, the leadership at Equifax will be replaced, and we’re seeing that happen now.  Next, there’ll likely be new standards governing security in the workplace, specifically around punitive damages when service providers commit gross negligence, as was the case here.  Finally, the usage of the Social Security Number itself as a credential in account origination will fall out of practice.  Why?  Because there’s no expectation that data is private now that 143 million records have leaked.

How To Prevent This From Happening

There’s no foolproof way to secure computing systems. But there are ways to mitigate the risk of exposure once the inevitable breach occurs.

Practice The Principle of Least Privilege

If Equifax had run their software inside a sandbox, like SELinux or the Java Security Manager, it would not have been possible for a remote code exploit to invoke system commands, a precursor to leaking the data.  The following code sample shows how to run Java code inside of a security sandbox that enforces mandatory access controls:

https://github.com/shawnmckinney/serial-exploit-sample

Nothing can be done before first being added to the policy file.  Follow the instructions inside the README to understand how the Java Security Manager works and how it can be used to prevent untrusted code from executing system commands.

More Reading

The Exploit CVE-2017-5638

How Does It Work

• Input data deserialized into an executable object with privilege.
• http://blog.diniscruz.com/2013/12/xstream-remote-code-execution-exploit.html