Holiday season is here again, yet as we relax, IT security professionals are completing their end-of-year tasks. Their eyes twitch and anxiety prevails as another December arrives.
Erin Stephan, Principal Product Marketer at Aqua Security suggests that their mild concern is understandable. Two years ago, the zero-day vulnerability, known as Log4Shell in the extremely popular Log4j logging framework, spoiling holiday celebrations for many across the globe and leaving organisations scrambling to fix it before it could be exploited.
Let’s discuss the lingering effects of the Log4j vulnerability in the software development lifecycle, why CISOs are still concerned about it, and how to protect environments against it and other zero-day vulnerabilities yet to come.
Why is Log4j still a concern, and why and why are we talking about Log4j 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 mentioned consistently and rightfully. 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, several factors remain a concern around the Log4j vulnerability. These include:
Widespread adoption: Log4j is used extensively 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.
Scenarios such as this 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 organisations often don’t know about its presence in their environments (or 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 included frequently as a default log handler in enterprise Java applications and commonly included as a component in various Apache frameworks. Millions of organisations 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 organisations 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 organisations are 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 organisations 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, organisations may make strategic decisions to prioritise 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 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.
A zero-day is an unknown software vulnerability that poses a risk to a business’s environment. These provide an attacker with leverage through the vulnerability to gain unauthorised access to a network, move laterally within it, steal data or compromise part of the system.
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 because they take advantage of unknown vulnerabilities in software, hence traditional security measures may not be effective at detecting or preventing them.
The Log4j vulnerability, Log4Shell is one of the most famous zero-day vulnerabilities and given its success, it is obvious why more continue to exploit them.
So, while a security team must strive for perfection, attackers need only persistence and luck to find that a still-exposed weakness. Log4j was such a significant vulnerability with such consequential impact that it is only a matter of time before the next Log4j occurs.
Detect, mitigate and remediate zero day vulnerabilities with Aqua.
No-one knows, or can predict, when or where the next threat will hit and emerge in open source libraries. It can happen at any time. Some would say we are always under threat of zero-day attacks.
How can we protect against zero-days? Traditional vulnerability scanners are not effective. Over a span of four days (from December 6th, 2021 – December 10th), 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. Only after December 10th could scanning tools effectively identify this CVE in user environments.
So we need to have runtime security controls as part of our security strategy. One of the effective runtime controls is drift prevention.
This solution is built to help security teams to:
# 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 unauthorised changes to running workloads to stop runtime attacks at any point.
# Automatically block any lateral movement or escalation within or between cloud workloads.
# Identify and & block anomalous behaviour in running containers.
# Maintain business continuity by running code that should run and block everything else without interrupting business continuity.
My comoany can help customers to secure their applications against advanced threats such as zero-day attacks with robust runtime protection. To learn more about Log4j and a zero-day defence strategy, join us for our webinar Log4j lessons learned: a blueprint for Zero-Day defence.
Learn how our platform can help to scan for Log4j lurking in an environment or other potential zero-day vulnerabilities. Discover how we can help to prevent access to an environment proactively and block threats before the business is compromised.
