Background

Software is constantly changing. Application and package authors tweak and update existing code more or less continually to provide features, improvements, fixes and workarounds. Also, most software is constructed, at least in part, from third party or open source components or packages, such that large parts of the code are integrated by, but not actually written by, the developer or vendor of the overall application.

Given this continual change, and these varying sources of code, it is incredibly common for applications of all types to have as yet unknown security vulnerabilities.

These vulnerabilities come to light over time, either through discovery by the code authors, through the direct attention of researchers, or through bug reports, commissioned code reviews, in-house red team activities, and commercial penetration testing.

A vulnerability can’t be known about until it is discovered, by whatever means, and we encourage active measures (like vulnerability discovery tools and penetration testing) to find the vulnerabilities in applications that your own organisation might write or commission.

The main focus of this post, however, is the important process of learning about vulnerabilities and available software fixes, or patches, and actively managing the prioritisation and application of those, especially those patching security vulnerabilities.

Vulnerabilities

Unpatched vulnerabilities, both newly discovered as well as old, remain the most prominent attack method exploited by attackers, including ransomware groups.

A recent Spotlight Report on ransomware from Ivanti reveals how attackers are targeting these unpatched vulnerabilities and weaponising, in record time, the security gaps they create in order to instigate crippling attacks, in particular those involving ransomware.

Ransomware attacks can result in costly downtime and remediation, as well as ransom payments and reputational damage.

As well as leaving users open to ransomware attacks, the most severe vulnerabilities recorded last year as CVEs (Common Vulnerabilities and Exposures identifiers, being a published ID for an acknowledged vulnerability) resulted in issues including:

  • Data corruption, caused by out-of-bounds writes
  • Inadvertent sensitive information sharing, caused by cross-site scripting
  • Unauthorised memory leaks and information sharing, caused by out-of-bounds reads

In 2021, the majority of notified vulnerabilities were classified as having a ‘high’ availability, meaning that they were readily and easily exploitable by hackers.

Some vulnerabilities, known as ‘zero-day’ vulnerabilities, are so new that the code authors themselves have not even been made aware of them, yet they are already being exploited in the wild. Interestingly, the definition of zero-day has become diluted to mean a vulnerability that the code author is made aware of (but wasn’t already aware of) and therefore could be exploited before a patch is created, and until that patch is applied. But essentially, zero-day means that attackers could have been aware of the vulnerability before the software author was.

The QNAP (CVE-2021-28799), Sonic Wall (CVE-2021-20016), Kaseya (CVE-2021-30116), and most recently Apache Log4j (CVE-2021-44228) vulnerabilities were exploited before they made it to the National Vulnerability Database (NVD) for the public to become aware of. This trend highlights the need for vendors to disclose vulnerabilities and release patches as soon as possible so that these can be applied by end users.

Patching

The time between a vulnerability being publicly known and the software vendor releasing an update (aka patch) to address this is a risky time, leaving affected systems open to attack. Agile software vendors have an important role to play in ensuring that vulnerabilities are disclosed, and patches released, quickly and in priority order.

DevOps teams for affected systems need to learn about vulnerabilities quickly and prioritise mitigation steps, including testing and application of patches, once those are available, to close that door to a potential attack. So the process of reliably learning about vulnerabilities, and taking defensive steps for those, including patching, are key in reducing the risks of both hacking and ransomware attacks against your organisation.

According to Ivanti, “Organisations need to be extra vigilant and patch weaponised vulnerabilities without delays. This requires leveraging a combination of risk-based vulnerability prioritisation and automated patch intelligence to identify and prioritise vulnerability weaknesses and then accelerate remediation”.

An effective patch management process is an essential part of managing vulnerabilities. Your organisation needs to have in place a policy and reliable processes to enable the timely discovery of vulnerabilities in any part of your system or software, and/or notification that a patch is available. Only then can you actively prioritise the most important ones, and apply patches according to the severity of the vulnerability and priority of the patch.

There are great tools these days (such as snyk.io, dependabot, npm audit/yarn audit, Debricked, OWASP Dependency Check, and many other free and commercial services) for getting reliable notifications for just the software components that you use, alerting you to the existence of vulnerabilities, and whether there is a patch available for a component of your software.

A vulnerability discovery and management policy and procedure covering all of your software applications (discovering both those applications you write and those that you integrate, by way of a penetration test) will ensure that this process is completed in a timely, prescriptive, and defensive manner.

Managing the risk

Speak to us today about penetration testing of your own software application, and how to best set up and manage an effective patch management programme for monitoring and patching of all software vulnerabilities, and let us help you stay ahead of would-be attackers.