Answering Log4Shell-related questions

Malware News
1

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

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

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

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

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

    3. 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?

    4. 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?

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

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

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

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

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

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

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

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

    9. 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.
  • 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 observed the use of the RMI service in the Log4Shell exploitation attempts.

  • 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 a part of the execution.

  • Is Kaspersky providing free IDS rules?

    • No, we provide rules for our customers that are using our Threat Intelligence services.

  • Do you see any vulnerabilities on IIoT devices?

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

  • 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 and scanning the software repositories using different SAST technologies.

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

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

  • Is Log4j effective even if Java is disabled?

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

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

    • The vulnerability affects either client side or server side.

    Article Link: Answering Log4Shell-related questions | Securelist