Spectral now part of Check Point’s CloudGuard to provide the industry’s most comprehensive security platform from code to cloud Read now

What is Log4Shell (the Log4j vulnerability)?

By Eyal Katz December 19, 2021

Log4j, Log4j, Log4j. Let’s see you say that 10 times fast. If you can’t, then you may need to learn because Log4j is on the tips of everyone’s tongues right now.

In fact, people are calling Log4j the biggest security breach since Tutar, Borat’s movie daughter, sneaked into The White House and had a lively face-to-face conversation with President Trump. Pretty embarrassing but the Log4j vulnerability, dubbed Log4Shell, can lead to even greater embarrassment for some pretty serious software players. Let’s start with understanding what is Log4Shell and what will be the fall out.

What is Log4Shell (Security Vulnerability CVE-2021-44228)?

On December 9th, 2021 a vulnerability was first discovered in the popular Log4j Java logging library. The vulnerability was quickly dubbed Log4Shell and logged as CVE-2021-44228. Basically, the vulnerable component can be exploited by an attacker who introduces a particular string, which allows attackers to execute code remotely and arbitrarily in the target application. Pretty wild stuff.

Why should we care about Log4Shell?

This vulnerability is particularly concerning because of the massive use of Log4j among some of the most popular software applications delivered by companies like Apple, Microsoft, and, of course, MineCraft, who have already announced that they were impacted by Log4Shell.

In addition, due to the nature of modern software architecture, it is almost impossible to know if a certain application is impacted by this vulnerability or not. Cloud infrastructure is a dispersed infrastructure. Software applications are composed of microservices and other third-party components who in turn are composed of their own smaller third party components. Therefore, unless software development teams can gain full visibility into how their data flows to and through their dependencies they will never truly know if they are impacted by this vulnerability.

How can you mitigate Log4Shell (CVE-2021-44228)

First, check yourself: Log4j versions 2.0-beta9 to 2.14.1 (inclusive) are vulnerable. Usage of specific JDK versions (6u211+, 7u201+, 8u191+, and 11.0.1+) makes exploitation more challenging but remains vulnerable.

However, in case you are unable to upgrade to the Log4j library to the latest version, you can set the config log4j2.formatMsgNoLookups to be true and add a reference link: https://logging.apache.org/log4j/2.x/security.html

As we mentioned, due to the distributed nature of Cloud Computing it’s a bit more complicated to find Log4Shell. So you must ask yourself if a vulnerability exists in the wild but I can’t find it does it really exist somewhere in my stack? Probably. 

If you want to mitigate and protect yourself from Log4j you need to go beyond regular threat intelligence and threat hunting platforms and adopt a solution that can provide visibility for modern Cloud architecture. This solution would need to be able to scan for vulnerabilities and misconfigurations across the entire SDLC, which you can accomplish using Spectral.

How to use Spectral to mitigate Log4Shell

Spectral lets you create your own custom detector and define your own security policy, here is one of the examples of how to detect you are using the vulnerable library:

$> cd my-awesome-repo
$> spectral init

$> cat << EOF > .spectral/rules/log4j.yaml
rules:
  - id: "LOG4J001"
    name: "Log4j Core JAR With Vulnerable Version (CVE-2021-44228)"
    description: "Found a Log4j core JAR with vulnerable version (CVE-2021-44228) https://logging.apache.org/log4j/2.x/security.html"
    recommendation_template: "Read more: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228"
    tags:
    - base
    - cve
    - log4j
    applies_to:
    - ".*log4j-core-2\\.(?:[0-9]|1[0-4])(?:\\.[0-9]+)?\\.jar$"
    severity: "error"
    pattern_group:
      patterns:
      - pattern: "."
        pattern_type: "single"
        match_on_path: true
EOF

$> spectral scan

The last spectral scanner already contains that detector and more detectors that related to that issue, so you just need to scan 😀

Related articles

top 12 open source security solutions

Top 12 Open Source Code Security Tools

Open source software is everywhere. From your server to your fitness band. And it’s only becoming more common as over 90% of developers acknowledge using open

top 10 java vulnerabilities

Top 10 Most Common Java Vulnerabilities You Need to Prevent

It’s easy to think that our code is secure. Vulnerabilities or potential exploits are often the things we think about last. Most of the time, our

the complete guide to the yelp api

The Complete Guide to the Yelp API

Part of the Spectral API Security Series Yelp.com is one of the most influential crowdsourcing sites for businesses. The company is worth just over one billion

Stop leaks at the source!