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.
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.
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.
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.
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
- 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"
- pattern: "."
$> spectral scan
The last spectral scanner already contains that detector and more detectors that related to that issue, so you just need to scan 😀
Developers don’t want to become obsolete, but we do want to become more efficient and effective at what we do. In addition to honing our skills
Did you know that Kubernetes is one of the leading open-source projects globally, boasting contributors from Google, Microsoft, and many other tech giants? Kubernetes enjoys the