Important notice
On December 18th, Log4j version 2.17.0 was released to address open vulnerabilities. It is highly recommended to update your systems as soon as possible.
History of the Log4j library vulnerabilities
A summary of the Log4Shell situation
On December 9th, a Chinese researcher posted his now-monumental discovery on Twitter: there was a Remote Code Execution vulnerability in the popular Apache Log4j library. This library is used in millions of commercial and open-source applications. Ranked 10 out of 10 in terms of severity, CVE-2021-44228, also known as Log4Shell, is capable of giving attackers full control over targeted systems.
The exploit takes advantage of Apache’s Java Naming and Directory Interface (JNDI), which provides programmers with an easy way to process remote commands and remote objects by calling external objects. However, with Log4Shell, attackers can inject their own code into the JNDI lookup command: code that will then be executed on the targeted system.
Log4Shell attack path
Attackers have been seen using the vulnerability in numerous ways, one of which is to execute XMRig, an infamous cryptominer. Another is to execute the Kinsing malware, a cryptominer that uses rootkits to hide malicious activity.
So far, exploitation attempts have been observed around the globe and are expected to continue in the coming months.
To safeguard systems, it is important to:
- Check if Log4j is installed
- Update to the latest version
- Monitor application logs
You can find more information about the vulnerabilities (technical details, mitigation steps, statistics) in our blogpost titled, “CVE-2021-44228 vulnerability in Apache Log4j library“.
In addition, check out the answers to some of users’ biggest security questions about the Log4Shell vulnerability. The questions were asked during our “The Log4Shell Vulnerability – explained: how to stay secure” webinar.
The Log4Shell vulnerability webinar FAQ
- Is it safe to use version 1.x?
- Have you seen exploitation attempts using Log4j directly as something like ${attack code} without using any jndi strings?
- On the map and graphs of hits, are exploits being shown or exploits plus scans? How do you differentiate between the two?
- Is IoT vulnerable to Log4j?
- Is there any information based on IoCs about when the first attack occurred?
- Am I safe if I only remove the JNDILookup class from Log4j?
- Is there a way to check if the vulnerability exists on a server? Are there any traces that the attackers leave?
- What is the mitigation plan for this vulnerability when it comes to Linux servers?
Log4j 1.x is an outdated version that is no longer supported. The last version, 1.2.17, was released in 2016. In general, software that is not updated or maintained poses a serious security risk as this software may contain unknown and unpatched vulnerabilities that will weaken your security.
No, we have not seen this kind of string so far.
The graphs only contain Log4j-related exploitation attempts. Basic scanning and other types of attacks are not included. We are using deep parsing and filtering methods to reveal malicious requests in any of the relevant sections (e.g., header entries, such as user-agent or referer).
This greatly depends on the device/vendor. There are most likely devices that contain vulnerable Log4j versions, e.g., if the interface or core application running is built on Java and incorporates this module.
The first attacks we saw occurred on December 10, 2021. Of course, this greatly depends on visibility, and the amount and sources of data. There are posts suggesting earlier attacks (beginning of December). Based on our data, we currently cannot confirm this.
According to the latest updates to the vendor publications’, you can disable the JNDILookupfeature in the Log4j library, and this modified configuration will help reduce exploitation impact; however, the vendor recommends updating to the latest version if possible.
All the JNDI exploitation attempts observed contain at least the ${jndi string in the request; however, attackers have applied several obfuscation techniques and character replacements. In addition, the Github community includes several log analyzers’ scanners to verify the presence of an exploitation attempt in your system.
The mitigation strategy will always depend on the environment where the Log4j library is executed. The vendor recommends updating to the latest version if possible, which will fix the current exploitation issue. Other recommendations are:
- Restrict outbound connections to unknown remote servers
- Disable the JNDI lookup feature
- Deploy WAF technologies and custom rules to block exploitation attempts.
- Block connections within your perimeter to IPs that are exploiting servers worldwide. We provide free IOCs relating to Log4j exploitation attempts.
It will always depend on whether your infrastructure uses this type of service. For security, we recommend enabling this service only when necessary to reduce the attack surface of your organization. We have seen the RMI service used in Log4Shell exploitation attempts.
In order to be vulnerable, the system has to execute software that uses the Log4j component as part of the execution.
No, we provide the rules to those of our customers who use our Threat Intelligence services.
This will depend on the vendor/software running on these IoT devices. We have no information about specific exploitation attempts targeting just that ecosystem.
We recommend following the DevSecOps principle by scanning the software repositories using various SAST technologies.
The exploitation attempt will use various types of services like LDAP, RMI, DNS, etc. The exploit uses a malicious Java class in order to exploit the vulnerability, so the attacker will set up a listener on the malicious infrastructure side.
Java can be disabled on the server but the library can still be embedded or used by other software running in your infrastructure.
The vulnerability affects either the client side or server side.
