Introduction
A critical remote code execution vulnerability in Apache Log4j is actively being exploited in the wild. Log4j is a widely used Java-based logging audit framework within Apache. The vulnerability is due to insufficient input validation and sanitization, which allows any user input that gets logged to lead to remote code execution. This vulnerability is also known as Log4shell, and it has been assigned the CVE number (CVE-2021-44228). This article discusses how FortiEDR protects against the post-exploitation of Log4shell.
Log4j
Log4j is a tool to help the programmer output log statements to a variety of output targets. In case of problems with an application, it is helpful to enable logging to locate the problem. With log4j, it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that log statements can remain in shipped code without incurring a high-performance cost. It follows that the speed of logging (or rather not logging) is capital.
At the same time, log output can be so voluminous that it quickly becomes overwhelming. One of the distinctive features of log4j is the notion of hierarchical loggers. Using loggers it is possible to selectively control which log statements are output at arbitrary granularity.
CVE-2021-44228
Apache Log4j2 versions 2.14.1 and below Java Naming and Directory Interface (JNDI) features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. A remote code execution vulnerability exists where attacker-controlled log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
FortiEDR Real-time Threat Protection
FortiEDR blocks post-exploitation activity associated with adversaries attempting to use this vulnerability to gain a foothold within the environment. For example, in the below event, FortiEDR blocks the PowerShell payload delivered by exploiting the Log4shell vulnerability.
Figure 1: FortiEDR blocked PowerShell payload by triggering Suspicious Application rule
The exploit request is given below, in which localhost:8080 is the vulnerable web application, and 192.168.230.134:1389 is a malicious LDAP server that redirects the commands back to the vulnerable application (localhost) and then executes the base64 encoded PowerShell commands on the vulnerable host.
Figure 2: Exploit request sent to a vulnerable server running vulnerable Log4j library
FortiEDR's Suspicious Application rule detected and blocked the PowerShell making a network connection.
Threat Hunting
Detection of exploitable systems is possible via FortiEDR threat hunting by searching for loading of vulnerable log4j versions.
Figure 3: FortiEDR Threat Hunting query to identify vulnerable Log4j versions
In this case, Apache Tomcat Server is loading the vulnerable log4j library.
Figure 4: Apache Tomcat loading Log4j version 2.14.1
Threat Hunting Queries
The FortiEDR Threat Hunting feature is able to collect metadata related to the most significant events occurring on an endpoint. Events are divided into five main groups: Process, File, Network, Registry, and Event Log. The events logged on each collector are determined by the Threat Hunting Settings which can be easily configured through the FortiEDR console to meet storage requirements or optimized to maximize detection capabilities for particular threats of interest.
To ensure events related to log4shell use in an environment are detected through currently available Threat Hunting queries included in this article, the following events need to be collected. These events are all logged through the use of the ‘Comprehensive’ profile which is provided with all FortiEDR environments OOTB.
|
Event Group |
Event Type |
|
Process |
Process Creation |
|
Process |
Library Loaded |
|
File |
File Read |
|
Network |
Socket Connect |
These events are also indicated in the figure below which shows the Threat Hunting Settings panel used to configure Threat Hunting through the FortiEDR console.
Figure 5: FortiEDR v5 Threat Hunting settings panel
The following queries help to identify potential anomalous events associated with this exploitation:
- File Read Events.
Identify file read of library load of vulnerable log4j libraries. Note this detects software loading log4j libraries NOT exploitation. Hits will need to be checked for a vulnerable version:
(Type:"File Read" OR Type:"Library Loaded") AND Target.File.Name:("log4j*")
- Process Creation Events.
Identify process creation events containing base64 encoded curl and wget commands:
Type:"Process Creation" AND (Target.Process.CommandLine:"KGN1cmwgLXMgN" AND Target.Process.CommandLine:"58fHdnZXQgLXEgLU8")
Identify process creation events containing curl and wget commands used in the most common base64 payload. These commands are related to attacks on Linux endpoints:
Type:"Process Creation" AND (Target.Process.CommandLine:"curl -s " AND Target.Process.CommandLine:"wget -q -O")
- Socket Connect Events.
Identify network connections to known bad IPS associated with kinsing cryptomining. (src: https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890 and https://github.com/eromang/researches/tree/main/CVE-2021-44228):
Type:"Socket Connect" AND (RemoteIP:"45.155.205.233" OR RemoteIP:"93.189.42.8" OR RemoteIP:"80.71.158.12" OR RemoteIP:"80.71.158.44")
Identify network connections to known bad IPs hosting Muhstik/Tsunami backdoor. (src: https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726):
Type:"Socket Connect" AND (RemoteIP:"18.228.7.109" OR RemoteIP:"45.130.229.168" OR RemoteIP:"210.141.105.67" OR RemoteIP:"159.89.182.117")
Identify network connections to known bad IPs observed dropping xmrig through the exploit. (src: https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726):
Type:"Socket Connect" AND (RemoteIP:"172.105.241.146" OR RemoteIP:"54.210.230.186")
Affected Products
Apache Log4j2 versions 2.14.1 and below are susceptible to a remote code execution vulnerability where a remote attacker can leverage this vulnerability to take full control of a vulnerable machine.
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques below.
- Java 8 (or later) users should upgrade to release 2.16.0.
- Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
- Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
FortiGuard Labs recommends organizations affected by CVE-2021-44228 update to the latest version of 2.16.0 or 2.12.2. For further details, refer to the "Apache Log4j Security Vulnerabilities".
