November saw the San Francisco Municipal Transport Agency targeted with a ransomware attack, with ticket machines across the city publishing the attackers demands for 100 Bitcoins (roughly £60,000) in return for unlocking its computer systems. Reportedly, the Muni was the target for an opportunistic hacker who discovered a vulnerability in its systems rather than political reasons as initially expected.
It appears the attacker scanned large swaths of the internet in search of several known vulnerabilities, including the ‘weblogic unserialise exploit'. One of the common deserialised class of vulnerabilities, this exploit is essentially like leaving the back door unlocked. It enables an attacker to run any code they want on their target's system.
There are a lot of applications across the globe with this vulnerability. SF Muni was the unfortunate target in this instance due to several security failings, including not updating software with security patches; using open source components with known vulnerabilities; and poor programming practices. However, the opportunity for hackers to leverage this vulnerability is rife, as Veracode's latest State of Software Security report indicated in its somewhat sobering results.
To be exploited by this vulnerability, an application needs two things: a vulnerable version of Apache Commons Collections (version 3.0 through to 3.2.1, or version 4.0), and to be practicing unsafe deserialisation (i.e. accepting a serialised Java object over the network and attempting to do something with it). And this combination is worryingly common.
Veracode research has found that about 50 percent of all Java applications have a vulnerable version of Apache Commons Collections, and about 25 percent practice unsafe deserialisation. And Java makes up a great population of enterprise and vendor-written applications, with half of those tested for this year's State of Software Security report written in Java.
How did this vulnerability come to be so widespread?
Java has a strong open source ecosystem, which includes foundational software like web servers, defect tracking systems, build servers, and more. Beyond the high profile open source software projects, such as Jboss and Jenkins, many more are available to address the everyday tasks that developers face.
One widely-used library is the Apache Commons Collections, which provides tools for working with groups of data in memory. This component is reportedly used in 3,160 artifacts, such as Spring and Hadoop, which in turn is then used in hundreds of other open source libraries and frameworks.
Going down five generations of software components from these initial artifacts, 80,323 are then found to have the Apache Commons Collections, which are then in turn used in millions of applications. Indeed, developers often don't choose Commons Collections components directly, but are introduced in their application by something else they did pick.
It's also rare for developers to update components once incorporated in software due to its cost. In the best case, it requires regression testing on all the parts of the application that leverage the component. In others, the updated component may not work correctly with all elements of the application, requiring it to be reworked or re-architected.
This certainly doesn't suggest that open source is inherently bad - commercial or enterprise-developed software is just as likely to be vulnerable. However, it does point to a lack of understanding around the security vulnerabilities in open source software, their gravity, and what steps developers can take to create securer code.
What can businesses do to avoid such an attack?
For more secure application development, a shift in how the development team thinks about open source components is required. How can this be achieved? These five steps are a practical starting point for organisations hoping to create a culture of secure coding.
Set a policy
The biggest challenge when dealing with security issues is often knowing where to start. Working out what activity is required to meet compliance goals can help compliance and security teams develop a corporate security policy that explicitly outlines which vulnerabilities require action, and how quickly. This can help raise awareness in the business of the threat of vulnerable components and provides a platform from which developers can explain how making those changes might impact time to market.
Build a baseline inventory
Creating an inventory of the open source components in existing applications ensures security teams can identify and respond to a newly announced vulnerability across the entire application portfolio. This can either be built by looking at source control or component repositories, while some static analysis providers may already create one for you.
Integrate security testing into the systems development lifecycle
Creating an inventory is only useful so long as it's up to date, which won't last long as development teams update their applications. Making sure the inventory is kept up to date is crucial if these security efforts will last in the long term.
Educate your development team
Some developers may not know they should monitor the open source components they use for security patches, or that the components they use may not be secure. Developer education massively improves secure coding practices, whether that's in one-on-one sessions or CBT courses. Even just identifying a few blogs to help keep developers up to date on vulnerabilities is a great first step.
Shift the mindset
There is no question of the benefit of open source for developers in driving time to market. But its value should be offset against its potential security costs, taking the form of regularly applying released updates to the open source library. Ultimately, this will reduce the work in the long term, when code must be scrapped and rewritten when the burden of applying patches gets too high.
Not only are cyber-criminals becoming more savvy to the potential of vulnerabilities, but the growth of ‘how to' videos online has meant anyone relatively technically minded can test their luck at exploiting application flaws. Some more ethically minded may try their luck at one of the growing number of bug bounty programmes. However, many will not.
With vulnerabilities rife, it is essential that organisations proactively identify and remediate the vulnerable components in their applications. SF Muni is just one organisation that has paid the price for its oversight of vulnerability remediation, and there are a massive number of organisations out there, which could to follow suit if they don't change their approach.
Contributed by Tim Jarrett, senior director of product marketing, Veracode