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 Netsparker 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 Netsparker Enterprise and Netsparker Standard.
For Netsparker Enterprise:
For Netsparker Standard:
For further information, see Detecting Log4j vulnerability with Netsparker.
Q: Do Invicti products detect Log4Shell?
A: Released & Updated to detect Log4Shell
- Netsparker Standard version 188.8.131.52642 was released on 14 December 2021.
- Netsparker Enterprise On-Demand was deployed on 15 December 2021.
- Netsparker Enterprise On-Premises 2.2.3 was deployed on 21 December 2021.
Q: How do Netsparker products detect Log4j?
A: Netsparker utilizes Out-of-Band vulnerability detection mechanism to discover the vulnerability. When Netsparker 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, Netsparker'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 Netsparker DAST probing attempts from an actual attack?
A: We will send payloads that correctly target the following sites owned by Invicti:
- Netsparker: The jndi payload, appearing in logs, correctly targets *.r87.me
Q: Do Invicti products use Log4j?
A: Invicti products, including Netsparker, do not utilize Log4j or ship Log4j. However, the Netsparker 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:
- Netsparker Enterprise Application
- Netsparker Standard Application
- Netsparker Agent
- Netsparker Authentication Verifier
- Netsparker IAST: NodeJS
- Netsparker IAST: ASP.NET
- Netsparker IAST: PHP
The following products may require action:
- Netsparker 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 Netsparker scan for Log4j CVE-2021-44832?
A: Log4j 2.17.1 addresses a malicious configuration change that can conditionally lead to remote code exploitation.
Netsparker 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.