The vulnerability in Log4j (simply) explained

Recently, a critical vulnerability in the popular software library Log4j was disclosed, which caused the internet to catch fire. And rightly so, because Log4j is used almost everywhere. There are numerous news articles, blogs, videos and lots of other content being published every day about Log4j ever since the vulnerability (coined Log4shell) came out, and it can get a bit overwhelming to try to keep up with everything for someone who wants to know what all the fuss is about. This blog is an attempt to provide a simplified view of what Log4j is, the implications of the vulnerability and what you can do to stay protected.

In a nutshell, Log4j is a piece of software used for logging (surprise!) activities by users of an application as well as general application behaviour. Almost all applications perform some form of logging, as logs can be very useful to find unusual behaviour and troubleshoot issues, and many of them use Log4j for this purpose. In its essence, it is an open-source software library, which means developers can use it for free instead of building a logging mechanism from scratch. So when there’s a vulnerability in such a widely used piece of software, things tend to get a bit messy. The vulnerability was found in a component known as JNDI (Java Naming and Directory Interface) within Log4j.

The vulnerability is something called remote code execution, commonly known as RCE. It means that malicious actors can execute commands of their choice on the vulnerable application. You may be realising the implications of this. Imagine how many systems can be compromised if you were allowed to execute anything you want on them. To make things worse, this vulnerability can be exploited easily compared to other RCEs. In some cases, it may be as simple as typing something into a chatbox.

Log4j is distributed and maintained for free by the Apache Software Foundation, and they were working frantically to come up with a patched version. Version 2.16.0 has been released now, which fixes the vulnerability. However, there is still news going around that the issue may not be fully fixed yet, and the impact of this vulnerability may be felt for a very long time in the future.

To stay protected as an individual, the best thing you can do is to update all your software and firmware to the latest version and make sure to keep everything updated in the future as well. All software vendors are releasing patches as you are reading this to fix the issue. You can find a list of software that is vulnerable/not vulnerable here. To help organizations stay protected, the National Cybersecurity Centre (NCSC) in the UK has published an article on what organizations can do in light of the vulnerability, which can be found here.

I realise there are not many technical details in this blog. I have tried to keep it simple, and there are numerous excellent resources already out there about the Log4j vulnerability which I can’t even hope to match in quality and detail. Some of my favourites are linked below.

John Hammond’s video on Log4j where he exploits a vulnerable Minecraft Server: https://www.youtube.com/watch?v=7qoPDq41xhQ&t=875s

A tweet by Naomi Buckwalter about the implications of this vulnerability: https://twitter.com/ineedmorecyber/status/1470224616375439369

The TryHackMe room Solar, which allows you to practice exploiting the vulnerability: https://tryhackme.com/room/solar

You may also want to check out the CVE on the National Vulnerability Database of NIST: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

---

The entire infosec community has been working very hard to stay on top of the issue, find as many vulnerable applications as possible, patch vulnerable software, and raise awareness about the issue. A huge shoutout to everyone for everything they are doing!