Last week the world was hit with what can be awarded the Vulnerability Of The Day for Java – the commons-collections deserialization vulnerability. The latest victim of the continued series of vulnerabilities comes from the Spring project with an implicating class that allows the same unsafe deserialisation vector in the spring-core.
What makes this issue particularly nasty is that, like the name implies, the spring framework is near-ubiquitous in Java applications. The issue has to do with reading untrusted serialised data from disk and introducing a malicious payload into such a file. The resulting exploit is very powerful – execution of system commands and privilege escalation can be achieved. There is also a published attack method to generate a malicious binary to exploit the issue.
The sad thing is this vulnerability is an implementation of a series of concerns raised about Java Deserialization by Gabriel Lawrence and Chris Frohoff in their presentation in AppSecCali 2015 in January – almost a year ago.
The vulnerability exposes countless of attack vectors in places that are scarier than you might imagine. Since Java can be found in most products ranging from industrial centrifuges used in nuclear fuel manufacturing to car infotainment systems, we as an industry must mount a swift response. Though seeming innocuous and like “just another java vulnerability”, the potential for exploits has real human lives at risk.
What’s up? What does it do?
To read a great description on how exactly this vulnerability can be leveraged in general, read this awesome article disclosing exploits against many of the most known java application servers:
To understand how it affects spring, refer to this ticket: https://jira.spring.io/browse/SPR-13656
The Sonatype report of this issue can be found here with recommendations on how to solve the problem: https://support.sonatype.com/hc/en-us/articles/213733638-Spring-core-unintended-code-execution-in-deserialization
How do I know I’m vulnerable?
At the time of writing, the Spring community has fixed this issue in the 4.2.3 release. Currently, if you have any of the older versions in your classpath you can consider yourself vulnerable to this exploit if your application performs any form of deserialisation of untrusted data. It can be mitigated by upgrading to the latest version of Spring.
Nexus Lifecycle alerts
Nexus Lifecycle users who have turned on continuous monitoring have received alerts for any of their applications that contain the affected libraries. Within hours of the original article going live, the Sonatype team appended the description for the affected libraries as a new issue in the system. Nexus Lifecycle allows you to monitor the external dependencies of your applications that have been put into production and be aware of any new security vulnerabilities as soon as they enter the system. This allows you to react to issues such as this before any of your clients start asking about it.
Alerting can be configured in the policy editor. This policy monitors for any new disclosed vulnerabilities in all of my organization’s applications.
Proactive alerting is key
Software components unfortunately do not age like fine wine but more like milk. We’ve all had that morning where milk that was perfectly fine yesterday but now mocks your tiredness as clogged flakes and clumps in your cup. The same principle applies to software components in regards to vulnerabilities – once it is out in the wild the milk has spoilt and should be replaced with a new carton.
Patching issues should be done as fast as possible when vulnerabilities do appear in the wild. Every moment not addressing the issues of course exposes your products to attackers that will now be shoving their sticks at every exposed port out there.
Finally, it is important to be aware when you are inflicted as soon as possible as your customers will worry about it. Reacting fast and on time to vulnerabilities builds trust and enables managing what is an exceptionally bad situation.
What do I do?
As always when dealing with situations like this, good development hygiene and professionalism go a long way. One of the key things you should do is keep a copy of a complete software bill of materials (BoM) of your applications that have been put into production. Sonatype offers this as a free service. After an initial analysis, do keep this bill of materials updated and current after every new release goes into production.
In the end, there is no such thing as perfect security, but with good methodology and process we can act and mitigate such vulnerabilities as fast as possible. As time goes on, there surely will be new discoveries around deserialization and java artifacts as it is one of the core methods used in the java world. When new issues are discovered or new mitigations published, we’re sure to keep our data service up to date.
Latest posts by Ilkka Turunen (see all)
- The Latest Victim of Deserialization-Gate - November 23, 2015
- Nexus and SSL - November 4, 2015
- 3 Things Developers Can Learn from the Scandal at VW - October 28, 2015
- Automating Nexus Deployment: Cookbooks, Modules and Playbooks - August 18, 2015
- Using the REST API in Nexus 2.x - August 13, 2015