Log4j lessons learned: A blueprint for zero-day defence

Two years ago, the zero-day vulnerability, known as Log4Shell unwrapped itself spoiling holiday celebrations for many across the globe leaving organizations scrambling for a fix before it could be exploited. 

The vulnerability was discovered in Log4j, a widely used logging tool used by millions of computers worldwide running online services.  Its profound impact on IT environments has called for a fundamental shift in how organizations think about their security strategies.

Traditional security methods fall short with zero-day attacks

Log4Shell is one of the most famous zero-day vulnerabilities and it is only a matter of time until the next is discovered.

A zero-day is an unknown software vulnerability that poses a risk to a business's environment. They provide an attacker with leverage through the vulnerability to gain unauthorized access to a network, move laterally within it, steal data or compromise part of the system. The name comes from the fact that these vulnerabilities aren’t found yesterday or tomorrow or next week, they are found right the second they are executed, leaving zero time to fix them before they're exploited. This means that no patch or workaround is available to fix the vulnerability, making it very dangerous.  

Zero-day exploits are a significant challenge for organizations because they take advantage of unknown vulnerabilities in software, which means that traditional security measures may not be effective at detecting or preventing them. This makes it difficult for organizations to protect themselves against these types of attacks.

Why is the Log4J vulnerability still a concern?

While many initiatives, tools and solutions have been created to help improve the security posture for enterprises and governments, there are several factors that remain a concern around the Log4j vulnerability. These include:  

• Widespread adoption: Log4j is extensively used in various software applications and systems across different industries. Many times, Log4j is intentionally left in the code as it has been deemed to pose little to no risk of exploitation particularly if the application is not connected to the internet. It is scenarios such as this that show the ubiquity around Log4j and what makes it challenging to identify and update all instances promptly.
• Complex ecosystems: Many software systems have complex dependencies and may rely on older versions of Log4j. Additionally, many organizations often don't know about its presence in their environments (that they are using this library at all) -- because it's used in other software tools/frameworks, which complicates the process of finding it. Log4j is frequently included as a default log handler in enterprise Java applications and is commonly included as a component in various Apache frameworks. Millions of organizations use Log4j across their environments, often via indirect dependencies. This makes updating a component within a larger system a complex and time-consuming process.
• Legacy systems: Some organizations may be using older software versions or have legacy systems that are no longer actively maintained. These systems may be more vulnerable and may not receive timely updates.
• Third-party dependencies: Many software projects rely on third-party libraries, and updating these libraries can introduce compatibility issues or require significant development effort. 
• Lack of awareness: Not all organizations may be aware of the Log4j vulnerability or its potential impact on their systems. Awareness and proactive measures are crucial for addressing vulnerabilities promptly.
• Resource constraints: Some organizations may face resource constraints, making it difficult for them to allocate time and manpower to address the vulnerability promptly.
• Strategic decision-making: In some cases, organizations may make strategic decisions to prioritize other tasks over immediate vulnerability patching. This could be due to business considerations, risk assessments, or resource allocation strategies.

Prioritizing runtime security for zero-day vulnerabilities

No one knows or can predict when or where the next threat like this will hit and emerge in open source libraries, it can happen at any time. Some would say you are always under threat of zero-day attacks. 

Traditional vulnerability scanners are not effective. Runtime security controls are essential. As was the case with Log4j, over a span of 4 days (from December 6th, 2021, to December 10th, 2021), the Log4j vulnerability was exposed on open-source platforms. An official patch was available from Apache during this time. However, attackers could still exploit this vulnerability against users who hadn't applied the patch. This is because only after December 10th could scanning tools effectively identify this CVE in user environments.

Runtime control security plays a pivotal role in a zero-day defense strategy by detecting and blocking known and unknown malware, zero-day exploits, and internal threats that can’t be caught early on in the application lifecycle.  An effective runtime control solution can proactively prevent access and block threats without interrupting business continuity.

Image credit: Simon Lehmann/Dreamstime.com

Moshe Weis is CISO at Aqua Security.