Vulnerabilities are discovered everyday. While some can be serious, most are not so scary that they get everyone in a (justifiable) panic. On Thursday 9th December 2021, a new vulnerability was publicly released after almost a month of remediation work by the affected vendor. This new vulnerability is in the Log4J library, and the vulnerability is now dubbed 'Log4J' and 'Log4Shell' (we'll be calling it Log4Shell here to avoid confusion).
So what is it? Who does it affect and why is it being called the most significant vulnerability in the last decade? Why exactly is the entire internet panicking?
Background
First, some nomenclature and a glossy of terms to help us get on the right foundation for what comes next.
Log4J
Log4J is a 'library', currently under the purview of the Apache Foundation (the vendor), and the library is a bit of add-on code that anyone can use. We will talk more about that use later.
Log4Shell
The cloud security team at Alibaba, the mega e-commerce conglomerate, discovered the vulnerability in November 2021 and told the vendor, Apache Foundation. They worked together to ensure a fix was available before the public release of the vulnerability details last Friday.
New vulnerabilities are assigned a CVE number when released responsibly like this. In this case, it was assigned CVE-2021-4428 (as you can see it is made up of CVE, the year it was discovered and then a unique ID number, somewhat sequential). However these are often hard to refer to, so the security community tend to settle on a name that is easy to remember and reference (e.g. 'EternalBlue').
What Does Log4J Do?
Right, now let's discuss what Log4J actually does. When you write some code, you often don't write everything, this is inefficient as you would have to keep re-writing the same bits of code for similar tasks. People, and large companies, share their code for doing specific things to help others. This can be strange to understand for some non-technical people but here is a good analogy to explain it.
Imagine you have the task of making coffee for your partner every morning. A simple task on the face of it, but breaking it down you need more and more components. You need a cup, you need water (hot water), you need coffee, and you may need milk and sugar.
You don't go to the pottery and make a new cup every morning, nor do you milk a cow or pick and dry coffee beans and then grind them up. You certainly don't pump water up from a well, filter it, heat it, and then combine everything. That would be incredibly time and labour intensive. Instead - if you're like most people at least - you buy a remade cup, buy pre-packaged coffee, milk and sugar. You turn on the tap for pre-filtered water then you combine them in a manner that suits your needs.
The milk, water, cup and coffee are all essentially libraries, you can 'import' the milk into any other recipe you are building that day: a bowl of cereal, a cake, scrambled eggs, more coffee etc. That is the power of a library and of code in general - write once, use many times!
When you build an Application, you need a way to record every thing that happens within it. This is where a log comes in, as it is basically like a huge diary of everything that happens to an Application: which end-user did what, when, how, where from, etc. The general rule of thumb is the more logging you have the easier it is to find and fix problems for your end-users, and you can also keep an eye on anything suspicious going on. The Log4js project run by Apache Foundation is considered one of the easiest and most robust libraries for performing logging.
What is the Log4Shell Vulnerability - in Simple Terms?
What the Alibaba team discovered is a flaw in the way that Log4J works. The purpose of a logger is to record things; generally the logger just takes what happens and writes it down. However, what Log4J does is that it uses variables to fill in some data, say the time or date which can be injected into the log command. This use of a variable is something all programming uses, but it must be done carefully especially if it takes in data from an end-user (a possible attacker!).
Think of a simple program like a Hello programme. You start it and it asks you to input your name: if you are called Jess, it then replies "Hello, Jess!". In order to do this it needs a variable for Name. So the programme may look like:
$name = [input from user]
print 'Hello, $name'The $ sign there tells the programme to look for a variable (meaning it can vary) called $name. The variable is assigned with the input from the user, in this example the word "Jess".
So when Log4J is writing the logs of what is happening, it follows a template, and it fills in variables like these before it writes it's record. This is where things go a bit off the rails for Log4J, as rather than stopping there and just recording everything it does something a little more complex, and a little bit silly.
When filling in the variables, some of those grab data from the internet, the equivalent of an end-user asking for a cup of coffee and your programme popping to the shops to get milk every time you need it! Imagine your Application is saying "I need milk, go to Tescos and bring back full fat milk". However, if the end-user is an attacker, they can ask for a cup of coffee in a special way that interrupts the process and changes it to say "I need milk, go to the dark alley behind the plastics factory and bring back white water". Your Application then proceeds to make the coffee without checking the 'milk' was legitimate.
This is essentially what Log4J is doing, it's being told to go out and pull in some code and run it without checking who wrote it or where it came from. This means attackers can run any code on they want on the victims computer.
The reason this issue is so bad, is that so many companies and projects use Log4J. Companies such as Microsoft, Apple, Cisco and many others have been impacted, and large scale games such as Minecraft have also been affected. In essence, there are very few companies this issue hasn't affected because the Log4J library is so prevalent. And this is why it has caused such a panic.
So what does this mean for people? Around the globe, the entire weekend was spent by incredibly skilled people finding vulnerable software and creating updates to fix the issue. Whilst it is too early to say we have found everything that was vulnerable to this attack, it is certain that in the upcoming days and weeks you will start to see your devices and computers start to ask you to perform updates, also known as patching, and it is vital that you perform these as soon as possible.
I know it can be frustrating to do security updates, but it is one way that you can help prevent crime being perpetrated by people taking advantage of this security issue. As the vulnerability is now known, attackers will be seeking to exploit it as much as defenders are seeking to fix it. Applying security updates as soon as possible, will apply the fixes as soon as they are released, and prevent attackers from exploiting the vulnerability.
What is the Log4Shell Vulnerability - in More Technical Terms?
For those slightly more technical people reading this as a summary, here is a simple overview of the attack under the hood:
Attacker injects JNDI lookup into a field that is likely to be logged e.g. User-Agent.
The string is passed to Log4J for logging
Log4J sees the string and queries a malicious LDAP server under attacker control
The LDAP server responds with malicious code
Log4J runs the malicious code
And here are a few things you can do to prevent Log4Shell in your applications:
Block $(jndi:ldap:// in your WAF
Patch Log4J to the latest version (at least log4j-2.1.50.rc2)
Disable Log4J (or replace with something else)
Disable JNDI lookups by setting the system property 'log4j2.formatMsgNoLookups' to True
Disable remote codebases
While some of these are simple to carry out, it's finding the use of Log4J that will be most challenging.
A Demonstration of Log4Shell
If you are interested to see how it works in action, see the demonstration we recorded below:
Interested in building your own version of this? Check out our simple guide and video!
If you've found this blog post helpful, you may want to subscribe to our mailing list. We'd be delighted to keep in touch!