CVE-2021-44228 – Log4j zero day vulnerability, detection and Log4shell fix

Share on facebook
Share on twitter
Share on linkedin
Share on email
CVE-2021-44228

Log4j zero-day vulnerability is flooding the security updates/news everywhere. This issue has been named Log4shell and assigned CVE-2021-44228 (still awaiting analysis at writing).

 

Log4j vulnerability

 

CVE-2021-45105 (infinite recursion in lookup evaluation) – third and latest flaw

Severity: High / 7.5
CVSS:AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Affected versions: All versions from 2.0-beta9 to 2.16.0

CVE-2021-45046 (Log4j2 Thread Context Lookup Pattern RCE) – second flaw 

Severity: CRITICAL
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected versions: All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

CVE-2021-44228 (original log4shell vulnerability)

Severity: CRITICAL
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Affected versions: All versions from 2.0-beta9 to 2.14.1

This is a developing story; you must refer to direct sources for any updates (Apache advisory page). From Minecraft to Internet’s big corporations serving applications we all use daily, a lot of them are vulnerable. 

Why is this a big deal?

This Java logging library (Apache log4j) is found everywhere – from big corporations to SMBs. Log4j is heavily used within products/organisations, and therefore, the attack surface available is massive as of now. If you want to read about the related topics, then head to our popular posts: impacts of data breaches, types of malware, attack vectors to help you understand and assess your attack surface. 

Updates since the original bug

There has been two more flaws since the original log4j vulnerability was discovered. Apache foundation has issued patches to fix this high severity log4j vulnerability.

  1. CVE-2021-45105 (Third flaw) – The latest version 2.17.0 is rolled out to address a security vulnerability in the logging library that could be used to launch denial-of-service (DoS) attack. This bug affects all versions from 2.0-beta9 to 2.16.0. You can read more about DoS and DDoS attacks here.
  2. CVE-2021-45046 (Second flaw) – This is a second bug that was discovered from flaws in ‘fix’ of original log4shell vulnerability. This flaw could result in remote code execution due to the incomplete fix in CVE-2021-44228 (log4shell). The severity for this issue (originally a DoS bug) has been revised from 3.7 to 9.0 as the attack impact includes information leak and remote code execution in some environments and local code execution.

What’s wrong with log4j?

This 0-day in java logging library log4j2 allows anyone to launch a RCE (remote code execution) by logging a particular string.

Discuss your concerns today

How do I find if I am vulnerable? 

The best way to figure out this vulnerability in your environment is to get started immediately. You may need assistance from your technical teams to help you identify the vulnerable instances. There are also web pages created by vendors to identify the affected instances, however, the best way is for you to run the tests on your own.

Log4j vulnerability test

Log4j vulnerability test can be conducted in a number of ways based on the underlying operating system and the asset category.

A file system search inside JAR, WAR files using this command

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

You can search dependencies in use using this:

dpkg -l | grep log4j

The above search may return multiple results, which means all the copies require updating/fixing. 

If you found these hashes in your inventory, then YES, your systems are vulnerable
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

Search for the presence of jar files around this pattern “log4j-core-*.jar”.
On windows, this file could be located here:

c:\Program Files\\log4j-core-version.jar

On Linux, you can find the apps using this jar file

lsof //log4j-core-version.jar

You should look for the output of this command in /var/log

sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log

Grep/zgrep commands and YARA rules to identify exploitation attempts are detailed here:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Use DNS logger (dnslog.cn or webhook.site or canary tokens) and use it in your test payloads. DNS queries shall help to identify which hosts have triggered the vulnerability.

Log4rce, log4shell, log4j2, log4j are the popular hashtags to search further on this topic. 

Impact/Containment

It is sensible to adopt an assume breach mentality and review logs as a first step to finding impacted applications for suspicious activities in your environment.

Minecraft has come up with a timely response to this issue already. 

 

Log4j vulnerability exploiting demonstrating sensitive data leakage.

Mitigation – latest fix in log4j 2.17

Log4j v2.17.0 has fixed these identified issues. There have been about three patches released in a week to mitigate against the three discovered flaws. Workarounds are also available online.
Apache advisory
https://logging.apache.org/log4j/2.x/security.html

At network level:

  • Block unexpected outbound connections (LDAP, LDAPS, RMI), however, exploits can use random ports also.
  • Blocking URL strings containing “jndi:ldap” at WAF/application layer. 

An excellent update by NCSC has been added here.

Anti-virus detections developed by Microsoft for Defender users on windows, linux include cryptocurrency miners, cobalt strike beacons, Tsunami backdoors, PowerShell and exploitation on the attacker machine. These details along with mitigation of log4j vulnerability by Microsoft Security Response Centre is detailed here:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

Useful links:
An excellent write up by Lunasec
https://www.lunasec.io/docs/blog/log4j-zero-day/

CISA emergency directive

https://www.cisa.gov/emergency-directive-22-02

Ycombinator – Log4j RCE found
https://news.ycombinator.com/item?id=29504755

Security recommendations

These are general security recommendations to help you with ongoing improvements:

Credits

  • A vulnerability has been credited to Chen Zhaojun of Alibaba. 
  • The official log4shell logo displayed above is from @GossiTheDog . 

Log4j meme

This ‘log4j meme’ topic in itself deserves a separate section :). Obligatory memes found in online for log4shell are:

In respect to Log4j from ProgrammerHumor

When our vendor says they’re safe because they’re using Log4J 1.X from ProgrammerHumor

log4j infosec meme

Get in touch to discuss any security concerns for your business.