On December 9, 2021, a vulnerability was found in the Apache Log4j module with the highest hazard level—CVSS 10. It has been named Log4Shell. The vulnerability allows to remotely execute any code and enables attackers to gain almost complete control over the victim’s servers.
Considering how widespread this module is, millions of Java services are at risk.
But if you are connected to our application security, you have nothing to worry about. We have already taken all measures to protect our clients.
What is the nature of the new vulnerability and why is it so dangerous?
Log4Shell, or CVE-2021-44228, is a vulnerability related to the Remote Code Execution (RCE). It allows to remotely execute arbitrary code on a server without authentication.
All Java services and APIs that use the Log4j log are at risk. This log is extremely popular, so there may be millions of potential victims.
The main problem of the vulnerability is that it is quite easy to use—even an inexperienced hacker can successfully carry out an attack.
To gain access to a resource, an attacker only needs to send a special query. It allows a hacker to upload his own code to an application or API.
How Gcore protects its clients from the new vulnerability
To protect your web resource against Log4shell vulnerability, simply turn on Basic WAF within our CDN product. It works as a built-in option and is available even on a free plan.
Log4shell vulnerability was added to the malware signature library during the latest product update.
We pass all traffic through the filtering system. Any suspicious queries, including those using the Log4Shell vulnerability, will be blocked on the way.
We will not allow intruders to run malicious code and will provide reliable protection for your websites and web applications.
What else can you do to protect yourself?
First of all, update Apache Log4j to the latest version.
If for some reason there is no way to update, we recommend the following:
- In versions 2.10 and higher, you can set the
log4j2.formatMsgNoLookupssystem property or theLOG4J_FORMAT_MSG_NO_LOOKUPSenvironment variable totrue. - In versions 2.7 to 2.14.1, you can change the PatternLayout patterns: specify the message converter as
%m{nolookups}instead of just%m. - In versions 2.0-beta9 to 2.7, the only solution is to remove the JndiLookup class from the classpath:
zip q -d log4j-core*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
But the most reliable way to secure your resources is to enable Basic WAF.
We monitor the emergence of new vulnerabilities and update our algorithms as quickly as possible. You don’t need to worry about the safety of your resources or take emergency measures to protect them.
