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:
Multiple complementary security controls across our portfolio, combined with best practices, can help protect organizations against the vulnerability. Here’s how:
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.
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:
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:
If you cannot patch your device or disable JNDI, take the following steps to minimize risk and keep your network safe:
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.