How an overlook in development wreaked havoc on the internet - The Log4Shell Vulnerability

Java is a funny language. The people who use it can often be found ranting about it on reddit. It is heavily criticized for its design choices over the years and it's no surprise that developers who code in it are bound to give way to serious security vulnerabilities, if not too careful.

One such is the recent vulnerability in Log4j, also nicknamed as Log4Shell - this particular vulnerability was so severe and the extent of which was so huge that it wreaked havoc on the internet and ruined Christmas for almost everybody that was responsible to fix the mess. In this blog, we'll be understanding the why and the how that led to this chaos.

What is Log4j?

Log4j is one of several java-based logging frameworks and comes under Apache's Logging Services. Being open-sourced, it is and has been maintained by contributors from all over the globe since many years (more on this later).

It logs events - from errors to diagnostic messages and more, so that system administrators and developers can look at them later. For example, when you try to login on a website and it shows an error message like incorrect password, log4j can be used to record that.

Some Technical Jargon

Let's understand some technical terms related to log4shell before we move forward and dive deep into it. This will make concepts clearer.

Java Naming and Directory Interface (JNDI)

Java has a lookup feature called JNDI, which is an interface that allows java applications to access naming and directory services. It has an API and a SPI. Different naming and directory services like LDAP, DNS, and RMI connect to this JNDI SPI which is then accessed by the java application using the JNDI API, the diagram below illustrates this.

So, this is basically like asking your friend to get you something from someone in a different hostel room. You tell your friend the path (the protocol), the room number and the item (the file path) you need to get. Here you act as the java application, your friend acts as the API and SPI.

Remote-Code Execution (RCE)

Remote-Code Execution, or RCE for short, is a class of vulnerabilities which allows an attacker to execute arbitrary code on a remote device. These RCE vulnerabilities can be a result of a variety of things ranging from Injection attacks (SQLi, HTML injection, PHP injection, etc.), Cross-Site Scripting, De-Serialization attacks to even Business-Logic flaws.

Say for example, you use a certain software for taking notes. A malicious* hacker finds a vulnerability that allows them to achieve RCE. The implication of this is that they can run any command they want on your computer! Using the RCE exploit, the attacker can launch a ransomware attack against you and lock your data, they can spy on you or steal your passwords or even make you part of a secret botnet!

Every time you use a piece of software you're essentially putting incredible trust in the security and integrity of the said software. Scary isn't it?

*A small note about "hackers"

The term "hacker" is often misrepresented due to pop culture and ignorant news reporting - not all hackers wear hoodies, sit in a dark room with green text flashing before their eyes! In fact, the term "hacker", in its right sense, is used for an individual who uses their extraordinary skills in computer, networking or other domains to overcome technical limitations and problems.

Not all hackers are bad and malicious! There are indeed hackers who use there skills to do illegal activities, but it's only a subset of the whole cybersecurity community - contrary to popular belief, majority of hackers are actually dedicated to make the internet more secure!

How does Log4Shell actually work?

We now know about Log4j, JNDI and RCEs, let's discuss how this relates to the Log4Shell vulnerability. Log4J allows JNDI lookups to enhance the quality of logs. A use-case of that might be logging the hostname or the IP address with the diagnostic message.

For example, ${jndi:ldap://example.com/file} asks JNDI to use the LDAP protocol to get the specified file hosted on the LDAP server. JNDI returns the object to log4j and it stores it. Now you might already know where this is going - Untrusted JNDI lookups to attacker-controlled servers!!!

An attacker could submit a string specifically crafted to tell log4j to use JNDI and retrieve a malicious payload hosted on the attacker's server. Log4j will store the object and Java will execute it resulting in RCE!

Initial Detection and The Impact

Believe it or not, this vulnerability was discovered on a Minecraft server! So, all this chaos was a result of just some gamers messing around - internet is a gift that keeps on giving!

The impact of this is HUGE. Every single service that uses Java and Log4j for their logging purposes might be vulnerable to log4shell. iPhone, Steam, Minecraft, Twitter, Google, Tesla, Microsoft were just among some of the biggest vendors affected by this.

Although a patch was issued, the impact doesn't stop here. There might still be hundreds of thousands of websites affected by this and they won't even know about it until much later. It is estimated we'll see the implications of this for years to come.

On March 22 2022, Okta was hacked where it is believed to be the work of LAPSUS$ hacker group. It is being speculated that the hack was a result of an earlier log4shell exploitation in Okta's infrastructure.

What led to this?

Looking at all of this, a question arises - How did all of this even happen? What led to this? Didn't anybody catch it earlier? The thing is that Log4j is open-source. Lots of contributors spend their time and effort in contributing to this and hence, this type of overlook in development is perfectly normal and possible.

The surprising part though, is that this vulnerability has existed since 2013! This means for almost 9 years it went undetected even after several researchers warned about untrusted JNDI lookups and attack vectors involving it. As a community, we need to be proactive in researching and mitigating issues like these before they pop up.

---

Closing Remarks

The likes of Log4Shell RCE vulnerabilities are said to be found once in a decade - and we saw this type of damage done by EternalBlue used during the WannaCry ransomware attacks. It poses a question - What's waiting for us in the future and How many more vulnerabilities like these are still out there, just waiting for another gamer to stumble upon them?