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. 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, 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.
However, 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. Luckily SpectralOps is such a solution and you can use our free scanner now.
*** This is a Security Bloggers Network syndicated blog from Security boulevard – Spectral authored by Eyal Katz. Read the original post at: https://spectralops.io/blog/what-is-log4shell-the-log4j-vulnerability/