Log4j FAQ

Last updated on 16th December 2021

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

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: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Q: What is the fastest way for Acunetix Standard / Premium to scan for vulnerable Log4j implementations?

There are two ways to scan for vulnerable Log4j implementations using Acunetix Premium. Both methods will use the same scan technologies and methodology - please select the configuration which works best for your deployment.

The first is to Scan your Targets using the "New Web Vulnerabilities" scanning profile. This will run a scan using the vulnerability checks included in the latest Acunetix update, and will work till the next Acunetix update.

The second is to configure a new custom Scan Profile which checks for Apache Log4j RCE and Apache Log4j RCE 404 page vulnerabilities, and scan your Targets using this new custom Scanning Profile.

Both methods above make use of AcuMonitor out of band vulnerability detection service. If you are using Acunetix On Premise, you will need to register your installation with AcuMonitor from the Acunetix UI > Profile page > License section. Click "Enable Acunetix Online Services". Acunetix Online users are automatically using AcuMonitor.

You can watch the following videos to learn how to identify the Log4j vulnerability using Acunetix Standard / Premium and Acunetix 360:

For Acunetix Premium: Detecting Log4j using Acunetix Premium/Standard

For Acunetix 360: Detecting Log4j using  Acunetix 360

Q: Do Invicti products detect Log4Shell?

The following Acunetix products have been Released and Updated to detect Log4Shell

• Acunetix Premium on-premise version 14.6.211213163 was released on December 13th
• Acunetix Premium Online was updated on December 14th
• Acunetix 360 On-Demand was updated on December 14th
• Acunetix 360 on-premise version 2.2.3 was updated on December 21st

Q: How do Acunetix products detect Log4j?

Acunetix utilizes an out of band vulnerability detection mechanism to discover the vulnerability. When our DAST technology scans your application, we 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, AcuSensor's 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 critical vulnerability to remediate.

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

We will send payloads that correctly target sites owned by Acunetix; the jndi payload, appearing in logs, correctly targets *.bxss.me

Q: Do Invicti products use Log4j?

Invicti products, including Acunetix, do not utilize Log4j or ship Log4j. However, the Acunetix 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:  Are there any steps I need to take to ensure that Invicti products do not call a vulnerable version of Log4j?

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

• Acunetix 360
• Acunetix Application
• Acunetix Agents
• Acunetix IAST AcuSensor: NodeJS
• Acunetix IAST AcuSensor: ASP.NET
• Acunetix IAST AcuSensor: PHP

The following products may require action:

• Acunetix IAST AcuSensor: 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.

Note: 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 plus restart the application to partially mitigate Log4Shell and force this change until proper remediation is complete.