Log4J FAQ

This document is for:

Invicti Standard, Invicti Enterprise On-Premises, Invicti Enterprise On-Demand

Last updated on 30 December 2021

Q: How do I ensure my Java application is not vulnerable to Log4Shell?

A: The best way to ensure your environment is not vulnerable is to verify that any presence of Log4j is a version that is not affected. Please see detection and mitigation guidance courtesy of CISA: Apache Log4j Vulnerability Guidance.

Q: What is the fastest way for Invicti to scan for vulnerable Log4j implementations?

A: Configure a scan policy that only contains the Log4j security checks. Run it with the existing profiles for each of their apps. That will be extremely efficient and run quickly.

You can watch the following videos to learn how to identify the Log4j vulnerability using Invicti Enterprise and Invicti Standard.

For Invicti Enterprise:

For Invicti Standard:

For further information, see Detecting Log4j vulnerability with Invicti.

Q: Do Invicti products detect Log4Shell?

A: Released & Updated to detect Log4Shell

Invicti Standard version 6.2.1.33642 was released on 14 December 2021.
Invicti Enterprise On-Demand was deployed on 15 December 2021.
Invicti Enterprise On-Premises 2.2.3 was deployed on 21 December 2021.

Q: How do Invicti products detect Log4j?

A: Invicti utilizes Out-of-Band vulnerability detection mechanism to discover the vulnerability. When Invicti scans your application, it will inject the string payload into places in your application where they might be logged. A vulnerable Log4j installation will attempt to make a DNS request to our out-of-band detection server and log the vulnerability against that application and vector.

Additionally, Invicti’s technology capability will detect the presence of the Log4j library and version. The out-of-date library will be reflected in the vulnerability report as a critical vulnerability to remediate.

Q: How can I tell Invicti DAST probing attempts from an actual attack?

A: We will send payloads that correctly target the following sites owned by Invicti:

Invicti: The jndi payload, appearing in logs, correctly targets *.r87.me

Q: Do Invicti products use Log4j?

A: Invicti products, including Invicti, do not utilize Log4j or ship Log4j. However, the Invicti Java IAST component may have its logging or tracing sent through the host application’s logging library. If the integrated Java application uses Log4j, logging or tracing may be sent through Log4j.

Q: How do I ensure my Invicti products do not call a vulnerable version of Log4j?

A: The following products do not require action. These products do not utilize Log4j:

Invicti Enterprise Application
Invicti Standard Application
Invicti Agent
Invicti Authentication Verifier
Invicti IAST: NodeJS
Invicti IAST: ASP.NET
Invicti IAST: PHP

The following products may require action:

Invicti IAST: Java

Our Java IAST solution utilizes the logging mechanism provided by the hosting Java application. We recommend analyzing the Java application for the presence of Log4j.

The best way to ensure your environment is not vulnerable is to verify that any presence of Log4j is a version that is not affected. For this RCE exploit, we recommend visiting the CISA Apache Log4j Guidance for further details on how to identify this vulnerability within your systems.

If Log4j is present and the library cannot be immediately updated, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS="true" environment variable and restart the application. This will help to partially mitigate Log4Shell until proper remediation is complete.

Q: Does Invicti scan for Log4j CVE-2021-44832?

A: Log4j 2.17.1 addresses a malicious configuration change that can conditionally lead to remote code exploitation.

Invicti Standard’s Software Composition Analysis (SCA) capability will detect the presence of the Log4j library and version. The out-of-date library will be reflected in the vulnerability report as a vulnerability to remediate.