Are you putting your business at risk by not patching these common vulnerabilities?

Patching is something that we all know we have to do. But it is easier said than done. In reality, patching can be hard due to problems around application compatibility, having adequate downtime windows, or more pressing business risks to manage. This can lead to some very serious software problems being left open and vulnerable to exploitation.

Here are three examples of common software vulnerabilities that existed for years with updates available, yet are still regularly targeted by threat actors.

Example #1 -- CVE-2020-1472

Zerologon is an unauthenticated privilege escalation that can be used to deliver full domain privileges. Based on our research, this vulnerability was used as part of attacks over the past four years - including at least 56 times in 2023.

Zerologon is a severe vulnerability in Microsoft’s Netlogon Remote Protocol, attributed to a flawed implementation of AES-CFB8 encryption. Incorrect use of the AES mode results in spoofing the identity of any computer account. Using a fixed initialization vector and accepting unencrypted sessions allows an attacker to impersonate a server and compromise the entire Windows domain. The attacker takes control over all the Active Directory identity services, establishes persistence, and from there can pivot to move laterally.

Example #2 -- CVE-2021-44228 is the Apache Log4j Remote Code Execution vulnerability commonly known as “Log4Shell.” Since it was discovered in 2021, it has been used by attackers to attempt exploits, and we saw 77 attacks in 2023. It was exploited by at least 10 Malware attackers, 26 Threat Actors, and 5 Ransomware creators during the year. Log4j was included in the “Top 12 Routinely Exploited Vulnerabilities in 2022” list, published by CISA.

Log4Shell is a severe vulnerability in Apache’s log4j Java library. The flaw exploits the ‘lookups’ feature of log4j, enabling an attacker to use a specially crafted input to trigger the execution of a remote Java class on an LDAP server, leading to Remote Code Execution (RCE).

This issue is highly dangerous if the user input containing specific characters is logged by log4j. It can trigger Java method lookup, resulting in the execution of a user-defined remote Java class on an LDAP server, leading to RCE on the server running the vulnerable log4j instance. Once exploited, attackers use that access to establish persistence and take further action against their attack pattern.

How long does it take to patch

Recently, we released the 2023 Qualys TruRisk Research Report. The data collected highlights some shocking realities. Chief among these is that even weaponized vulnerabilities remain unpatched for 30.6 days. Companies are faster around common services like Google Chrome or Microsoft Windows, where the average time to patch is 17.4 days, with an effective patch rate of 82.9 percent. In practice, Windows and Chrome are patched twice as fast and twice as often as other applications. But the browser and OS are simply only the beginning of the attack surface.

On average, vulnerabilities that can be weaponized took 19.5 days for patches to become publicly available. After their availability, organizations need time to test the patch, stage it, and promote it to a production fix. The gap between the vulnerability and patch deployment is approximately 11 days, if not longer. This represents a significant window of opportunity for threat actors.

The number of zero day attacks is a huge threat -- around 25 percent of security vulnerabilities were immediately targeted for exploitation, with the exploit published on the same day the vulnerability itself was publicly disclosed. We have seen internet-facing systems like file transfer applications attacked, indicating that threat actors are focusing on internet-facing business productivity tools for exploitation. While protecting these systems should be a priority, they can be overlooked as they are sometimes not treated as ‘critical’ to the business.

Why is there often a delay?

While security teams may have good reason to escalate the need to patch, organizations often have countervailing concerns that delay patching, and often for good reason. Patching can impact normal operations, require downtime, cause compatibility issues, and could even conflict with regulatory compliance obligations if significant changes require prior approval. More than this, changes need to be tested and validated, which can take some time. And as usual, organizations nearly always operate in resource constrained environments where they may not have the budget or manpower to promptly apply patches.

More than this, there are always lingering questions around necessity. It can be difficult to prove that a particular patch is required to avoid exploitation. While the timelines on exploitation are stark when acted upon by a threat actor, few vulnerabilities actually have active exploits. Less than 3 percent of vulnerabilities have weaponized exploits or evidence of exploitation in the wild, two attributes posing the highest risk. CVSS based prioritization results in 51 percent of vulnerabilities marked as high or critical which leads to ineffective, low-value prioritization.

The goal for CISOs is to help their organizations make risk-informed decisions that do three things. First, work in ways that make systems antifragile, leading to more rugged organizational outcomes. This means focusing on ensuring that systems are designed so they can take change and organizations can learn from feedback. Second, promote an understanding that patching needs to be prioritized to address operational risks of exploitation first, and then business as usual tasks thereafter. Targeting those vulnerabilities that are exploitable first is the best way to deliver a return on security investment. Third, partner with stakeholders in platform engineering, systems administration, corporate IT, and other groups to help them gain trust in the approach. Do this because, one day, you’ll need to have them snap a plan into action, which they’ll only do if they’re sure that you know the difference between what is urgent and what is important.

What needs to change?

While Security teams might have found it hard to get attention from the Boardroom in the past, now CEOs want to see action. More and more, organizational leaders understand that security risk is indeed business risk. This recognition makes it easier to get things started, but there are still challenges around how companies work and where goals might be different. Here are three things to consider.

First, set goals for patching with leaders across the organization. Make them organizational goals around security, not security goals for the organization. Ensure that when doing this, those goals are agreed to by leadership and that those goals are Specific, Measurable, Achievable, Relevant, and Time-Bound (SMART). Once done, bring the data to track achievement so that the right behavior can be encouraged and the wrong behavior can be addressed.

Second, recognize that ability to patch at a certain velocity (e.g. within the SLA) is partially determined by the system architecture, which is a function of cost and capability. If the architecture does not support the required patch outcome, focus on making the business investment case rather than chasing a patch problem that cannot be solved. Shift the focus to address what is blocking goal achievement.

Third, focus on communicating with data. Assessing risk and putting the business concerns into context, rather than the technical issues themselves, is essential. Building understanding about the wider context can help unlock investment that might be needed alongside deploying updates, so that problems can be addressed and solved rather than mitigations or stop-gap fixes applied that then stay in place for far longer than is safe.

Increasingly, CISOs are alone being held responsible -- sometimes personally -- for security gaps even though they do not control budget or decision-making for most of the organization. Given that, they must change the way that they work to find different and productive ways to bring the organization with them, focus on de-risking issues to the extent possible, and reducing friction so that security outcomes are achieved. While it's fair to say that the wider organization has to take guidance from the CISO and commit to action, security organizations also need to change so that they become business enablers as well as risk reducers.

Image credit: WrightStudio/ depositphotos

Matt Middleton-Leal is Managing Director for EMEA North, Qualys.