The Log4j Vulnerability is Likely to be a Significant Threat for Years

Until last month, Log4j was simply a popular Java logging framework; one of the numerous components that run in the background of many modern web applications. But since the zero-day vulnerability (CVE-2021-44228) was published, Log4j has made a huge impact on the security community as researchers found that it’s vulnerable to arbitrary code execution.

As you dig into this story, you’ll hear Log4j and Log4Shell, so to clarify upfront, Log4Shell is a software vulnerability in Apache Log4j 2, a popular Java library for logging error messages in applications. The vulnerability, published as CVE-2021-44228, enables a remote attacker to take control of a device on the internet if the device is running certain versions of Log4j 2.

What that means is Log4Shell affects Log4j or Log4j 2. So, what is Log4j? It’s an open-source logging framework in Java that developers use to track software activity in cloud and enterprise apps. That means it’s used in a vast number of things, Java is on billions of systems including IoT devices, medical kits, and more.

To summarize how Log4j was uncovered, on December 9, 2021, a zero-day vulnerability in the popular Log4j logging framework for Java was first published. NIST has given this vulnerability (CVE-2021-44228) a score of 10 out of 10, which is highly critical and significant as NIST rarely scores vulnerabilities a 10. Since this vulnerability allows remote code execution and can easily be exploited, there are already dozens of PoCs or proof of concepts for exploit kits available online for bad actors to buy and use. Further, there are numerous reports that it’s being massively exploited in the wild.

To help make sense of the events around this critical vulnerability, here is a basic timeline:

• November 26: The CVE ID for the vulnerability is reserved.
• December 1: The first known exploit of the vulnerability is detected in the wild.
• December 10: The CVE ID is published and a patch is released.
• December 11: At 14:24 CET, ESET’s Network Attack Protection module receives a detection update to cover this vulnerability.
• December 13: Log4j version 2.16.0 is released after the fix in version 2.15.0 was found to be incomplete and still put some systems at risk.
• December 18: Log4j version 2.17.0 is released to address a vulnerability (CVE-2021-45105) that could be exploited for denial-of-service (DoS) attacks.

A month into the battle to eliminate the vulnerability, many IT security leaders believe that attempted exploitation of the Log4Shell vulnerability will likely continue for years and will become a favorite target for penetration testers and nation-state-supported threat actors. Sophos added in its blog last week “The urgency of identifying where it is used in applications and updating the software with the patch remains as critical as ever.”

 

 

The real fear for most organizations is that attackers may have already gained access to their networks and will simply sit, wait, and monitor the network for an optimal time to strike.

In the meantime, many security organizations have developed tools to help identify the vulnerability. Here is one from Trend Micro that has become fairly reliable – https://log4j-tester.trendmicro.com/

 

Why is Log4j Viewed as Such a Critical Vulnerability and Threat?

Microsoft had immediately warned organizations about the high potential for threat actors to expand the use of the recently discovered remote code execution (RCE) vulnerabilities in the Apache Log4j logging framework to numerous types of attacks.

The company said its security researchers had observed a large amount of scanning activity and exploitation attempts targeting the flaws in the last weeks of December by what it assumed were threat actors searching for the vulnerability.

 

 

Many attack groups — including nation-state actors and ransomware groups—have added exploits for the vulnerabilities to their attack kits and are using them to establish reverse shells, drop remote access toolkits, and carry out hands-on-keyboard attacks on vulnerable systems. Backdoors and reverse shells that Microsoft has observed being deployed via the Log4j flaws include Bladabindi, HabitsRAT, Meterpreter, Cobalt Strike, and PowerShell.

Again, Apache Log4j is a widely used open-source logging component that is present in almost every environment where a Java app is used. So, when we said billions of devices earlier in the post, this includes Internet-facing servers, backend systems, network components, third-party applications, services that use those applications, in cloud environments, and in industrial controls systems and SCADA systems.

There’s also a script available on Github to detect the presence of the vulnerability on Linux and Windows systems. The vulnerable versions of Log4j 2 are all Log4j-core versions from 2.0-beta9 to 2.14.1. The best advice is to update your dependencies to use the latest version, 2.15.0. Earlier 1.x versions of Log4j aren’t subject to this vulnerability but they have their own issues.

 

Apache Log4j is Easily Exploitable by Threat Actors

On December 9th, when the Apache Software Foundation disclosed the critical RCE (CVE-2021-44228) vulnerability (Log4Shell), the security community immediately understood that the vulnerability provided attackers a relatively trivial way to gain complete control of vulnerable systems. The disclosure prompted widespread concern and urgent warnings from security experts about the need for organizations to quickly update their Log4j version because of widespread scanning activity and exploit attempts. Less than a week after the first flaw was disclosed, the Apache Foundation disclosed a second flaw in Log4j (CVE-2021-45046) and then a few days later, a third one (CVE-2021-45105).

 

 

The widespread prevalence of the flaw as well as the ease with which it can be exploited, has attracted the interest of a broad range of threat actors. In the weeks since the first flaw was disclosed, numerous vendors have reported observing ransomware operators; cryptocurrency miners; nation-state actors from countries including Iran, Turkey, China, and others attempting to exploit the flaws.

The actors that have been observed exploiting the flaws include the China-based Hafnium group that was responsible for carrying out zero-day attacks against the so-called ProxyLogon set of Exchange Server flaws last year. Other actors exploiting Log4j flaws include Phosphorous, an Iranian ransomware operator, and Aquatic Panda, a China-based actor that CrowdStrike thwarted in the middle of a targeted attack on a large academic organization a few days after the first flaw was disclosed.

In that attack, CrowdStrike’s researchers observed, the threat actor attempted to execute Linux commands on the victim organization’s Windows host, says Param Singh, vice president of CrowdStrike’s Falcon OverWatch threat-hunting service. When the attempts to execute Linux commands failed, the threat actor quickly shifted to using Windows native services or so-called living-off-the-land binaries (LOLBins).

 

Nearly All Major Organizations Will Need to Patch and Monitor?

If unpatched, many enterprise applications and cloud services written in Java are also potentially vulnerable to the flaws in Log4j. The open-source logging library is believed to be used in some form; either directly or indirectly by leveraging a Java framework. The framework is used by nearly ALL major, large organizations.

However, at the time of writing this post on January 30th, “Sophos believes that the immediate threat of attackers mass exploiting Log4Shell was averted because the severity of the bug united the digital and security communities and galvanized people into action.”

Few major attacks using Log4j have been disclosed to date, however, on December 20th, the defense ministry in Belgium disclosed that a portion of its network was shut down in the wake of a cyber-attack. The attack had indeed resulted from an exploitation of the vulnerability in Log4j, the defense ministry said. In addition, hackers including Chinese state-backed groups had launched more than 840,000 attacks on companies globally in the first week after the vulnerability was uncovered. The issue is there are countless Log4Shell attack vectors that need to be addressed. Cybercriminals like the infamous Conti ransomware gang known for making millions from using a ransomware-as-a-service model have already been exposed using Log4Shell for lateral movement in organizations.

 

Conclusion

Organizations should take the Log4j situation to take a step back and answer the following fundamental security and risk management questions:

What is our plan?

Currently, most organizations will be responding to software found to be vulnerable, or to cyber-attacks. There will likely be a migration to a more methodical approach which first identifies how the organization is affected and then rectifies any problems found. Large organizations and enterprises will need a phased approach to manage this issue over many weeks or months, with teams able to sustain a response over the medium term.

How will we know if we’re being attacked, and can we respond?

While researchers are trying to various ways Log4j is providing attackers access to networks, attackers themselves are certainly working to exploit the vulnerability as we suggested. Would your teams know if your organization was being targeted, and be ready for an appropriate response?

What visibility do we have to our software, servers, and critical data?

Teams are hopefully trying to find instances of software, and of Log4j itself as we also said earlier. This task will be easier on corporately managed assets, but less so on unmanaged assets including any SaaS-based asset or personal device that can access the corporate network.

How are we addressing shadow IT/appliances?

As well as fixing corporately managed assets, teams need to be thinking about how they will discover things that may have slipped through the net and are not centrally managed, sometimes called ‘shadow IT’, which has become prevalent since the Covid epidemic.

Do we have significant 3rd Party Risk?

If your organization is dependent on any particular key suppliers that have access to your network. Do 3rd parties handle crucial software that runs your business or remote admin access?

 

To Learn More About How to Defend Against Malware Attacks or If You Have Been Attacked Please Call Us – as Always, We Are Happy to Help – 1 (888) 982-0678.

You Can Also Fill Out Our Contact Us Form Here to Talk with a Security Specialist – https://secureops.com/contact-us/