4-Step Immediate Mitigation for Log4j Attacks (Log4Shell)

4-Step Immediate Mitigation for Log4j Exploits

It seems that we will be talking about Log4j for weeks, maybe months to come. Even though a patch for the first Log4j vulnerability (CVE-2021-44228) was released on December 10th, another Log4j vulnerability (CVE-2021-45046) was found on December 14th, 2021. Picus updated Picus Threat Library within hours after the release of the first PoC exploits and gave detailed explanations in the blogs on how to simulate and prevent Log4Shell attacks and remediate those attacks with WAFs and IPSs.

In this blog, 4-step quick mitigation plan for Log4j attacks is explained. 

Update: In addition to two vulnerabilities mentioned in this blog post, a new denial of service (DoS) vulnerability affecting Apache Log4j versions prior to 2.17.0 is found. This vulnerability is called CVE-2021-45105 and its CVSS score is 7.5 (high).

Test your security controls against Log4Shell now!

Why Is the Remediation of Log4j Vulnerability Challenging?

In most cases, when there is a vulnerability in a product, it is easy to detect whether we have a vulnerable version of this product in our environment or not. We can check product banners, names, paths, and file hashes to find vulnerable product versions. For example, you can quickly check your systems for Sunburst vulnerability in Solarwinds by just checking the product version displayed in the footer of the Orion Web Console login page.

However, it is challenging to check your environment for affected Log4j versions and affected products because of the following reasons:

• It is a library widely used in many software and applications. Some products utilize the Log4j library externally, but some standalone Java applications use it embedded in their executables. It is tough to detect a Log4j library embedded in a standalone executable.
• The Java Runtime Environment (JRE) may also be embedded in this standalone application. In other words, the absence of a JRE installation on a system does not mean that Log4j cannot be exploited on this system.
• Although externally used Log4j libraries are easier to detect than embedded ones, there is another difficulty. Since it is open-source software, anyone may modify and compile it. So, the effectiveness of hash lists is limited.
• If a transitive dependency to Log4j exists in your applications, which means that although an application you are using does not directly use Log4j, another library that the application depends on may be able to use Log4j.

Briefly, it is very challenging to discover 100% of vulnerable assets. As with the ShellShock vulnerability, you may encounter applications with the Log4j vulnerability after months. Moreover, many public exploits are available, and research for different methods to exploit the vulnerability is still underway. Incident response and threat hunting are also challenging since the JNDI string is not actually logged if the exploitation is successful.

What are the Immediate Mitigation Measures?

While mid and long term operations continue to discover vulnerable assets, respond to potential incidents, and hunt for retroactive threats, you must take the following immediate measures to limit the attack surface:

1- Secure public-facing critical assets first

Since detecting all vulnerable assets in the network is hard, it is best to start with public-facing critical assets to limit the attack surface. Note that the effectiveness of black-box external scanning is very limited for the Log4j vulnerabilities. This type of scan focuses on finding vulnerable services according to banners of web server applications, such as Apache Tomcat. However, the attack surface is larger than the applications focused on external scans. Log4j rabbit hole runs deep, where finding vulnerable assets is challenging for even white-box internal scans; relying only on external scans creates a false sense of security.

2- Validate network security controls

You should simulate attacks to understand whether your security devices are preventing these attacks or not. To measure the actual effectiveness of your security products against Log4j vulnerability exploitation attacks, you should test all valid variants of Log4j exploits, including evasive payloads. You should also test JNDI-related naming services other than LDAP, such as DNS, RMI, NDS, NIS, and CORBA. 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.

Test your security controls with Picus now!

How does Picus help? 

Picus platform automatically simulates 48 known variants of Log4j exploits within minutes without causing single damage to your environment and assesses your security posture. Picus Labs’ experts continuously research new variants and add them to the platform.

3- Utilize your network security controls

Remote code execution (RCE) attempts to exploit the Log4j vulnerability can be blocked by web application firewalls (WAF) and intrusion prevention systems (IPS) by inspecting ingress network traffic. For egress JNDI traffic from the vulnerable system to the attacker’s system, firewall rules should be set in place to block attacks.

How does Picus help? 

Picus platform provides prevention signatures of WAF, IPS, and NGFW vendors, such as F5, Citrix, ModSecurity, Cisco, Palo Alto, Fortinet, Check Point, Forcepoint, McAfee, Trend Micro, and Snort. See our previous blog post.

4- Keep your assets up-to-date but continue to simulate attacks and harden your perimeter security

Apache released a patch for CVE-2021-44228. However, it was incomplete, and CVE-2021-45046 was discovered, and a new patch was released. There might be more patches on the way, and it is crucial to follow vendor updates. In addition, you should run attack simulations, identify the gaps in your security controls and fix these gaps as a continuous effort.

How Picus Helps? 

Picus helps you to:

• Simulate Log4j vulnerability exploit (a.k.a. Log4Shell) attacks
• Test your WAF, IPS, and NGFW against Log4j attacks and uncover gaps
• Enable prevention signatures to fix gaps and block Log4j attacks
• Secure your network against Log4j attacks
• Continuously validate your security controls and Log4j resilience.

Start Validation Your Security Controls Now!

Click here to benefit from the special offer of the Picus platform and be resilient for Log4j attacks!

See Picus in Action

Watch how you can easily simulate Log4j attacks to assess your security posture and prevent them with signatures of your WAF, IPS, and NGFW.