Answering Log4Shell-related questions
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
- CVE-2021-44228 (initial vulnerability) – partly fixed in 2.15.0
- CVE-2021-45046 (present in Log4j 2.15.0) – fixed in 2.16.0
- CVE-2021-45105 (present in Log4j 2.16.0) – fixed in 2.17.0
The 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 a 10/10 in terms of severity, CVE-2021-44228 or Log4Shell is capable of giving attackers full control over the targeted systems.
The exploit takes advantage of Apache’s Java Naming and Directory Interface (JNDI), which provides programmers a way to easily 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.
How an attack is carried out with the Log4Shell vulnerability
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 – another cryptominer that uses rootkits to hide their malicious activities.
So far, exploitation attempts have been noted around the globe and are expected to continue in the coming months.
To safeguard systems, it’s 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, statistics) in our blogpost “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 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 heavily 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’ve seen occurred on 10.12.2021. Of course, this heavily 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 can not confirm this.
According to the vendor publications’ new updates, you can disable the JNDILookupfeature from the Log4j library, and this configuration modification will help reduce the exploitation impact; however, the vendor recommends updating to the latest version if it’s possible.
All the JNDI exploitation attempts observed contain at least the ${jndi string in the request; however, the attackers have applied several obfuscation techniques and character replacements. Also, 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:
- Limit the outbound connections to unknown remote servers
- Disable the JNDI lookup feature
- Deploy WAF technologies and custom rules to block exploitation attempts.
- Block the connections to your perimeter to IPs that are exploiting servers worldwide. We provide free IOCs related 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 observed the use of the RMI service in the Log4Shell exploitation attempts.
In order to be vulnerable, the system has to execute software that uses the Log4j component as a part of the execution.
No, we provide rules for our customers that are using our Threat Intelligence services.
This will depend on the vendor/software running on these IoT devices. We don’t have information about specific exploitation attempts targeting only that ecosystem.
We recommend following the DevSecOps principle and scanning the software repositories using different SAST technologies.
The exploitation attempt will use different 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 in the server but the library can still be embedded or used by other software that is running in your infrastructure.
The vulnerability affects either client side or server side.
If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.
