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) – partially 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

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

1. Is it safe to use version 1.x?

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.

2. Have you seen exploitation attempts using Log4j directly as something like ${attack code} without using any jndi strings?

No, we have not seen this kind of string so far.

3. On the map and graphs of hits, are exploits being shown or exploits plus scans? How do you differentiate between the two?

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).

4. Is IoT vulnerable to Log4j?

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.

5. Is there any information based on IoCs about when the first attack occurred?

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.

6. Am I safe if I only remove the JNDILookup class from Log4j?

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.

7. Is there a way to check if the vulnerability exists on a server? Are there any traces that the attackers leave?

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.

8. What is the mitigation plan for this vulnerability when it comes to Linux servers?

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](<https://github.com/craiu/iocs/blob/main/log4shell/log4j_blocklist.txt>) relating to Log4j exploitation attempts.

9. I have seen a lot of RMI Port 1099 connection attempts on my IPS. Is this type of traffic normal?

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.

10. If I have Java 8 installed on my machine, does that automatically mean I have the Log4j exploit?

In order to be vulnerable, the system has to execute software that uses the Log4j component as part of the execution.

11. Is Kaspersky providing free IDS rules?

No, we provide the rules to those of our customers who use our Threat Intelligence services.

12. Do you see any vulnerabilities on IIoT devices?

This will depend on the vendor/software running on these IoT devices. We have no information about specific exploitation attempts targeting just that ecosystem.

13. Is there a way to check if the vulnerability exists in third-party libraries? I am referring to projects that are built without Java but might have some dependencies under the hood.

We recommend following the DevSecOps principle by scanning the software repositories using various SAST technologies.

14. When using the Base64 method, is an LDAP server still required?

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.

15. Is Log4j effective even if Java is disabled?

Java can be disabled on the server but the library can still be embedded or used by other software running in your infrastructure.

16. Am I vulnerable if I have Java installed on my server or end-user device?

The vulnerability affects either the client side or server side.