CVE-2021-44228: Apache Log4j2 Zero-Day Exploited in the Wild (Log4Shell)

An exploit for a critical zero-day vulnerability affecting Apache Log4j2 known as Log4Shell was disclosed on December 9, 2021. All versions of Log4j2 versions >= 2.0-beta9 and <= 2.15.0 are affected by this vulnerability. This vulnerability is actively being exploited in the wild.

Log4j2 is a ubiquitous library used by millions for Java applications. Created by Ceki Gülcü, the library is part of the Apache Software Foundation’s Apache Logging Services project.

The vulnerability, when exploited, results in remote code execution on the vulnerable server with system-level privileges. As a result, it is rated at CVSS v3 score of 10.0.

Apache Log4j2 version 2.16.0 fixes this vulnerability.

Update

Take advantage of our free service to quickly detect vulnerabilities in your external attack surface. Visit qualys.com/was-log4shell-help to get started.

Update – February 16, 2022 3:00 PM ET

Log4j QID 376187 has been updated to include enhancement in reporting, fix for false positives on Linux when JMSAppender class is deleted in QID 376187. Please click here for comprehensive details of the changes.

Update – February 10, 2022 3:00 PM ET

Log4j QIDs have undergone many changes recently that include enhancement in reporting, fix for false positives on Linux when JNDI lookup class is deleted in QIDs 376157, 376178; and a new QID (48021) which prints the summary of the Qualys Scan utility. Please click here for comprehensive details of the changes.

Update – December 29, 2021 3:00 PM ET

New QIDs to address CVE-2021-44832 were released on December 29, 2021, at 3 PM ET with VULNSIGS-2.5.366-2 or later. Please review Qualys KB for CVE-2021-44832 to find all QIDs for this CVE.

Update – December 22, 2021 7:53 PM ET

A bug in external scanners could result in false negatives when unauthenticated Log4Shell scans were run with external scanners. This issue is now resolved, and the fix will be rolled out by 11 PM ET today.

Update – December 22, 2021 5:55 AM ET

Added information about new rule and dashboard in CSAM to quickly figure out the vulnerable software and hosts.

Update – December 20, 2021 1:00 PM ET

Qualys is aware of false negatives for QID 376160, 376195 and 376193. They read the file generated by the Qualys Log4j Scan Utility and the signatures for addressing them are released at 1 PM ET on Dec 20th. They are part of VULNSIGS-2.5.359-3 or later.

Update – December 18, 2021 9:00 PM ET

Two new QIDs (376194, 376195) to address CVE-2021-45105 (Log4j < 2.17) were released at 9 PM ET on Dec 18th. They are part of VULNSIGS-2.5.357-9 or later.

Update – December 18, 2021 4:20 PM ET

• Two new option profiles for authenticated and unauthenticated Log4Shell scans are now added to the platform.
• QID for CVE-2021-45105 will be available on or before 6 PM PDT on Dec 18.

Update – December 18, 2021 1:00 PM ET

We are aware of a third update to Log4j, v2.17 (CVE-2021-45105), and are working on building QIDs for it. We will provide an ETA by 10 PM ET today if not earlier.

Update – December 17, 2021 4:38 PM ET

According to reports, Log4Shell vulnerability can be exploited locally by leveraging Javascript WebSocket connection to trigger the remote code exploit (RCE).

This attack vector does significantly increase the attack surface of this vulnerability than was previously known. See details here.

The only recommendation at this point is to update Log4j to the latest version or remove the jndi class file.

Authenticated scans at this point provide the most accurate representation of risk and attack surface.

Update – December 17, 2021 2:06 PM ET

Added QID 376187 for Apache Log4j 1.2 Remote Code Execution Vulnerability.

Update – December 16, 2021 6:19 PM ET

Updated dashboard

Update – December 16, 2021 6:20 AM ET

The mitigation shared earlier has been discredited by the vendor – https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228. The safest thing to do is to upgrade Log4j to a safe version or remove the JndiLookup class from the log4j-core jar. Qualys has not removed the mitigation QIDs so that customers do not lose track of the progress made for it.

Added QID 376160 for a zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) that results in remote code execution (RCE). Affected versions are Log4j versions 2.x prior to and including 2.15.0. This QID reads the file generated by the Qualys Log4j Scan Utility. The QID reads 1st 100000 characters from the generated output file.

Update – December 14, 2021 8:45 PM ET

Log4j discussion and Q&A webinars from Monday, Dec 13 are available to watch on demand.

Update – December 14, 2021 2:10 PM ET

• Windows Detection added to QID: 376157 with version 2.5.354-2
• Remote QID 730297 updated to include additional payloads with LDAPS, RMI, DNS, IIOP, NIS, NDS, HTTP, CORBAL with version 2.5.354-2

Update – December 13, 2021 3:30 PM ET

Added QIDs 178935, 178934, 317118, 317114, 317117, 317115 and 690737 to address Log4j vulnerability

Update – December 13, 2021 2:00 PM ET

Added information related to expediting testing for CVE-2021-44228 using Qualys WAS

Update – December 13, 2021 1:00 PM ET

Added QIDs 45514 and 48199 to address Log4j vulnerability

QID 376157 updated to not post vulnerability on Log4j API installations

Update – December 13, 2021 11:39 AM ET

Added information related to IG QIDs which can be used to detect assets where mitigations are applied

Update – December 12, 2021 8:54 PM ET

Added information related to remediating Log4j vulnerability using Qualys Patch Management

Update – December 12, 2021 4:30 PM ET

Added information related to mitigation controls along with specific QIDs that will help detect assets with mitigation controls applied

Update – December 12, 2021 10:30 AM ET

The Qualys Security Operations team has conducted a detailed investigation of our platforms to determine the vulnerable versions of Log4j needing remediation. We have implemented multiple measures for mitigation which include:

1. Rolling out latest version of Log4j where applicable, or making configuration changes on the confirmed hosts.

2. Configuration of custom rules to intercept and drop malicious web requests.

3. Blocking known IoCs available via threat feeds and research.

4. Signatures updates to perimeter security solutions like IPS/WAF to block any exploit attempts on our platforms.

Update – December 11, 2021 11:30 PM ET

• WAS QID 150440 was released to customers along with VULNSIGS-2.5.352-4.
• QID 376157 was updated to look for vulnerable installs using locate and ls proc commands

---

We are continuously monitoring all our environments for any indication of active threats and exploits. With these measures, we are confident that necessary mitigations and remediation are in place to block and prevent any exploits of Log4j RCE and there is no impact on Qualys scanners, Cloud Agent, QGS, systems or customer data. We will continue to monitor our environment round the clock and implement additional measures as required. 

Qualys Coverage

The Qualys Research Team has released both unauthenticated and authenticated QIDs to address this vulnerability. These QIDs will be available starting with vulnsigs version VULNSIGS-2.5.352-3 and in Cloud Agent manifest version lx_manifest- 2.5.352.3-1

QID	Title	Version	Available for
376157	Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell)	VULNSIGS-2.5.352-3 / 2.5.352.3-2	Scanner, Cloud Agent
730297	Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell) (Unauthenticated)	VULNSIGS-2.5.352-3	Scanner
150440	Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)	VULNSIGS-2.5.352-3	WAS
178935	Debian Security Update for apache-log4j2 (DLA 2842-1)	VULNSIGS-2.5.353-2 / 2.5.353.2-1	Scanner, Cloud Agent
178934	Debian Security Update for apache-log4j2 (DSA 5020-1)	VULNSIGS-2.5.353-2 / 2.5.353.2-1	Scanner, Cloud Agent
317114	Cisco Secure Web Appliance Log4j Remote Code Execution (RCE) Vulnerability (CSCwa47278)	VULNSIGS-2.5.353-2	Scanner
317118	Cisco Application Policy Infrastructure Controller (APIC) Apache Log4j Vulnerability (cisco-sa-apache-log4j-qRuKNEbd)	VULNSIGS-2.5.353-2	Scanner
317117	Cisco Integrated Management Controller (IMC) Apache Log4j Vulnerability (cisco-sa-apache-log4j-qRuKNEbd)	VULNSIGS-2.5.353-2	Scanner
317115	Cisco SD-WAN Log4j Remote Code Execution (RCE) Vulnerability (CSCwa47745)	VULNSIGS-2.5.353-2	Scanner
198604	Ubuntu Security Notification for Apache Log4j 2 Vulnerability (USN-5192-1)	VULNSIGS-2.5.356-2 / 2.5.356.2-1	Scanner, Cloud Agent
376178	Apache Log4j Remote Code Execution (RCE) Vulnerability (CVE-2021-45046)	VULNSIGS-2.5.356-2 / 2.5.356.2-1	Scanner, Cloud Agent
376160	Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell) Detected Based on Qualys Log4j scan Utility	VULNSIGS-2.5.356-4 / 2.5.356.4-3	Scanner, Cloud Agent
198606	Ubuntu Security Notification for Apache Log4j 2 Vulnerability (USN-5197-1)	VULNSIGS-2.5.357-4 / 2.5.357.4-3	Scanner, Cloud Agent
216275	VMware vCenter Server 7.0 Apache Log4j Remote Code Execution (RCE) Vulnerability (VMSA-2021-0028)	VULNSIGS-2.5.357-4	Scanner
216276	VMware vCenter Server 6.7 Apache Log4j Remote Code Execution (RCE) Vulnerability (VMSA-2021-0028)	VULNSIGS-2.5.357-4	Scanner
216277	VMware vCenter Server 6.5 Apache Log4j Remote Code Execution (RCE) Vulnerability (VMSA-2021-0028)	VULNSIGS-2.5.357-4	Scanner
282110	Fedora Security Update for log4j (FEDORA-2021-f0f501d01f)	VULNSIGS-2.5.357-4 / 2.5.357.4-3	Scanner, Cloud Agent
317119	Cisco Firepower Threat Defense (FTD) software Vulnerability in Apache Log4j (cisco-sa-apache-log4j-qRuKNEbd)	VULNSIGS-2.5.357-4	Scanner
376184	VMware Identity Manager (vIDM) and Workspace ONE Access Apache Log4j Remote Code Execution (RCE) Vulnerability (VMSA-2021-0028)	VULNSIGS-2.5.357-4 / 2.5.357.4-3	Scanner, Cloud Agent
376183	VMware NSX-T Apache Log4j Remote Code Execution (RCE) Vulnerability (VMSA-2021-0028)	VULNSIGS-2.5.357-4 / 2.5.357.4-3	Scanner, Cloud Agent
376185	DataDog Agent Log4j Remote Code Execution (RCE) Vulnerability	VULNSIGS-2.5.357-5 / 2.5.357.5-4	Scanner, Cloud Agent
376187	Apache Log4j 1.2 Remote Code Execution Vulnerability	VULNSIGS-2.5.357-5 / 2.5.357.5-4	Scanner, Cloud Agent
730301	Apache Solr Affected By Apache Log4J Vulnerability (Log4Shell)	VULNSIGS-2.5.357-8	Scanner
150441	Forms Vulnerable to Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)	VULNSIGS-2.5.357-8	WAS
376193	Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell) Detected Based on Qualys Log4j scan Utility (CVE-2021-45046)	VULNSIGS-2.5.357-8 / 2.5.357.8-7	Scanner, Cloud Agent
376194	Apache Log4j Denial of Service (DOS) Vulnerability (Log4Shell)	VULNSIGS-2.5.357-9 / 2.5.357.9-8	Scanner, Cloud Agent
376195	Apache Log4j Denial of Service (DOS) Vulnerability (Log4Shell) Detected Based on Qualys Log4j scan Utility	VULNSIGS-2.5.357-9 / 2.5.357.9-8	Scanner, Cloud Agent
178945	Debian Security Update for apache-log4j2 (DSA 5024-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
198613	Ubuntu Security Notification for Apache Log4j 2 Vulnerability (USN-5203-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
282173	Fedora Security Update for log4j (FEDORA-2021-017d19088b)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751506	OpenSUSE Security Update for log4j (openSUSE-SU-2021:1577-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751493	OpenSUSE Security Update for log4j (openSUSE-SU-2021:4107-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751499	OpenSUSE Security Update for log4j (openSUSE-SU-2021:4094-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
376192	Elasticsearch Logstash Log4j Remote Code Execution (RCE) Vulnerability	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751496	OpenSUSE Security Update for log4j (openSUSE-SU-2021:1586-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751524	OpenSUSE Security Update for log4j12 (openSUSE-SU-2021:4112-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751525	OpenSUSE Security Update for log4j (openSUSE-SU-2021:4111-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751508	OpenSUSE Security Update for log4j (openSUSE-SU-2021:3999-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751523	SUSE Enterprise Linux Security Update for log4j (SUSE-SU-2021:4115-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent
751522	SUSE Enterprise Linux Security Update for log4j (SUSE-SU-2021:4111-1)	VULNSIGS-2.5.359-2 / 2.5.359.2-1	Scanner, Cloud Agent

Detecting Mitigations

Qualys customers can leverage output following QIDs to detect if log4j2.formatMsgNoLookups property is set.

45241 – UNIX Daemon/Services Listed Under Root User

45240 – UNIX Daemon/Services Listed Under Non-Root Users

Qualys customers can also leverage output following QIDs to detect if LOG4J_FORMAT_MSG_NO_LOOKUPS is set to true

QID: 48196 Windows Host Environment Variables Detected                       

QID: 115041 Unix Environment Variables

Discover Log4j packages Using Qualys CSAM

To secure your infrastructure from Log4J vulnerability, first you need to get in-depth visibility into all the software components that are vulnerable. Identification and updating these components will reduce the attack surface of your infrastructure.

Log4J is installed explicitly, or it can be included in a java application as a transitive dependency with common java libraries. If Log4j is installed explicitly or is in the class path of a running java application, then Qualys CSAM will inventory it and we can currently show you where Log4j is present within your environment.

Qualys CSAM makes it easy to identify assets containing Log4j. Please use the following QQL query to identify such assets.

Query: software:(name:“log4j” or name:“liblog4j2”)

When searching for log4j in Qualys CSAM, please understand that log4j could be renamed and installed with different prefixes such as but not limited to: log4j2-java or liblog4j2 or log4j2 etc. There could be many different variations of this file being named. Currently, QQL search would show results only for exact match and not prefix/suffix. We are also actively working to improve the QQL token software:(name:) to work with prefix and suffix.

Default rule to tag all software using Log4j

Please note that a new rule will be automatically published in your Qualys CSAM account to list and tag all the software applications that are vulnerable or potentially vulnerable due to use of vulnerable Log4J component. This rule takes into consideration an extensive list of all software applications, utilities created by vendors like Microsoft, Cisco, RedHat, Juniper, Dell, HPE, BMC, Oracle, Riverbed, Siemens, Phillips, NetApp, etc. This rule will be continuously updated to reflect latest status as vendors are releasing new patches to their upgrade log4j version. The rule named “Apps with Log4j – potentially vulnerable” will be disabled by default and needs to be enabled explicitly.

Once the hosts containing vulnerable software are identified, they can be grouped together with a ‘dynamic tag’, let us say – “Log4j”. This helps in automatically grouping existing hosts with the above vulnerabilities as well as any new assets that spin up in your environment. Tagging makes these grouped assets available for querying, reporting, prioritizing, scanning and management throughout the Qualys Cloud Platform.

Dedicated Inventory Dashboard

To help you quickly find out vulnerable hosts and software, a new dashboard is created in Qualys CSAM. This dashboard has very useful widgets listing all the vulnerable hosts, applications with vulnerable versions of log4j, and most importantly all the vulnerable hosts visible on the Internet. Dedicated widgets with names ‘External Attack Surface’ populate all vulnerable hosts that are visible on Shodan and are low-hanging opportunities for attackers. These widgets also list workloads hosted on shared cloud infrastructure and that have public IP addresses. All the apps containing log4j, in which the default bundled version of log4j is vulnerable, are listed as ‘potentially vulnerable apps’.

Discover Vulnerable Log4j packages Using Qualys VMDR

You can see all your impacted hosts for this vulnerability in the vulnerabilities view by using QQL query

vulnerabilities.vulnerability.qid:[`730297`,`376157`]

Prioritize Based on RTIs

Using VMDR, the Log4j vulnerabilities can be prioritized using the following real-time threat indicators (RTIs):

• Predicted_High_Risk
• Wormable
• Remote_Code_Execution
• Unauthenticated_Exploitation

Detect Impacted Assets with Threat Protection

VMDR also enables you to automatically map assets vulnerable to these vulnerabilities using Qualys Threat Protection.

Remediate Using Qualys Patch Management

Remediating this vulnerability is not straightforward as the vulnerability is a library that is used by a Java application. As such, Qualys Patch Management can be used for different types of remediations which depend on the specific vulnerable Java application.

• In case the vendor of the Java application releases a patch, customers can use Qualys Patch Management to deploy the patch. Updating the version is not possible.
• Customers can use Qualys patch management to remove the JndiLookup.class as recommended by Apache Log4j (https://logging.apache.org/log4j/2.x/) from the log4j jar. To do so, customers can create a pre action to execute the following command as recommended by Apache Log4j: “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”
• Customers can use the pre actions to create an action that will replace the old log4j jar with the 2.16.0 jar.
• In more complex situations, pre actions can be used to update the environment variables or system properties as suggested by Apache Log4j
• Note that it is highly likely that a reboot will be needed after the changes recommended above are applied. We recommend utilizing the pre action ability to force a reboot to ensure the application has been restarted.

Dashboard

With VMDR Dashboard, you can track this vulnerability, its impacted hosts, their status, and overall management in real-time. With trending enabled for dashboard widgets, you can keep track of these vulnerabilities trends in your environment using the “Log4j” Dashboard.

Free 30-Day VMDR Service

To help security teams assess and mitigate their risk exposure to the Log4j vulnerabilities (Log4j), Qualys is offering an integrated VMDR service free for 30 days to identify vulnerable assets.

Detecting the Vulnerability with Qualys WAS

For details on Qualys WAS Log4Shell detection, please refer to: https://blog.qualys.com/vulnerabilities-threat-research/2021/12/15/is-your-web-application-exploitable-by-log4shell-cve-2021-44228-vulnerability

Qualys WAS Research team has released 150440 QID to production in order to detect the web applications vulnerable to apache log4j2 zero-day vulnerability (CVE-2021-44228). 

On affected versions of Log4j, a zero-day vulnerability exists in JNDI (Java Naming and Directory Interface) features, which was made public on December 9, 2021 that results in remote code execution (RCE).

The WAS module is using our Out Of Band detection mechanism to inject payloads into the following headers listed below.  The following request headers will be tested:

1. X-Api-Version
2. User-Agent
3. Referer
4. X-Druid-Comment
5. Origin
6. Location
7. X-Forwarded-For
8. Cookie
9. X-Requested-With
10. X-Forwarded-Host
11. Accept

We are working on other headers and will update our signatures as needed. 

The above headers will be tested at the base URl and several directories up and down (adhering to scope rules) to ensure each application is thoroughly tested.

As part of the test to detect the presence of the vulnerability WAS engine sends a HTTP GET request with a specially crafted payload inside Request headers, where vulnerable servers will make a DNS query that will trigger Qualys Periscope detection mechanism.

Successful exploitation of this vulnerability could allow a remote attacker to execute arbitrary code on the target system.

Unique payloads between the DNS server and our web server will confirm the requests, making this technique very accurate in identifying the vulnerability.

Given the detection mechanism and payload confirmation, there is no room for false positives in this approach.

QID 150440 has been added to the WAS Core Detection Scope, so all scans using the Core detection will include this QID in scanning as well.  However, to expedite testing for CVE-2021-44228 across all of your web applications, it is recommended that you create a new scanning Option Profile to limit testing to only this specific vulnerability.  This can be done by creating a new Option Profile and selecting “Custom Search Lists” under the Detection Scope to create a new static list. 

Complete the creation wizard and add QID 150440 to the Static Search List.

Additionally, we recommend limiting the scan to between 50 and 100 links in scope maximum.

Scanning with this option profile will achieve two things to expedite testing your web applications in the most efficient way possible.  First, we are only testing for one specific vulnerability, QID 150440.  Second, as this vulnerability is only tested at the base URI and several directories up and down as appropriate, there is no need to crawl and test every link in the application.  These two changes will allow each web application to be scanned faster than full Core detection scans while still providing you the necessary visibility of any vulnerable versions of Log4j2.

Detecting Exploits & Malware with Qualys Multi-Vector EDR

Qualys Multi-Vector EDR will detect exploits, malware, and Indicators of Compromise (IOC) associated with Log4Shell and will be continually updated as more are discovered in the following months.

Multi-Vector EDR collects endpoint telemetry and will flag suspicious activity associated with the vulnerability:

1. Detects java.exe processes with an LDAP network connection
2. Search for Log4J Vulnerabilities by collecting and inventorying all .jar files on a system
3. Detect internal lateral movement attempts by flagging on curl.exe and Log4J payloads
4. Detect java.exe process that spawn unusual child processes

Detect Exploitation Attempts with Qualys XDR (beta)

XDR (currently in Beta) can detect evidence of exploits across the network

1. Search for Log4J exploit attempts using QQL
2. Create alert notification rule based on the QQL using Rule Editor
3. Search for Command & Control connections (IP Addresses & Domains) interactively via QQL and automatically via threat intelligence feed integration

Update – February 10, 2022 3:00 PM ET

The following changes have been made to the log4j QIDs:

• Qualys has released a new IG QID 48201 (Qualys Log4j Scan Utility Summary Information). QID 48201 reads the output of:
  • log4j_findings.stderr (on Linux/Unix)
  • log4j_summary.out and status.txt (on Windows)

These files contain scan summary such as scan start time, details of any errors encountered during the scan, if the scan run was successful, etc. The scan utility summary can be found in the results section of 48201.

• Authenticated QIDs 376157, 376178, 376194 and 376209 on Linux and scan utility QIDs 376160, 45515, 376193, 376195 and 376210 on both Windows and Linux have been modified to enhance reporting and provide details in a more comprehensive manner than before. Refer to screenshots below for reference:

The results will contain four columns:

PATH: This column will contain the full path to the log4j-core jar

VERSION: This column will contain the version extracted from the log4j-core jar file

JDNI CLASS STATUS: This column will contain information regarding JNDI lookup class status and would have the following value:

• JNDI_CLASS_FOUND – JNDI lookup class was found in the Log4j jar file
• JNDI_CLASS_NOT_FOUND – JNDI lookup class was not found in the Log4j jar file
• JNDI_CLASS_STATUS_UNKNOWN – Scan could not determine JNDI class Status

BASE_DIR: This column will contain the base directory extracted from the PATH.

NAME: Applies to IG QID 45515 only. Lists the name of the Log4j component.

Note: The enhanced reporting will not work on vulnerable package-manager-based installations of log4j. Additionally, on the container sensor the enhanced reporting will not work on the container-specific detection for log4j.

• On Linux, QIDs 376157 and 376178 will now filter out instances where JNDI class is not found.
  To check whether the vulnerable JNDI lookup class inside a log4j instance has been deleted or not, Qualys relies on either one of the commands:
  • unzip -l <LOG4J_JAR_FILE>
  • jar -tf <LOG4J_JAR_FILE>
  • zip -sf <LOG4J_JAR_FILE>

These commands are used to list the files inside the log4j core jar which helps in checking if the JNDI lookup class is present or not. The above commands are not present by default on some flavors of Linux/Unix, in that case Qualys cannot verify if the class has been deleted or not. In such cases the status for the JNDI class is displayed as JDNI_CLASS_STATUS_UNKNOWN, QIDs 376157 and 376178 will post when JNDI status is Unknown.

Update – February 16, 2022 3:00 PM ET

Authenticated QID 376187 on Linux has been modified to enhance reporting and provide more comprehensive details than before. Refer to screenshots below for reference:

The results will contain four columns:

PATH: This column will contain the full path to the log4j-core jar

VERSION: This column will contain the version extracted from the log4j-core jar file

JMS CLASS STATUS: This column will contain information regarding JMSAppender class status and would have the following value:

• JMSAppender_CLASS_FOUND – JMSAppender class was found in the Log4j jar file
• JMSAppender_CLASS_NOT_FOUND – JMSAppender class was not found in the Log4j jar file
• JMSAppender_CLASS_STATUS_UNKNOWN – Scan could not determine JMSAppender class Status

BASE_DIR: This column will contain the base directory extracted from the PATH.

Note: The enhanced reporting will not work on vulnerable package-manager-based installations of log4j.

Additionally, On Linux, QID 376187 will now filter out instances where JMSAppender class is not found. To check whether the vulnerable JMSAppender class inside a log4j instance has been deleted or not, Qualys relies on either one of the commands:

• unzip -l <LOG4J_JAR_FILE>
• jar -tf <LOG4J_JAR_FILE>
• zip -sf <LOG4J_JAR_FILE>

These commands are used to list the files inside the log4j core jar which helps in checking if JMSAppender class is present or not. The above commands are not present by default on some flavors of Linux/Unix, in that case Qualys cannot verify if the class has been deleted or not. In such cases the status for the JNDI class is displayed as JMSAppender_CLASS_STATUS_UNKNOWN, QID 376187 will post when the JMSAppender class status is Unknown.

Webinar: Qualys’ Response to the Log4Shell Vulnerability

Please join Qualys for a Q&A and discussion on the Apache Log4j2 vulnerability.

• Monday, December 13, at 10:00 am Pacific Time. Register at https://qualys.com/log4j-webinar.
• Monday, December 13, at 2:00 pm Pacific Time. Register at https://qualys.com/log4j-webinar-2.

Vendor References

• https://logging.apache.org/log4j/2.x/security.html

Frequently Asked Questions

What versions of Log4j are affected?

All versions of Log4j from 2.0-beta9 to 2.15.0 are affected by this vulnerability.

When will the QIDs be available?

The QIDs will be released at 11 PM ET on Dec 10^th, 2021.  And will be part of vulnsigs version VULNSIGS-2.5.352-3 and in Cloud Agent manifest version lx_manifest- 2.5.352.3-1

What is the detection logic for QID: 730297?

QID 730297 is a remote unauthenticated check. It sends a HTTP GET to the remote web server and tries to inject the payload

${jndi:ldap://<SCANNER_IP>:<SCANNER_PORT>/QUALYSTEST}

to exploit the vulnerability to receive a connection back to the scanner.

Following are the parameters that the QID tries to inject payload:

• X-Api-Version
• User-Agent
• Cookie
• Referer
• Accept-Language
• Accept-Encoding
• Upgrade-Insecure-Requests
• Accept
• upgrade-insecure-requests
• Origin
• Pragma
• X-Requested-With
• X-CSRF-Token
• Dnt
• Content-Length
• Access-Control-Request-Method
• Access-Control-Request-Headers
• Warning
• Authorization
• TE
• Accept-Charset
• Accept-Datetime
• Date
• Expect
• Forwarded
• From
• Max-Forwards
• Proxy-Authorization
• Range,
• Content-Disposition
• Content-Encoding
• X-Amz-Target
• X-Amz-Date
• Content-Type
• Username
• IP
• IPaddress
• Hostname
• X-CSRFToken
• X-XSRF-TOKEN
• X-ProxyUser-Ip

Additionally, payloads are now also included:

• In the body of a request
• In place of the request method
• In place of the URI

Under what situations would QID 730297 not detect vulnerability?

QID 730297 tries to exploit the vulnerability via the parameters mentioned above. If the application is not logging any one of the parameters mentioned above, the QID will not be detected.

What is the detection logic for QID: 376157?

QID 376157 is an authenticated check. This detection is based on querying the OS package managers on the target. If the target has a log4j package with a version less than 2.15.0, the target is flagged as vulnerable.

Update – Dec 11th 11:30pm EST

We have added 2 additional updates to the QID. We have updated the logic to find the log4j installs using the locate command. We have also updated the logic to identify the Log4j running process using the ls proc command. These updates are in VULNSIGS-2.5.352-4.

Update – December 14, 2021 2:10 PM ET

We have updated the detection logic for QID 376157 to support Windows Operating System. The detection logic for Windows uses WMI to enumerate the running process and identifies log4j included in a process via the command line.

The QID 376157 is a  version based check. Please note that mitigation is not equal to remediation and if customers have put mitigation controls in place but still have a vulnerable version of Log4j, Qualys would continue to flag the QID 376157 on their system. The mitigation QID is provided so that customers can get a better understanding of their environment. It should be not considered as a replacement for patching.

Under what situations would QID 376157 not detect vulnerability?

QID 376157 leverages the OS package manager to identify vulnerable Log4j packages. If the target does not have the vulnerable log4j package installed via the package manager, this QID might not get detected. This would typically happen when an application bundles the Log4j library in a jar etc.

Please run rpm-qa OR equivalent on the target and see if log4j is registered. Please note that if log4j is not in the output, Qualys would not flag the QID. Qualys is actively investigating other options to identify this vulnerability. We would continue to update this blog as we make progress.

If log4j is installed with OS package manager (i.e coming in the output of rpm -qa) and QID is still not detected, we need to run a debug scan to identify why QID it’s not getting flagged. Please refer to the below link for steps to run debug scan. https://success.qualys.com/support/s/article/000001825 with Qualys Support.

Update – Dec 11th 11:30pm EST

If access to /proc/*/fd is restricted or if log4j is embedded inside other binaries, such as jar, war ect.. or lof4j jar filename doesn’t have file version, this QID may not be detected.
Also, if locate command is not available on the target this QID might not be detected.

Update – December 14, 2021 2:10 PM ET

On Windows systems, the QID leverages WMI to identify log4j instances. If access to WMI is restricted or log4j is embedded inside other binaries, such as jar, war, etc. or log4j jar filename doesn’t have file version, this QID may not be detected.

What is the difference between the QID 730297 and QID 376157?

QID 730297 is a remote unauthenticated QID and 376157 is an authenticated QID.

Does Qualys WAS have a detection?

Update – Dec 11th 11:30pm EST

Yes! Qualys WAS has the following QID: 150440 with VULNSIGS-2.5.352-4

What should customers do if there are false negatives for remote detection QID 730297 on higher ports?

We recommend allowing bidirectional communication between scanner and target on all ports. At the time of the scan, the scanner is scanning multiple IP addresses. So for each IP, it scans it provides a unique port (usually a high number port) to connect back to. Once the scanner gets the connection back from the target to the high port it confirms the vulnerability.

Which port the target will connect back to is not known ahead of the scan. Hence the communication between the scanner and targets needs to be white-listed in both directions.

When will authenticated detection Windows be available?

QID 376157 is updated to support Windows Operating with version VULNSIGS-2.5.354-2 QAGENT-SIGNATURE-SET-2.5.354.2-1

What are the ports on which Remote QID would be flagged?

QID would be tested and flagged (if found vulnerable) on any port (Included in the scan) where the Webservice is running.

Is log4j-api also vulnerable?

No, Apache maintainers updated the advisory to confirm that only log4j-core is vulnerable, We have updated our signatures to accommodate this change in VULNSIGS-2.5.353-2.

Does QID 376157 check for the Log4j1.x version as well?

No, Vulnerability for Log4j 1.x is tracked via CVE-2021-4104. This blog would be updated as we release new QIDs for the same.

Update – December 17, 2021 2:06 PM ET

Added QID 376187 for Apache Log4j 1.2 Remote Code Execution Vulnerability.

Would Qualys update/release more QIDs for this vulnerability?

Yes. We expect more QIDs will be created for this CVE as more vendors release updates for this vulnerability. Also, we expect more updates to QID 376157 and 730297.

What is the difference between 48201 and 45515 QID.

QID 45515 parses the output of log4j_findings.out (on Windows) and log4j_findings.stdout(on Linux/Unix) to list all log4j related instances discovered on Host.

QID 48201 provides a scan summary for the Qualys Log4j Scan Utility. QID 48201 reads the output of:

• log4j_findings.stderr (on Linux/Unix)
• log4j_summary.out and status.txt (on Windows)

What does JDNI_CLASS_STATUS_UNKNOWN mean?

Log4j instances may report with this status when a scan is not able to determine if JNDI Lookup class is present inside the log4j jar file. As detailed above, Qualys relies on unzip, zip, or jar commands to be present on the host to determine the JNDI class status. These commands are missing my default on some Linux distributions.