Log4j Vulnerability: FAQs & How to Protect Your Organization

CVE-2021-44228 (“Log4Shell”) is a remote code execution (RCE) in Apache log4j 2. Hackers first exploited its vulnerabilities on Dec. 9, 2021.  A public proof of concept exploit was released shortly after. Due to the ease of exploitation, massive scanning activity has begun on the internet with attackers seeking out and exploiting unpatched systems.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Image Credit: GovCert

 

What is Version is Affected?

The cybersecurity vulnerability affects Apache Log4j 2.x <= 2.15.0-rc1

 

What Software is Affected?

There are a large amount of Java-based applications that use Log4j as their logging utility.  The most common include:

• Apache Struts
• Apache Solr
• Apache Druid
• Apache Flink
• ElasticSearch
• Flume
• Apache Dubbo
• Logstash
• Kafka
• Spring-Boot-starter-log4j2

 

How Do I Know if My Organization is Vulnerable?

There are some automated ways to check for this vulnerability.  Notable ones as of the time of this writing are:

• Qualys QID 150440
• Tenable Nessus Check

How Can I Check if My Organization Was Compromised?

If you have a vulnerable server that has been externally exposed, it is very likely that this issue has been exploited or will be imminent if not fixed.  Exploitation attempts can be detected by inspecting log files for the characteristic URL pattern of: ${jndi:ldap://

 

How Do I Remediate Log4j Issues?

Those using applications leveraging Apache Log4j should upgrade to the newest version. 

Additionally, both of the most popular Java implementations — Oracle JDK and OpenJDK — have shipped with a default setting that should prevent exploitation since 2019; the variable com.sun.jndi.rmi.object.trustURLCodebase is set to false by default, disallowing access to remote resources. This setting can be checked to determine if a system has been vulnerable, and set to false as a workaround to prevent attacks, for instance by logging or printing the return value of: System.getProperty(“com.sun.jndi.ldap.object.trustURLCodebase”)

A new version of Log4j 2 published on Dec. 6, 2021 introduces the following new security controls for JNDI session security controls to restrict access to remote resources (If you are unable to deploy the patch, these settings can be altered to remediate the issue):

 

• allowedJndiProtocols restricts JNDI protocols to those listed; default: none
• allowedLdapHosts restricts LDAP requests to listed hosts; default: none
• allowedLdapClasses lists names of allowed remote Java classes; default: none

 

Unsure if Your Organization was Affected by the Log4j Vulnerability? 

Our team of experts is ready to examine your network assets and implement fixes immediately. Contact us today to get started.