Apache Log4j Flaw: Best Practices to Respond to the Vulnerability of the Decade

If ransomware attacks throughout 2021 weren’t damaging enough, businesses worldwide are now bracing for a massive impact after security geeks dug out a critical zero-day flaw in the open-source Apache Log4J Shell logging tool. Having earned the tag of ‘the vulnerability of the decade,’ the flaw, if exploited, could bring down around 40% of businesses worldwide. But like with every other code flaw, there are mitigations available to temper the storm. Let’s look at ways your organization can duck the ball in the days to come.

The Apache Log4j or Log4Shell zero-day vulnerability (CVE-2021-44228), first discovered on December 9, involves an exploit affecting Log4j, an open-source Apache library for logging errors and events in Java-based applications. Morphisec’s CTO Michael Gorelik says the exploit “allows threat actors to take over compromised web-facing servers by feeding them a malicious text string.” Though fixing vulnerabilities like this are relatively simple, the scale at which Log4j is used by software developers worldwide presents an immense challenge.

The major challenge we are referring to, regrettably, is cyber hygiene. The most well-known enterprises across the globe, let alone tens of thousands of SMBs, routinely run third-party software and applications that are either unpatched are too old to be updated. In most cases, visibility over devices and applications gets affected as organizations onboard new ones by the hundreds. Sometimes, IT teams are too stressed to check every application for code errors or flaws as they race to resolve the existing backlog of tickets.

The good news is that the scale of cyberattacks in recent years has forced decision-makers across industries to start thinking about cybersecurity and invest more money in skilled professionals. Of late, there has been a tremendous uptick in the onboarding of network visibility, identity management, network monitoring, cloud security, and application security solutions. A lot of ground still needs to be covered. Still, considering that cybersecurity is among the top concerns for IT decision-makers now, it can be expected that organizations will respond better to the discovery of the Log4j flaw than they would have five years ago.

Here, let’s look at some essential steps your IT security team must take now to ensure malicious actors do not take over your web-facing servers and applications by exploiting the critical zero-day flaw.

See More: Log4j Flaw: Critical Zero-day Leaves Millions of Systems at Risk

 

Get Started With a War Plan

Ric Longenecker, CISO at Open Systems, says that we’ve already gotten a taste of the potential impact of the Log4j vulnerability with Kronos Global being hit, and we should be wary of other potential organizations at risk and how it may impact the ability to distribute paychecks before the holidays. “Some are calling Log4J the vulnerability of the decade. Forty percent of organizations are reportedly being targeted, and it is wormable,” he says.

“Companies must continue taking this very seriously and must ensure round-the-clock monitoring. We strongly encourage all companies to seek out a trusted security partner to help protect themselves against a potential attack. Log4J might be a doorway into an organization that’s used as a foothold, but not executed on for several months. When that time comes, enterprises may be able to avert a severe compromise or ransomware attack if proper steps are taken beforehand.”

As per Longenecker, your IT security team should take the following steps urgently:

1. Gather a team with an IR lead to identify potential software and third parties, then search code for vulnerabilities.
2. Think about externally facing (websites, servers) systems and prioritize.
3. Make a patching or remediation plan.
4. Determine how to monitor, or report up, and respond to any potential incidents.

Chris Dobrec, VP of product at Armis, also details how scary the vulnerability is, the damage that malicious actors can cause, and best practices for preparing for any eventuality. “The impact is massive and far reaching as, in this case, the Log4j library lurks in both obvious and not so obvious places. It is so ubiquitous and used in such a wide array of assets, that it’ll take years to get rid of it and in reality a large long tail of assets some of which will never be patched,” he says. 

Here’s a short Q&A with Dobrec that should prepare you well for what lies ahead:

What sort of potential impact could result if these attacks are successful?

This is a critical, easily exploited, Internet-facing remote code execution (RCE) that threat actors actively use. An attacker who can control log messages or log message parameters can execute arbitrary code. The exploit lets the attacker load arbitrary Java code on a server, allowing them to take control. We’re already seeing attack attempts in hundreds of our clients and are continuing to see new attacks every day with the top 3 types of the targeted devices; Physical Servers (42%), Virtual Servers (27%), and IP Cameras (12%). We’ve also spotted attack attempts on manufacturing devices (HMI Panels & Controllers) and Attendance Systems (Kronos).

What do organizations need to do to protect themselves from Log4j? 

Active asset management and security are critically important here – don’t wait for the problems to happen, but manage them continuously. This starts with gaining complete visibility of your environment. The fact that the library exists in so many places means you need to look across everything in your environment – IT, OT, IoT, IIoT, IoMT devices and their associated applications and services.

Are we likely to see the impact from Log4j intensify in the days and weeks ahead? If so, why?

Yes. This all comes back to the ubiquitous use of the Log4j library and the relative ease of the exploits, so we will see this continue to intensify. However, the long tail is really troubling and will likely take years to get rid of. What about the devices that are already shipped and in the supply chain that are not yet deployed? What happens when IoT devices that contain the vulnerability currently sitting on your loading docks or in Amazon warehouses get plugged into your network? You need to be ready and continuously monitor your environment.

 

Ilkka Turunen, field CTO at Sonatype, says that the only mitigation path is to patch software in the immediate term, and speed is absolutely critical. Every minute counts as bad actors are constantly scanning for organizations using the vulnerability. In the longer term, organizations must create and continuously update a software bill of materials and conduct software composition analysis to determine the potential risk of components and the threats they might deliver.

Todd Carroll, CISO at CybelAngel, says that organizations running Apache Log4j should check for vulnerable versions in their environment and locations. “They should block external-facing applications that use the vulnerable library until an updated version is released. Whenever possible, they should install the most recent version of Log4j and monitor for vendor patches as they become available. In addition, they should monitor traffic to and from application workloads that may be exploited due to this vulnerability.”

See More: Top Five Cloud Disaster Recovery Solutions for 2022’s Post-Pandemic, Cloud-First World

Apply Proper Mitigations

The first and the most important thing your organization needs to do now is to check whether any applications are using the Log4j 1.x series of tools to log errors and events. The Apache Foundation says that even though the critical flaw doesn’t affect the Log4j 1.x series, the latter has reached the end of life, is no longer supported, and will not be fixed even if any vulnerabilities are found. All users of Log4j are advised to upgrade to Log4j 2 to obtain the latest security fixes. 

If your developers are running any Apache projects, the bright thing to do is to check the listOpens a new window of Apache projects impacted by the Log4j vulnerabilities. Your security team should also check if they updated their Log4j tools correctly. Apache Logging Services released an initial fix, named Log4j 2.15.0, to address the most severe vulnerability but subsequently released Apache Log4j 2.16.0 on December 13 to address the most recent CVE. It is important to update to Log4j 2.16.0 as the previous update did not protect against DDoS attacks targeting some non-default configurations. 

Rahim Jina, the COO and co-founder of Edgescan, has aptly described the importance of regularly checking for available fixes for unknown vulnerabilities. “In the race to fix and issue patches, often the full extent of an issue is not known when patching takes place, and ‘incomplete’ fixes are issued. It would not be surprising if more vulnerabilities are found to be linked to patches already issued,” he says.

 

Build a DevSecOps Culture

Curtis Simpson, CISO at Armis, says that organizations that manage their product and product environment through applied DevSecOps have a significant benefit over those traditionally managing virtual or physical infrastructure. A DevSecOps approach, which is already in place, can help them rapidly establish and test a new build with the latest patch across all vulnerable workloads. Once tested, the existing build can be eliminated and replaced with the patched build. Depending on how the business application has been architected, such an approach can also drastically reduce or even eliminate the need for application downtime.

“In terms of the actions that organizations applying a DevSecOps approach to operations should execute, it comes down to establishing or honing your ability to rapidly apply, test, and deploy software updates across all relevant workloads in your virtual environments without the need for downtime or at least a level of downtime that could trip relevant SLAs. 

“Today, it’s Apache Log4J. Months from now, the next critical exposure will apply to another commonly used software package/library. It’s not about optimizing the ability to update one software package across all workloads with limited human input; it’s about honing the ability to update any or all software packages across all impacted workloads in the cloud within moments to hours, all with limited human involvement and a high degree of confidence,” he says.

Has your organization started patching the Log4j flaw yet? Let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!