In the first part of our blog series on the ransomware attack on the San Francisco Municipal Transportation Agency, we discussed how the attacker chose to exploit a deserialization vulnerability in WebLogic to compromise vulnerable systems. And we learned that this vulnerability was a big target, because it is the result of a component (Apache Commons Collections) present in about 50 percent of all Java applications and a risky programming practice – unsafe deserialization – present in about 25 percent of all Java applications.
So how did a relatively obscure open source Java library end up being so widely distributed? To understand that, it helps to learn some things about Java open source development. The Java open source community is robust, partly because the underlying language has a lot of opportunities to add convenience functions, and partly because Java has benefited from an open source ecosystem, including foundational software like web servers, build servers, defect tracking systems, and others. And while there are a lot of high-profile open source software projects like Jenkins and Jboss, there are others that address more everyday tasks that developers have to address.
One of those libraries is the widely-used Apache Commons Collections, part of the Apache Commons project, which focuses on developing and promoting reusable Java components. Apache Commons Collections provides utilities for working with groups of data in memory. The Maven repository of open source components, which collects and tracks components and their usage, says that Apache Commons Collections is used in 3,160 other artifacts. Some of those, like Hibernate (a library for accessing database and other storage), Spring, Hadoop and others, are themselves used in hundreds or thousands of other open source libraries and frameworks. So it’s likely that developers aren’t picking Commons Collections directly, but getting it included in their application because of something they did pick.
The data from our most recent State of Software Security report reinforces this hypothesis. The most common Java component is aopalliance-1.0.jar, a library for doing aspect oriented programming – which happens to be used in Spring and other major projects. It's likely most developers don't know they're using it.
The other information we’ve learned from studying the component data is that developers rarely if ever update components; once incorporated in the software, they’re there for life. Why? Our conversations with development teams suggest it’s because updating components can be expensive. At a minimum, you have to regression test all the parts of your application that leverage the component. In some cases you may identify additional places where your application doesn’t work correctly with the new version that need to be worked around or re-architected.
None of this, by the way, is to suggest that open source is inherently bad. Our data shows that commercial or enterprise-developed software is just as likely to have vulnerabilities. And it’s unrealistic to expect developers to build all the functionality of their applications themselves. Not only would that lead to unrealistically long time-to-market for software, in many situations it’s counterproductive from a security standpoint to do so. (See, for instance, the First Rule of Cryptography).
But the evidence does point to an open source problem, and we have a better understanding of its cause:
How do we address this challenge? In part three of this blog series, we’ll talk about strategies for getting your arms around open source components in your software development process.
This is the second part of a blog series on vulnerabilities in third-party components and what enterprise developers can do about them. Read the first part: Why the Ransomware Attack on San Francisco Is Such a Big Deal. Read part three: 5 Ways to Keep Your Applications Safe From Vulnerable Components.