Apache Zero Day Vulnerability Response – Week Two

December 15, 2021 Update

Palo Alto Networks has determined Panorama 9.0.x,  9.1.x, and 10.0.x are affected by the log4j vulnerability. Upgrade Panorama to PAN-OS 10.1 to remediate this issue. If you cannot upgrade to 10.1, hotfixes are being developed but are not ready at this time.

It is safe to upgrade Panorama without upgrading managed firewalls. Panorama just needs to be the same major release, or higher.

No updates for other Palo Alto Networks products are required at this time.

Palo Alto’s notice also contains more recommendations to block the first and second stage attacks at the firewall.

https://security.paloaltonetworks.com/CVE-2021-44228

 

December 14, 2021 Update

Juniper’s Response to Log4J Vulnerability – Zero day exploit – AKA “Log4Shell”

You may have seen the news regarding the Log4J vulnerability discovered last week specific to the popular Java tool Log4J – part of the Apache logging services. Active exploitation by threat actors is already being observed, which you can read more about here from our Juniper Threat Labs leader, Mounir Hahad.

This particular piece of code is very broadly distributed and in use by organizations around the world (part of the Apache web services framework, the most popular web server globally.)

What you can do:

Apache has released an updated version of Log4J (version 2.15) that fixes this.

Juniper Threat Labs has released IDP signature packs #3444 & #3445 for all currently supported SRX firewalls that are effective at both detecting and preventing the original proof of concept and additional variants. We will release additional packs as new Log4J variants are identified.

In addition, Juniper customers running Juniper Cloud Workload Protection are protected against the discovered exploits to date. These attempts will register as a Server-Side Request Forgery (SSRF) attack.

 

December 14, 2021 Update

Some of the mitigations recommended early on after the discovery of the log4j vulnerability have been found to be inconsistent. One of the recommendations was to set the log4j2.formatMsgNoLookups parameter, but it is only available in certain versions and can be bypassed.

Log4j 2.15.0 was released last week to fix the vulnerability, but it has been found to have other vulnerabilities that are not as serious or exploitable. Log4j 2.16 has been released which fully disables JNDI and removes support for Message Lookups, which are the features at the center of this.

The best mitigation is to upgrade log4j. Also make sure security devices have updates running and configured correctly as new updates are being pushed all the time to try to detect the new vulnerabilities.