CVE-2017-5638 is a remote code execution bug that affects the Jakarta Multipart parser in Apache Struts, an open source application framework for developing Java EE web applications. Remote code execution bugs are generally extremely serious, and for that reason, when the vulnerability was discovered, the Apache Foundation recommended that any developers or users of affected versions of Struts upgrade to later versions that had been patched to close the vulnerability.
Unfortunately for Equifax, news of the bug never reached the person or persons responsible for applying patches, so the software in use in the company was never patched. And as if that were not bad enough, a scanner used by the company to detect software with known vulnerabilities reportedly did not detect the unpatched versions of Struts and issue an alert to the relevant administrators either.
As a result, hackers soon exploited the company’s vulnerable systems to infiltrate the organization and made off with sensitive personal records – including social security numbers – of more than 140 million people in the U.S., Canada, and the UK.
The failure by Equifax to ensure that its systems were patched promptly to prevent hackers exploiting a known (rather than zero-day) vulnerability highlights the importance of having an effective patch management system in place. The overwhelming majority of hacks are caused by organizations running software that has known vulnerabilities that should have been patched, and in that sense they are easily preventable. In fact an HP study, Cyber Risk Report 2015, found that 44 percent of known breaches in 2014 were caused by vulnerabilities that were between two and four years old that had not been fixed.
Patch management features
Most patch management solutions include three features: Inventory scanning to detect what software is present in an organization (authorized or otherwise); patch status detection to check that operating systems and applications are fully patched and flagging any that are vulnerable or for which the patch status is unknown; and patch deployment to collect, configure and apply software patches to applications that require them in the appropriate order to avoid conflicts or to undo a previously applied patch.
What’s clear from the fallout from the Equifax hack is that an effective patch management system would have prevented the incident: A thorough vulnerability scan would have detected the unpatched and vulnerable software and made it straightforward for the patches to be deployed. Ideally, an administrator dashboard would have highlighted the fact that the software had not been patched and prompted a suitably senior administrator on a continuous basis until the patches had been deployed.
There is no shortage of good patch management solutions. Microsoft allows many organizations to update their IT infrastructure using System Center and Windows Server Update Services, and there are also many other third-party patch management solutions from the likes of SolarWinds, Ivanti, Kaseya, and Flexera.
Open source patch management solutions
These solutions all involve proprietary software, but many organizations prefer to use open source solutions whenever possible. Apache Struts is itself open source software, but what’s notable is that when it comes to open source patch management solutions which might have prevented the data breach, there are very few options.
That’s not to say that none exist at all. One possible candidate is OPSI – Open PC Server Integration – which bills itself as “an open source client management system to manage heterogeneous environments.” The code is under active development, and the latest test version of the code was released on Nov. 20, 2017. Commercial support is available from the project’s sponsor, a German company called UIB.
And a quick search of GitHub reveals just a handful of possible solutions such as vFense (“an Open-Source Cross-Platform Patch Management and vulnerability correlation tool”) which has not been updated for several years, or more actively maintained projects such as LLNL/MacPatch, which is specifically targeted at OS X systems used in enterprises.
But the truth is that there are not many realistic options for anyone looking for an open source patch management solution with a vibrant community around it and commercial support available when necessary.
Linux comes with patch management
So why are there so few open source patch management solutions? Josh Zelonis, a senior analyst at Forrester, suggests that Linux lies at the root of the answer. “Open source software tends to mean Linux, and the distributions usually have package managers for simplifying patch management,” he points out. “This is probably to a greater extent than closed source software because you’re using YUM or APT or other package fetch programs that in theory will handle all your applications, not just the Google ones, or Microsoft ones, or Adobe ones, et al.”
This is similar to the way smartphone operating systems typically allow users to update their applications easily, although there is also an important difference. “The distributions will usually build and test packages to make sure an update doesn’t cry havoc with your infrastructure and let slip the dogs of war,” Zelonis says.
That’s true, but using YUM or APT to get updates and install them is by itself a solution that doesn’t scale well or include the level of automation that most enterprises require.
DIY patch management
A deeper search of GitHub also reveals several (old) generic patch management cookbooks and playbooks for open source automation deployment and configuration management engines such as Chef, Puppet and Ansible. That’s significant because all three of these open source applications can be used to deploy patches automatically to applications that they know about. There’s a catch though: This is not a straightforward undertaking, and it probably involves a little coding and a great deal of time – initially at least – to get it set up right. It’s certainly not as quick and efficient as a packaged offering.
An open source patching solution built using Chef, Puppet or Ansible may be able to handle the patch deployment function of a full patch management solution, but that still leaves the challenge of how to create an inventory of all the software running on the network and how to establish if any of it has known vulnerabilities that need to be patched.
Open source vulnerability scanning
Maintaining a list of vulnerabilities (and discovering new ones) is a significant task, and probably because of this, many of the early open source vulnerability scanners such as Nessus and SAINT have morphed into proprietary products.
But some open source scanners do exist, and one of the best known ones is a project called OpenVAS. This is a code fork from the last version of Nessus that was open source, and it is maintained and updated on a daily basis. Another example is an open source project called Clair, maintained by CoreOS, which scans applications running inside containers for known vulnerabilities.
So while the most convenient option for patch management may be to use a proprietary solution, it is possible to use open source software to achieve somewhat similar results. The downside is that it is likely to involve considerable work to get the various components to function anything like a complete patch management solution. It’s also likely to be more complicated to operate, and that’s worth keeping in mind because if a patch management system fails to work as it should, the consequences can be catastrophic – as Equifax has learned.
