Another December is upon us, stores are full of shoppers, lights are illuminating cities, towns and cul-de-sacs as radio stations bombard listeners with the continuous rotation of holiday music. Yet amongst all this merriment sits the IT security professional behind their screen completing their end of year tasks. Their eyes slowly twitch, and they fill with anxiety as another December is here.
This mild anxiety is understandable. Two years ago, the zero-day vulnerability, known as Log4Shell in the extremely popular Log4j logging framework unwrapped itself spoiling holiday celebrations for many across the globe and left organizations scrambling to fix it before it could be exploited.
In this blog, we will discuss the lingering effects of Log4Shell in the software development lifecycle, why CISOs are still concerned about it, and how to protect your environments against it and other zero-day vulnerabilities that are yet to come.
Why is the Log4j vulnerability still a concern?
Why are we talking about Log4j vulnerability when it happened two years ago? Well, according to a July 2022 report from the U.S. Department of Homeland Security’s Cyber Safety Review Board on the Log4j vulnerability, the bug will remain an issue for a decade or more. Additionally, when CISOs are asked about what concerns them Log4j is consistently mentioned, and rightfully so as even our own research still points to the Log4j vulnerability as it continues to resonate across environments.
Efforts to mitigate the Log4j vulnerability involve updating to patched versions of Log4j, but the process continues to be complex, especially in large and interconnected systems. 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. This includes:
- 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.
In other words, the Log4j vulnerability is still out there waiting…waiting for the team to miss it in the ecosystem because they are constrained on resources, or for the right connection made to a legacy system with interesting data to be mined, or worse the lack of awareness of a developer of its potential impact.
Zero-day vulnerabilities, One exposed weakness
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 vulnerabilities can affect any piece of software on a device – including operating systems, applications and web browsers. 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. Log4j is one of the most famous zero-day vulnerabilities and given its success, it is obvious why more continue to exploit them.
So, while security team must strive for perfection, attackers need only persistence and luck to find that one still exposed weakness. Log4j was such a significant vulnerability with such consequential impact that it is only a matter of time for when the next Log4j happens.
Detect, mitigate and remediate zero day vulnerabilities with Aqua
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 (even on your weekend, Christmas holiday, etc.). Some would say you are always under threat of zero-day attacks.
How can you protect against zero-days like the Log4j vulnerability? Traditional vulnerability scanners are not effective. 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. That’s why you need to have runtime security controls as part of your security strategy. One of the effective runtime controls is drift prevention from Aqua.
Drift prevention is built to help security teams:
- Detect and block known and unknown malware, zero-day exploits, and internal threats that can’t be caught early on in the application lifecycle.
- Enforce immutability by preventing code injection and unauthorized changes to running workloads to stop runtime attacks at any point.
- Automatically block any lateral movement or escalation within or between your cloud workloads.
- Identify & block anomalous behavior in running containers.
- Maintain business continuity by running code that should run and block everything else without interrupting business continuity.
Here is a quick example of how drift prevention works within the Aqua platform. Below is an image of the incident screen, it shows all the runtime findings in the environment, whether behavioral or based off a runtime policy to control drift in the running of the application.
Image 1 – Incident Screen showing all the runtime findings in the environment
This next image shows the timeline of events leading up to the drift event. The user can see that a privilege change was executed and access to the container gained, triggering the alert and containment.
Image 2: Timeline of a drift event, showing the dropping a new executable and trying to execute it
This is a small example of how Aqua helps customers secure their applications against advanced threats such as zero-day attacks with robust runtime protection. To learn more about Log4j and a zero-day defense strategy, join us for our webinar Log4j Lessons Learned: A Blueprint for Zero-Day Defense. See firsthand how the Aqua Platform can help you scan for the Log4j vulnerability lurking in your environments or other potential zero-day vulnerabilities. Discover how Aqua can help to proactively prevent access to your environment and block threats before your business is compromised.