The recent Apache Log4j vulnerability is a particularly pernicious problem for two reasons. First, it has a very large footprint. Log4j is a back-end logging library that is incorporated into many widely-used, open sourced and internally developed applications used by enterprises around the world. This vulnerability affects almost everyone. Second, remediation can take weeks. The best way to protect yourself is to upgrade to Log4j version 2.16.0; however, that requires that you first know where every instance is that 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.
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.
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 (NGFWs) — hardware and software — with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 91991 (initially released using Applications and Threat content update version 8498 and further enhanced with version 8499). Customers are also protected via Threat ID 91994 and 91995 (released using Applications and Threat content update version 8500). Customers already aligned with our security best practices gain automated protection against these attacks with no manual intervention. This offers customers purpose-built, automated protection against these attacks with no manual intervention required. 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.
- 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) 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.
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 our customers the ability to validate full asset inventory with an up-to-date asset inventory that makes it easy to consolidate vulnerability data and convey to the asset owner that a fix is needed.
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.
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.