10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
Take advantage of our free service to quickly detect vulnerabilities in your external attack surface. Visit qualys.com/was-log4shell-help to get started.
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.
Added information about new rule and dashboard in CSAM to quickly figure out the vulnerable software and hosts.
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.
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.
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.
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.
Added QID 376187 for Apache Log4j 1.2 Remote Code Execution Vulnerability.
Updated dashboard
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.
Log4j discussion and Q&A webinars from Monday, Dec 13 are available to watch on demand.
Added QIDs 178935, 178934, 317118, 317114, 317117, 317115 and 690737 to address Log4j vulnerability
Added information related to expediting testing for CVE-2021-44228 using Qualys WAS
Added QIDs 45514 and 48199 to address Log4j vulnerability
QID 376157 updated to not post vulnerability on Log4j API installations
Added information related to IG QIDs which can be used to detect assets where mitigations are applied
Added information related to remediating Log4j vulnerability using Qualys Patch Management
Added information related to mitigation controls along with specific QIDs that will help detect assets with mitigation controls applied
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:
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.
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.
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.
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 |
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 isset to true
QID: 48196 Windows Host Environment Variables Detected
QID: 115041 Unix Environment Variables
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.
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.
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’.
You can see all your impacted hosts for this vulnerability in the vulnerabilities view by using QQL query
vulnerabilities.vulnerability.qid:[730297
,376157
]
Using VMDR, the Log4j vulnerabilities can be prioritized using the following real-time threat indicators (RTIs):
Detect Impacted Assets with Threat Protection__
VMDR also enables you to automatically map assets vulnerable to these vulnerabilities using Qualys Threat Protection.
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.
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.
QLYS-Apache_Log4J2___Global_InsightsDownload
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.
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:
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.
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:
XDR (currently in Beta) can detect evidence of exploits across the network
Please join Qualys for a Q&A and discussion on the Apache Log4j2 vulnerability.
All versions of Log4j from 2.0-beta9 to 2.15.0 are affected by this vulnerability.
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
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:
Additionally, payloads are now also included:
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.
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.
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.
QID 730297 is a remote unauthenticated QID and 376157is an authenticated QID.
Update - Dec 11th 11:30pm EST
Yes! Qualys WAS has the following QID: 150440 with VULNSIGS-2.5.352-4
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.
QID 376157 is updated to support Windows Operating with version** **VULNSIGS-2.5.354-2 QAGENT-SIGNATURE-SET-2.5.354.2-1
QID would be tested and flagged (if found vulnerable) on any port (Included in the scan) where the Webservice is running.
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.
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.
Added QID 376187 for Apache Log4j 1.2 Remote Code Execution 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.
10 High
CVSS3
Attack Vector
NETWORK
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
NONE
Scope
CHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C