Last Update: 04-Jan-2022 09:20

Between the 9th and 10th of December, a new critical vulnerability impacting a popular logging library named log4j (version 2) has been published. The vulnerability has been scored 10.0 out of 10 because it allows a Remote Code Execution with a simple string placed in a logged parameter.

There are a lot of articles explaining the details about it (one for example is available here). We'd like to summarize here some of the informations available in these articles with some suggestions from our side, to manage the issue.

Who is impacted

Since the log4j2 library is widely used in all Java-related projects, we can assume that all the Java applications needs at least to be checked and verified. A lot of Open Source and Proprietary projects/products already stated they are vulnerable and almost all are releasing communications about it.

Affected Apache log4j2 Versions

all log4j-core versions >= 2.0-beta9 and <= 2.14.1 (also 2.15.0, 2.16.0 and 2.17.0 has been found vulnerable to other issues)

NOTE: version 1 could be vulnerable to other older RCE (like CVE-2019-17571), and another CVE similar to Log4Shell has been confirmed (when JMSAppender is used, which is not the default).

Since things are constantly changing, we try to summarize here below the current situation. We are dealing with different CVE:

• CVE-2021-44228 (CVSS score: 10.0) - Remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1 (Fixed in version 2.15.0)
• CVE-2021-45046 (CVSS score: 9.0) - Information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (Fixed in version 2.16.0)
• CVE-2021-45105 (CVSS score: 7.5) - Denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (Fixed in version 2.17.0)
• CVE-2021-4104 (CVSS score: 8.1) - Untrusted deserialization flaw affecting Log4j version 1.2 (Upgrade to version 2.17.0)
• CVE-2021-44832 (CVSS score: 6.6) - RCE via JDBC Appender when attacker controls configuration (Upgrade to version 2.17.1)

Permanent Fix

WARNING: Updated versions 2.15.0 and 2.16.0 has been found vulnerable (see previous paragraph). Also 2.17.0 was reported to be vulnerable to CVE-2021-44832

The recommended action is to upgrade to 2.17.1 or later

Mitigations

We recommend to update to the latest release: it's the only way to fix all the above reported CVE. Consider the mitigations below only if the upgrade is not possible

There are some "official" mitigations available in several articles which are:

The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [IN SOME CASES (ES. LOGSTASH) SETTING THE PARAMETER IS NOT ENOUGH. BE SURE TO TEST IT FOR YOUR ENVIRONMENT OR FOLLOW VENDOR GUIDELINES. THIS DOES NOT MITIGATE CVE-2021-45046 and CVE-2021-45105]

If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:

• Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 (only works on versions >= 2.7) [THE PREVIOUS ONE IS NOT RECOMMENDED. USE IT JUST AS LAST RESORT: IT'S EASY TO MISS AN ENTRY OR TO INTRODUCE A REGRESSION IN THE FUTURE]

• Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behavior [YOU CAN USE https://github.com/corretto/hotpatch-for-apache-log4j2 TO AUTOMATE THE PROCESS. THIS DOES NOT MITIGATE CVE-2021-45105]

To mitigate CVE-2021-45105 follow Apache suggestions

Additional Mitigations and Use Cases

This is a very serious issue (may be one of the biggest of last years) and it must be addressed as soon as possible. The pervasivity of the package make this a bit difficult. We suggest to focus the efforts at the beginning on "Internet facing" applications and move then to the internal one. But do not miss this second step: even an internal application could be abused, so do not feel safe because of this, just treat it as "less urgent".

Suggestions:

• stay focused on application vendors bulletins regarding the CVE. Most of them are releasing updates (see below). The aforementioned Mitigations can not be applied on vendors package without the risk of impacting the application itself. Do it only if you accept this risk.
• as a quick mitigation, if your vulnerable application is exposed on Internet, you can remove this exposure
• you can apply "Security Devices" mitigation on your Firewall, WAF, IPS: it can be done but do not consider this as a permanent solution: signature can be evaded, HTTPS inspection is required, etc so the mitigation itself could be not so effective
• if you can not remove the exposure of your vulnerable application, you can limit its capability to reach the Internet: the external exploit requires Internet access, if your system does not need it, you can remove this possibility (considering also DNS queries).
• since one of the most important thing is identify the version of the installed log4j, some utilities can help in doing that: Scan for log4j, Lunasec log4shell.
• some are reporting that the log4j vulnerability can be exploited only on certain version of Java, so they suggest to upgrade the Java package. We do not recommend this solution as a long term fix for this issue. The safe way is to upgrade the log4j itself
• if you are doing tests with the PoC kits you found online, always consider the leakage part: if you use external services to verify the vulnerability, remember that you are disclosing to them that you are vulnerable
• if you find your environment already patched, be sure you applied it. Some attackers are patching the vuln after they implanted backdoors.
• is strongly suggested to review all the logs of the last days to identify possible successful exploitation of the vulnerability

Need help? Suggestions?

If you need additional help or you want to suggest improvements to this page you can reach out at the following address: security-advisory_at_sorint.it

Vendors communications

This is not a comprehensive list and it will be updated with new entries when available.

Access Vendor List with Status Updates