Log4Shell webinar: What you need to know

No matter your role in tech, you’ve probably already heard about, or dealt with, the ubiquitous Log4Shell vulnerability impacting a large number of Java applications. To help spread the latest info on this critical, zero-day vulnerability, we recently hosted a webinar to get everyone up to speed.

During our Log4Shell: What you need to know webinar, Snyk’s Steve Kinman (Field CISO), Simon Maple (Field CTO), and Kirill Efimov (Security Research Team Lead) discussed the Log4Shell vulnerability and how to mitigate it. Here’s a brief recap of what you’ll learn from the discussion.

What is Log4j?

Log4j is a popular open source Java library that’s widely used within Java applications for logging. The logging framework uses the JNDI service offered by the Java Development Kit (JDK) to pull additional information from the application that makes the logs more useful to developers by enriching the logged data with more metadata. Many popular Java application frameworks use Log4j by default, such as Apache Struts 2, Apache Solr, and Apache Druid.

Logging is a very important thing. Java applications log things all the time, particularly around exceptions and errors, so that developers can understand what is happening.

The Log4Shell vulnerability

Log4Shell is the name given to a critical and easily exploitable vulnerability within the Log4j2 library. The vulnerability (CVE-2021-44228) has received a CVSS score of 10, which is the highest score possible.

There is a highly prevalent, critical, easily exploitable zero-day vulnerability that was disclosed in Log4j. This is an attack vector which has existed for five or six years. Since it’s very exploitable, there are a huge number of attacks that are happening and it’s a constantly evolving situation.

How the Log4Shell exploit works

The JNDI (Java Naming and Directory Interface) is a directory service similar to LDAP, allowing you to use a unique identifier to get code or Java objects back. It’s common for Java applications to make requests to the JNDI services for data sources or other information.

The Log4j logging framework uses JNDI to pull variables and other information to enrich the data that it logs. The problem is that Log4j may attempt to resolve during runtime dangerous strings when logging, including URLs to an unauthorized JNDI service.

That means the Log4Shell vulnerability could allow a malicious actor to make a request from a Java application to their own JNDI service by exploiting the logging service and having their service respond back with a malicious object or code. This remote code execution (RCE) attack can have far-reaching consequences.

The main risks of Log4Shell

When it comes to Log4Shell, the direct risk is a remote code execution attack. Through the injection of malicious code, a threat actor can deploy malware or ransomware, take over a server or application, exfiltrate data, impact data integrity or application availability, or disable other security services.

Besides the immediate risk of being exploited, there are other concerns for vulnerable Java applications. The Log4Shell vulnerability can also lead to regulatory compliance failures, cloud security controls failures, third-party SaaS application security failures, and violations of compliance policies.

The biggest risk is your supervisory board or CEO asking, "Are we affected?" And if you don’t have a great answer, that’s a risk.

Identifying the Log4Shell vulnerability

For Java development teams, mitigating Log4Shell requires identifying where in the dependency graph Log4j might be in use. This may be challenging because we’ve found that 60.8% of Snyk customers are using Log4j as a transitive dependency, meaning the logging framework exists within another open source library they’re using.

One of the things that makes this vulnerability even more terrifying for security teams is not knowing whether they even have Log4j in use. If you don’t know what your software is actually built using, then you really may not know if you're affected.

You can use Snykto scan your applications for vulnerabilities like Log4Shell, even if these security issues are within transitive dependencies. This allows you to protect your software supply chain from introducing security risks like Log4Shell. Snyk has also created a snyk log4shell command to find the vulnerability in your unmanaged and shaded JARs.

Mitigating the Log4Shell exploit

Once you’ve identified the Log4j version you’re using, you should ensure that it’s version 2.17.1 at a minimum. The original advice given shortly after the zero-day was discovered was to move to version 2.15.0 to fix the Log4Shell vulnerability, but there are other issues within that version as well.

Editor’s note: At the time of the webinar’s recording, the recommended upgrade was to 2.16. This has since been updated to 2.17.1. More is being learned about this vulnerability every day, so we recommend regularly checking out our Log4Shell vulnerability resources page for all the latest information.

If you can’t immediately upgrade the library, you’ll want to mitigate the exploitability of Log4Shell. For a full remediation guide, see our Log4Shell remediation cheat sheet, which we’re continuously updating as the situation unfolds.

This vulnerability will be around for years and the fact that it’s zero-day is a concern for the industry. It’ll keep rearing its ugly head because people will put it back into play or it’s in a dependency you don’t know about.