Addressing Apache Log4j Vulnerability with NGFW and Cloud-Delivered Security Services

This post is also available in: 日本語 (Japanese)

Learn how our Palo Alto Networks customers can help protect against the critical Apache Log4j vulnerability with our Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) by using automated preventions and best practices.

Recap: How the Exploit Works

The Apache Log4j library allows for developers to log various data within their applications. In certain circumstances, data being logged can originate from user input. Should this user input contain special characters, as shown in Step 1 of the above example, a Java method lookup can be called, as shown in Step 2. This method can be redirected to download and execute a Java class hosted on an attacker's external server in Step 3. The malicious Java class is then executed on the victim server that uses the vulnerable log4j instance. For a complete breakdown, description and most up-to-date information on the vulnerability, check out the detailed report from our Unit 42 team.

Automated Preventions and Best Practices to Help Detect and Prevent Against the Log4j Vulnerability

As you can see, Palo Alto Networks, through the Threat Prevention service and automated content updates, has been actively releasing signatures throughout the evolving timeline of this vulnerability.

The following Palo Alto Networks protections can help keep customers secure from this vulnerability:

• PA-Series hardware platforms for enterprise network security
• VM-Series virtual platforms for multi-cloud network security
• CN-Series containerized platforms for container security

Multiple complementary security controls across our portfolio, combined with best practices, can help protect organizations against the vulnerability. Here’s how:

• Threat Prevention security subscription can automatically block sessions related to Step 1 of this attack using Threat IDs 91991, 91994, 91995, 92001, 92007 and 92012 (minimum Application and Threat content update 8506). Please note: the situation with this vulnerability is evolving quickly and we recommend that customers install the latest content updates in alignment with our best practices as we continue to add signatures to improve protections.

If your organization is already aligned with our security best practices, you gain automated protection against the multiple steps of this attack with no manual intervention.

Please note, while we provide multiple avenues of protection against this attack, customers with Log4j in their environments should patch or apply workarounds suggested by respective vendors, and not rely only on the Threat Prevention signatures.

Threat Prevention Best Practices

Also in line with our security best practices, we recommend security profiles be leveraged in policies, similar to this example:

The Threat IDs relating to Log4Shell are all classified as Critical, so the referenced Vulnerability Protection Profile should be similar to this example:

You can also confirm all the signatures developed to protect against CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105 are present by querying the CVE-ID in the Exceptions tab.

• SSL decryption should be enabled on the NGFW to block known attacks over HTTPS
• Egress application filtering should be used to block Step 2 of the attack. Use the App-ID for ldap and rmi-iiop to block all RMI and LDAP to or from untrusted networks and unexpected sources.

• Step 3 of the attack requires access to malicious Java code hosted externally. Our Advanced URL Filtering and DNS Security service are constantly monitoring and blocking new, unknown and known malicious domains (websites) to block those unsafe external connections.

Security Profiles should be applied to Security Policies in a fashion similar to the below example. You can also leverage Security Profiles Groups to minimize configuration errors:

Advanced URL Filtering Best Practices

Advanced URL Filtering profiles should align with this best practice example:

In addition to blocking the categories:

• Malware
• Command-and-Control
• Phishing
• Grayware

Consider heightened security for the newly-registered-domain and high-risk categories.

DNS Security Best Practices

DNS Security is configured as part of the Anti-Spyware Profiles and should align with best practices similar to this example:

Identifying Vulnerable Devices with IoT Security

Palo Alto Networks IoT Security helps identify IoT devices and IoT device management servers where CVE-2021-44228, CVE-2021-45046 or CVE-2021-45105 is being exploited based on specific indicators of compromise or behavior observed in network traffic.

When IoT Security determines the identity of an IoT device and specifically the libraries it uses, it can alert you if it's running an affected Apache Log4j library. If so, it displays a vulnerability alert in the IoT Security portal so you can take further action, such as updating the device to a software patch that doesn't use the vulnerable library.

If you find any device that is vulnerable to these CVEs or exhibiting anomalous behavior, or if you receive a security alert, consider taking the following actions:

• Patch the device to use the latest version (2.17.0 or newer) of Apache Log4j.
• If you are unable to update Log4j 2 version, the following mitigations are available:
  • Remove JndiLookup.class from the classpath and restart the service
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Disable JNDI
  • Set spring.jndi.ignore=true in the spring.properties file

If you cannot patch your device or disable JNDI, take the following steps to minimize risk and keep your network safe:

• • Configure the vulnerable device to ensure it's not accessible from the Internet. If Internet connectivity is necessary, limit the number of open ports to limit any backdoors.
  • Configure your network segments to ensure the vulnerable device is behind a firewall and isolated from guest and business networks.
  • Implement zero-trust network policies to protect any critical assets.
  • Block any anomalous IoT device traffic.
  • Quarantine any compromised device to stop attacks from spreading to other vulnerable devices in the same network segment.

Visit this website for more information on Palo Alto Networks IoT Security.

About the Log4j Vulnerability

On Dec. 9, 2021, a critical remote code execution (RCE) vulnerability in the Apache java logging package Log4j was disclosed. Given how frequently this open source library is used in enterprise software, teams are on high alert throughout the industry. The vulnerability is tracked as CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105. It is also known as "Log4Shell."

Unauthenticated attackers can exploit Log4Shell and force a vulnerable system to download malicious software, enabling them to take control of servers located within enterprise networks. The affected software is prevalent in many applications and due to the recent discovery of this vulnerability, many systems, both on-premises and within cloud environments, have yet to be patched. Like with many high severity RCE exploits, massive scanning activity for Log4Shell has begun on the internet with the intent of seeking out and exploiting unpatched systems. As such, there have been ongoing reports of active exploitation in the wild, with recorded attempts to leverage the flaw to connect devices into a botnet and drop additional payloads such as Cobalt Strike and cryptocurrency miners.

To stay on top of the latest Log4j analysis and mitigation, as well as the latest vulnerability updates, please continue checking the Unit 42 blog or view the on-demand replay of the Unit 42 Briefing: Apache Log4j Threat Update.