CVE-2021-44228: Apache Log4j2 Zero-Day Exploited in the Wild (Log4Shell)
Last updated on: January 17, 2023
Table of Contents
- Update
- Qualys Coverage
- Detecting Mitigations
- Discover Log4j packages Using Qualys CSAM
- Discover Vulnerable Log4j packages Using Qualys VMDR
- Prioritize Based on RTIs
- Detect Impacted Assets with Threat Protection
- Remediate Using Qualys Patch Management
- Dashboard
- Free 30-Day VMDR Service
- Detecting the Vulnerability with Qualys WAS
- Detecting Exploits & Malware with Qualys Multi-Vector EDR
- Detect Exploitation Attempts with Qualys XDR (beta)
- Update February 10, 2022 3:00 PM ET
- Update February 16, 2022 3:00 PM ET
- Webinar: Qualys Response to the Log4Shell Vulnerability
- Vendor References
- Frequently Asked Questions
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.
Free Trial
Quickly Identify Your Vulnerable Web Applications Using Our Cloud Platform
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:
- 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:
- X-Api-Version
- User-Agent
- Referer
- X-Druid-Comment
- Origin
- Location
- X-Forwarded-For
- Cookie
- X-Requested-With
- X-Forwarded-Host
- 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:
- Detects java.exe processes with an LDAP network connection
- Search for Log4J Vulnerabilities by collecting and inventorying all .jar files on a system
- Detect internal lateral movement attempts by flagging on curl.exe and Log4J payloads
- 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
- Search for Log4J exploit attempts using QQL
- Create alert notification rule based on the QQL using Rule Editor
- 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
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 10th, 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.
Very good article, do we need to restart the application services to upgrade this log4j component?
Yes, you need to restart the application service after the upgrade.
Randori mentions that it is possible for lower versions of log4j to be vulnerable if they are using JMS Appender class as well. Are you investigating this side of things in conjunction?
Yes, this is under active investigation.
what QIDs are available for WAS ?
WAS QID 150440 was released to customers along with VULNSIGS-2.5.352-4.
The Qualys detection method ONLY checks for an LDAP callback triggered by this string: ‘${jndi:ldap:///a}’ and listens for an LDAP callback
We need additional callback checks from Java RMI, HTTP, DNS, NIS, NDS, LDAPS, and CORBA since we are actively seeing these protocols is being used rather than just LDAP to reach an Attacker controlled C2. The most important protocols to focus on however would be RMI and HTTP, since there is already exploit code published that uses LDAP, RMI, or HTTP to callback to a C2.
JAVA JNDI protocol overview Source URL:
https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
Please update the existing detection method QID or provide additional detection methods for the other protocols so we can select with callbacks to check for. This is extremely time sensitive.
Yes, this is under active investigation.We will update this blog once it’s available.
The unauthenticated QID 730297 is not working properly, trying the default “X-API-Version” header returning false positives for servers that probably don’t even have Log4j and that returns a 404 to the pages Qualys “identified”. No callback was seen on manual verification of those results.
PLEASE DON’T DELETE THIS POST and fix your QID!!!
Hi Dan,
There are several cases where remote detection might not work as documented in blog. Please open a support case with https://www.qualys.com/support/,so that we can work further with you.
I figured it out how this QID returns false positives: scanner is reusing thoe ports for the Weblogic exploits and the alledged JNDI connections are actually from a different Weblogic RCE exploit (may be several other Weblogic RCEs on the same server) NOT from Log4Shell exploit, that explains the HTTP connection instead of LDAP coming back to the scanner:
From:Oracle WebLogic Server Remote Code Execution Vulnerability (Oracle Security Alert Advisory – CVE-2019-2729)
port 7001/tcp
RESULTS:
POST /_async/AsyncResponseServiceJms HTTP/1.0
Host: vulnerable-server:7001
Content-Type: application/soap+xml
Content-Length: 697
demoActionhello com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContexthttp://10.1.2.3:33565
Vulnerable version of Weblogic (WLS9-async) Detected on 7001 port.
Then same port is used for the JNDI Log4Shell exploit:
RESULTS:
Apache Log4j Remote Code Execution (RCE) Vulnerability (Zero-day) on 7001 port.
GET / HTTP/1.0
Host: vulnerable-server:7001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
X-Api-Version: ${jndi:ldap://10.1.2.3:33565/QUALYSTEST}
Dan- We stood up a vulnerable test system and scanned it for QID 730297. Qualys detected it vulnerable. I didn’t set any custom header. I can’t say it always detects it properly, but the QID did work in this case.
On the other hand, the CSAM search doesn’t work for me. It didn’t show the system the QID above found. A CSAM software search isn’t comprehensive enough to solely rely on for this.
Kirk, yes, it is working well in certain cases but returns false positive on Web logic 10.3.x servers that have another RCE.
The unauthenticated check is not working for us remotely either – it will work in for an asset located on prem but using the Qualys SOC to scan it is not producing results we would have expected.
Hi Donal,
There are several cases where remote detection might not work as documented in blog. Please open a support case with https://www.qualys.com/support/,so that we can work further with you.
Is 376157 detecting log4j-over-slf4j.jar and log4j-api.jar too? These are not vulnerable. Only using the log4j-core.jar is problematic.
376157 (CVE-2021-44228) – This is authenticated version based check for CVE-2021-44228, which will check for the affected version of log4j-core.
Which of these QIDs would most likely be detected by the Qualys cloud agent?
All Authenticated QIDs would be detected by Cloud agent,provided the asset is vulnerable.Please refer to Supported modules in QID details section under the Knowledgebase tab.
We would love to see a Periscope-based payload in a QID for VMDR.
1 – DNS is one outbound protocol that typically isn’t blocked or dropped.
2 – This would simplify SIEM analysis of target hosts that attempt callbacks since we wouldn’t have to correlate a target host with a scanner IP and an unknown high port number.
Hi Jeni,
Remote QID 730297 is updated to include additional payloads with LDAPS, RMI, DNS, IIOP, NIS, NDS, HTTP, CORBAL with version 2.5.354-2
why would we have both confirmed vuln 376157 and the IG for mitigation 45514 firing for the same agent-based asset please?
Surely if the mitigation is in place, then the 376157 is prevented?
I would also like an explanation on this please Qualys
Hi Tony and Donal,
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.
With the official Apache patch being released, 2.15.0-rc1 was initially reported to have fixed the CVE-2021-44228 vulnerability. However, a subsequent bypass was discovered. A newly released 2.15.0-rc2 version was in turn released, which protects users against this vulnerability.
Is QID 376157 updated to look for this patch? Could we get an update here if / when it is?
Hi Keith,
Yes,Our detections are updated accordingly to check vulnerable versions mentioned by Vendor.
Remote QID 376157 updated to include additional payloads with LDAPS, RMI, DNS, IIOP, NIS, NDS, HTTP, CORBAL with version 2.5.354-2
Is this correct? Isn’t 376157 a local/authenticated check?
QID 376157 is an authenticated check. Remote QID 730297 is updated to include additional payloads with LDAPS, RMI, DNS, IIOP, NIS, NDS, HTTP, CORBAL with version 2.5.354-2.
https://logging.apache.org/log4j/2.x/security.html
Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.
Will it be taken into account by Qualys? Thanks you
Hi Fabrice, you are correct, it doesn’t mitigate completely, so Qualys does still flag the vuln QIDs even when the IG QID triggers.
This mitigation 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.
Hello,
log4j 2.15 fixes the 2021-44228 CVE but it seems we have one more CVE CVE-2021-45046 which is fixed in log4j 2.16.0 version. For more info, Please refer below vendor official site,
https://logging.apache.org/log4j/2.x/security.html
Hi Karthick,
Qualys has released multiple QIDs for CVE-2021-45046.
There is always talk that it is affected by version 2 of log4j. But we don’t know if version 1.X is also affected.
Hi Sandra,
1.x is also vulnerable as per https://logging.apache.org/log4j/2.x/security.html. QID 376187 is released for 1.x version.
Hi, does Qualys consider the point “Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.”
from the following please?
https://logging.apache.org/log4j/2.x/security.html
Hi Tony,
Yes,Our detections are updated to check for affected version of log4j-core and Applications using only the log4j-api JAR file without the log4j-core JAR file are not flagged as vulnerable.
Is the detection logic for Windows working correctly? I might be wrong but seems like the scanner is looking for “log4j-core” in the parameters of running Windows processes. If this is the case, does it handle the situation when the parameters are references (for example, JAVA_OPTS = -Des.path.home=%ES_HOME%;-Des.path.conf=%ES_PATH_CONF%)? Is the parameter search in the processes really sufficient?
Hi Eugene,
You are correct.QID 376157 relies on WMI query to list running processes,Attempts to execute select CommandLine from Win32_Process where CommandLine like ‘%log4j%’ WMI query.This query will return a loaded log4j file, and signature will check for vulnerable log4j jar file.The filename is checked to find vulnerable versions of log4j. The version needs to be present in the filename for successful detection.
QID 376160, 376195 and 376193 are based on Qualys Log4j Scan Utility (https://github.com/Qualys/log4jscanwin)
They read the file generated by the Qualys Log4j Scan Utility , perform a “deep” file scan to find all instances of a vulnerable log4j library. The benefit of such a tool is that it should find all instances of a vulnerable log4j library regardless of the Java application coding, packaging, and deployment method used.
Given the announcement of a second CVE, it is becoming difficult to scan with 1 profile. May I suggest adding all the CVE-2021-44228 and CVE-2021-45046 QIDs to the “log4j” Product database. Then a scan can be run using a search list for Product=log4j. Thank you
Hi Sherri,
Please refer to https://blog.qualys.com/vulnerabilities-threat-research/2021/12/20/new-options-profiles-for-log4shell-detection.
I see that “Qualys Log4j Scan Utility” is introduced. I assume this file has to be uploaded manually or with some tool and executed on relevant assets. Can Qualys Agents do the same search for log4 files? Can such search be executed as part of the vulnerability scan?
Hi Eugene,
QID which use the Utility are QID’s 376160,376193 looks for “JNDI found” and the “vulnerable version”. These QID will flag if Mitigation is not applied for JNDI.They are applicable for both agent and scanner . The entire process would be
You run utility (manually) ->Once completed file is generated -> You must Run the scan including above QIDs -> QID read the data and report if mitigation for JNDI is not applied .
This eventually mean you have to run the script across their environment , however, reading the output from script we are already doing it from our QIDs
for CVE-2021-4104, Qualys 376187 can flag vulnerable v1.2 JAR on linux, but not whether non-default config is utilised. Therefore 376187 should be potential vuln, no?
Hi Tony,
QID 376187 has been made potential.
Do we have any way to scan from the central repositories it self where we will get to know which framework has been used in our products? I looking for any possible way to scan the repositories like GIT, Nexus CI/CD…etc, so that I can detect the vulnerability at the root itself
Hi Naga,
The Qualys Log4j Scan Utility (https://github.com/Qualys/log4jscanwin) scans the entire hard drive and looks for file JndiLookup.class -> validates the version of the log4j jar It will search for this class inside all Jars, nested Jars, and other Java-based archives. Vulnerable log4j jars will be reported to file. Customer must run this script before launching any scan.
Feature suggestion – in QQL let me search using “vulnsig” token. i can see the file version in the agent summary but i cant tell how many agents dont have the latest (zero-day) version
Hi Sherri,
Thank you for the suggestion.We have passed this to our Product management team,Kindly raise a Feature Requst for official tracking of this request too.
Hi Guys,
How to detecting mitigation with remove class JNDI?
Rerun the scan utility provided by Qualys
Hi Diego,
Please use OOB utility based QIDs (376160, 376193) and IG QID 45515 for detecting mitigation with remove class JNDI.
I have agents running all my systems. it would be very helpful to distinguish running processes vs old abandoned jar files that are not in use.