The Palo Alto Networks Full-Court Defense for Apache Log4j

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

The recent Apache Log4j vulnerabilities are a particularly pernicious problem for two reasons. First, Apache Log4j has a very large footprint as a back-end logging library that is incorporated into many widely-used, open sourced and internally developed applications used by enterprises around the world. Issues with Apache Log4j affect almost everyone. Second, remediation can take weeks. The best way to protect yourself is to upgrade to the latest version; however, that requires that you first know where every instance needs to be patched and second that Java 8 is installed. There are many reasons why customers may not be able to upgrade for days or weeks, including the big effort required to upgrade Java before applying this patch, the full test cycle needed before upgrading Log4j, so it doesn’t break applications or year-end production freezes.

How Palo Alto Networks Protects Customers From the Apache Log4j Vulnerability

Palo Alto Networks customers are protected from attacks exploiting the Apache Log4j remote code execution (RCE) vulnerability as outlined below. In addition, we offer a number of solutions to help identify affected applications and incident response if needed.

Blocking the Exploit

To give you time while your teams patch the vulnerabilities, Palo Alto Networks customers are protected by our Next-Generation Firewalls with an active Threat Prevention security service, Cortex XDR and Prisma Cloud:

• Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription can automatically block sessions related to this vulnerability. Customers already aligned with our security best practices gain automated protection against these attacks with no manual intervention. These signatures block the first stage of the attack. Customers should verify security profile best practices are applied to the relevant security policies and have critical vulnerabilities set to reset or default actions. Additionally, the Log4j RCE requires access to code hosted externally. Our Advanced URL Filtering security service is constantly monitoring and blocking new, unknown and known malicious domains (websites) to block those unsafe external connections. Also, suitable egress application filtering can be used to block the second stage of the attack. Use App-ID for 'ldap' and 'rmi-iiop' to block all RMI and LDAP to or from untrusted networks and unexpected sources. SSL decryption needs to be enabled on the firewall to block known attacks over HTTPS. Customers with log4j in their environments should upgrade or apply workarounds suggested by respective vendors and not rely only on the Threat Prevention signatures. Learn more about how the NGFW with cloud-delivered security services can help protect against these vulnerabilities.
• Cortex XDR customers who are running Cortex XDR agent 7.0 and higher and content 290-78377 on Linux are protected from a full exploitation chain using the Java Deserialization Exploit protection module. Other Cortex XDR customers are protected against various observed payloads stemming from CVE-2021-44228 through Behavioral Threat Protection (BTP). Additionally, Cortex XDR Pro customers using Analytics will detect post-exploitation activities related to this vulnerability.
• Prisma Cloud customers with the Web Application and API Security module enabled running either Enterprise Edition or Compute Edition with the latest Console version (21.08.525, Update 2 and higher) can leverage a virtual patch for the CVE to actively identify and protect against exploitation. Users not running the latest version of Prisma Cloud can manually create and enable a custom rule in Prevent mode.

Incident Scoping — What Systems Need to Be Patched

Every time a new security vulnerability surfaces, a race begins between attackers and defenders to identify vulnerable systems. The question defenders need to answer is: What is my full inventory of affected assets? Here’s how Palo Alto Networks can help provide this visibility:

• Prisma Cloud: Prisma Cloud Defender agents can detect whether any continuous integration (CI) project, container image, or host operating system maintains a vulnerable Log4j package or JAR file with a version equal to or older than 2.14.1.
• Cortex XSOAR: Cortex XSOAR has a playbook that automates much of the workflows. Download the "CVE-2021-44228 - Log4j RCE'' pack to automatically detect and prevent the vulnerability exploit across NGFW, Cortex XDR and SIEM products. Read more on the XSOAR marketplace.
• Cortex Xpanse: Our external attack surface management product gives customers the ability to validate full asset inventory to easily consolidate vulnerability data and convey that a fix is needed. 

Incident Response

If you think that you have an incident related to the Log4j vulnerability or simply need additional capacity to respond and remediate faster, Unit 42 can help. If you are concerned that you may have been impacted, you can contact Unit 42 for a compromise assessment and incident response services. For detailed findings on the Log4j vulnerability, see Unit 42’s summary.

Lessons from Log4j

Even if you’re not an Apache Log4j user, it's still likely that one of your partners, customers or suppliers uses software that includes the vulnerable component. This week’s vulnerability demonstrates the fragility of our large, interdependent technical ecosystem. A well-known concept in supply chain is the bullwhip effect where unforeseen fluctuations in supply can cost an individual company more than actual market demand fluctuations. In cyber security, we’re experiencing our own version of the bullwhip effect, only everyone is affected by infrastructure that makes a single vulnerability a global incident.

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 register for our threat intelligence briefings, Unit 42 Briefing: Apache Log4j Threat Update.