Learn what Log4j is, how to verify it and how to avoid this attack on your Adobe Commerce and Magento OpenSource. Before start going deep into it, these are the next emergency steps to avoid this issue.
Add a custom VCL rule in your Fastly or Varnish.
Upgrade your ElasticSearch to the new version (Dec 13, 2021).
Run the audit tool mentioned in this article.
It’s a Java framework used by developers to keep records of activity within an application. Although, the hacker has been using it to exploit the flaw is strategically sends a malicious code string that eventually gets logged by Log4j version 2.0 or higher (CVE-2021-44228). The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
When you have Adobe Commerce installation the most possible software that might bring this vulnerability is ElasticSearch. If you have it in a different server or container you might check that server first.
If you have hosting support, for example, MageMojo, Ecritel, WebScale or Platform.sh, contact them as soon as possible. Having your own server on AWS or Digital Ocean, make sure you have your server has updated packages. The main updated package that you need to have is ElasticSearch.
In order to keep your server updated you should keep your Magento updated too, the last stable version of Magento is compatible with the lasted version of the server packages too, like PHP, ElasticSearch, etc. If you don’t have your upgrade planned, let’s create one for you.
If you use ElasticSearch 5, 6 or 7 you need to update it to use the version launched today (Dec 13, 2021). To mitigate attacks during the time you’re upgrading your ElasticSearch, you need to set the JVM option below.
For now, Fastly has not yet deployed a general WAF rule, if you want to mitigate against this please deploy this VCL on staging and test then deploy to prod. It’s going to block possible communication via a new Log4j script.
How to detect it?
The easiest way to detect it is to run this script below, it’s going to verify if you have the vulnerability. In case you have that vulnerability in your server, you can run the second tool called Grype, it’s going to find any possible threat using this vulnerability.
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - |bash
Or Manual check
Find files with suspect names
locate log4j|grep -v log4js;
Find the lib log4j if it’s installed
dpkg -l|grep log4j;
Check if Java it’s installed, if it’s check folders jar/war/ear
Thank you for checking it, and remember to keep your system updated.
Top comments (0)