Log4j Exploit (What, Why, Fix and Hacking Examples)

Just before the end of 2021, a big security flaw was discovered in Log4j, which caused abnormal panic, a large number of new memes and even forced non-IT people to investigate what happened and why there is so much hype.

In short, it is the most popular Java library used for logging (creating files with the .log extension and printing important information to the console). It sounds very simple, but for some reason there is a function to download and execute code from another remote location. Which means that hackers are able to insert their code that will be executed on the victim’s system. Version 2.15.0 was released in an attempt to fix this flaw, which affected versions 2.0 – 2.14. Unfortunately, that version also had its problems, it was constantly patched. So now we have a lot of jokes about Log4j and the current version 2.17.1, which does not have these hitherto known problems.

The Fix

For large companies with huge projects, it is not that easy to use another log library, such as Logback. So the only way to fix this, without changing all the code and configuration files, is to constantly update to the latest version. Note that if you don’t use Log4j directly, it is possible that other libraries have it as a dependency, so they need to be updated as well.

<properties>
	...
	<log4j.version>2.17.1</log4j.version>
</properties>

<dependencies>
	...
	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-core</artifactId>
		<version>${log4j.version}</version>
	</dependency>
	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-api</artifactId>
		<version>${log4j.version}</version>
	</dependency>
	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-slf4j-impl</artifactId>
		<version>${log4j.version}</version>
		<scope>test</scope>
	</dependency>
</dependencies>

The Hacking (For Beginners)

For me, always the most interesting part, it’s time to put on our gray hat.

The simplest approach would be to search for public online services/websites that use Java and bombard them with, for example, this sting:

${${::-${::-$${::-j}}}}

The result could be a service shutdown or some background error, but we still don’t have much response, so a safer and simpler method is needed.

Identify vulnerable servers (Log4j v2.0 – 2.14.1)

This time we target all the input fields on the website (search box, contact form, login form) to trigger a DNS query. First a Log4jShell token will be created using canarytokens.org. Of course you can take a temporary email or your real email address.

Now you choose a company that you don’t really like and insert that token wherever you can.

You submit all inputs and if you get mail…

If you receive an e-mail, you know that the site is not protected. Of course the first thing you will do is to inform your dear colleagues about the security hole until someone puts on a black hat and starts executing all sorts of code.

Leave a Reply

Your email address will not be published. Required fields are marked *