Log4J Vulnerability: A Legacy of Cybersecurity from Java to Blockchain and Minecraft

Who:

This is a cybersecurity attack specifically targeting the logging behavior of software. There are many developer pipelines that use Java-based logging. If you track licensing (LDAP) or just run basic best practices on logging your network activity this could already have affected you. The problem with this type of attack is that it is very simple to exploit. All you need is user-level access and the ability to insert a string that is input into a log from Log4j (Shell4j).

Does it affect you?

You can use this on your application endpoints. To be clear: this also means that anyone on the internet can see this vulnerability from your endpoints.

What:

It’s a class trick in Java, exploited:

“Any of the log strings that get passed to it gets interpreted. The developer meant only special commands that went from them but the data was coming in from an end user, but think about all the things an application logs: user agent, header, file request, messages, you name it, and that gets executed.”

It targets specifically the logging \\ the logging on all architectures. we’ve seen this have the biggest impact on a non-java, java-logged ecosystem.

Where:

This process uses a combination of and to cause the code to inject, pull or nullify data in real-time. We have also now seen the use message expansion can execute code to leverage a different class that isn’t JMVI.

The concern in real-time is if extraction and injection are done in parallel for sensitive databases, where malicious injection can be covert. We should expect that kind of curiosity to expand on the surface of national security.

Right now we don’t know how many of these injections are going to come in, and they are all trojanized. We need to remove all known sensitive impacts of this, and it’s everywhere. There really isn’t a national security alert for this, we need everyone who has used this package to update as a matter of security. This specifically is the first instance of a long series of new cybersecurity attacks that could happen if we don’t let the public know they are coming, and mitigate them.

That’s why it doesn’t matter what JRE you are using. The only way to present this behavior is to either upgrade (disable the message expansion by default). This is going to lead to a never-ending chain of exploits.

How:

This means that if people are not updated to the new version those architectures are vulnerable until patched. What is important here is the idea of a zero-day in cybersecurity and how many security teams are going to experience that for the first time because of this kind of exploitation. It is clever and this style of attack is going to evolve.

“​​It’s as simple as changing your twitter handle or your home address.” Ilkka Turunen, explaining how a malicious end user turns can turn the keys of the log4j exploitation to deliver trojanized, executable code.

Blast Radius:

Any of the log stream that gets passed to it gets interpreted. This is a log framework that supports a lot of other log frameworks. A lot of the vendors that have the ability to see network traffic have put in specific signatures looking for these LDAP hits and payload downloads but hate to use the Covid analogy, as this evolves…we are already seeing new variants of this attack. They are going to have different network signatures, in fact some might not have a network signature.

This goes way beyond Java based projects. A lot of blockchain stacks, for example, aren’t written in Java but a lot of Blockchain monitoring tools are. In this attack a bad agent can insert the target string into the payload and it gets logged.

“One of the reasons this is so impactful is that we all use log4J to record information to diagnose problems later on. One of the things you do then is to capture the data as it comes in as is, so we have  a situation where any sort of data sanitisation is never going to happen” Steve Poole

This attack falls under the loose category of malicious injection, meaning it means that fundamentally this was not the exploitation of a bug: this is an exploitation of exactly how this code was engineered to work.

Updates on the Vulnerability:

Log4Shell can now be identified by its number CVE-2021-44228. , is a vulnerability in the popular . This vulnerability was privately disclosed to Apache by 's Cloud Security Team on 24 November, then was publicly disclosed on 9 December 2021.

Impact Blast and Original Report:

This has affected everything from Blockchain to . The internet is on fire with a major vulnerability from the Java ecosystem.

“There’s the original thing [that you intend to log] but the other thing is that because this has substitution string replacement…it’s very easy with things like JVM class substitution, which turns out to be really easy now with this attack.” Brain Fox

What to do:

The advice is to upgrade to the latest version, but it's important to understand that this type of attack is likely to happen again, as it's not actually exploiting a bug, it's doing just what the logging tool is intended to do and bad actors have figured out how to chain a series of events together to exploit that.

Why it matters: Even if your team is using another form of logging framework, they may be leaning one Log4J under the hood. We’re already seeing new variants of this attack, some may not have network signature. All developer teams are impacted by this.

Remediation at:

. *Recommend this for code fix

Hackernoon Remediation Guide

TDLR: This is a really simple and easy-to-understand attack, but its impact radius is going to be one of the biggest we’ve ever seen. That’s really simply because it’s attached cleverly to a logging framework. A lot of new architectures that aren’t written in Java are logged by it: Blockchain isn’t written in Java but a lot of logs and monitors (or exchanges are). THAT is what this attack went for.