Qualys : Is Your Web Application Exploitable By Log4Shell (CVE-2021-44228) 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 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 which sends specially crafted requests to the target server to detect vulnerable web application instances using Log4j2 library. Once successfully detected, users can remediate the vulnerability by upgrading to Apache Log4j 2.16.0

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 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 "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 protocol such as LDAP, RMI, DNS etc. This JNDI lookup allows a developer retrieve DataSource objects and enhance the data which is being logged by 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 vulnerable instance of Log4j, below is the POC to demonstrate how attackers are exploiting this vulnerability in 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:

The WAS module injects JNDI payload into the headers listed below and uses Out Of Band (OOB) detection mechanism where vulnerable instances will make a callback DNS query that will trigger Qualys Periscope detection mechanism :

1. X-Api-Version
2. User-Agent
3. Referer
4. X-Druid-Comment
5. Origin
6. Location
7. X-Forwarded-For
8. Cookie
9. X-Requested-With
10. X-Forwarded-Host
11. Accept
12. Authentication
13. Authorization

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:

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

1. 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.
2. 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.
3. 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.
4. 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

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.

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 Apache products like Struts2 and Solr and will update new QIDs as needed.

Solution

It is strongly recommended to upgrade to Apache Log4j 2.16.0 to remediate this vulnerability. According to Apache Security Advisory, Log4j 2.16.0 disables access to JNDI by default and message lookups feature has been completely removed.

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 this attack when they use JNDI in their configuration and can mitigate by auditing logging configuration to ensure it has no JMSAppender configured.
• For Log4j 2.x : Implement one of the mitigation techniques below :
  • Java 8 (or later) users should upgrade to release 2.16.0.
  • Users requiring Java 7 should upgrade to release 2.12.2 once it becomes available.
  • Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. Please note that, only 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.

Credits

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

CVE Details: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Credits for the vulnerability discovery go to:

• Chen Zhaojun of Alibaba Cloud Security Team.

References:

• https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce
• https://y4y.space/2021/12/10/log4j-analysis-more-jndi-injection/
• https://www.lunasec.io/docs/blog/log4j-zero-day/
• https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java

Contributors

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

Related