Log4j Protection

What can administrators do?
What can end users do?

Race between hackers and system administrators

Since the security gap Log4j / Log4Shell was discovered, described and published on the Internet, the race between attackers and administrators has started. Who is faster, attackers who have been exploiting this security gap since it became known, or the system administrators with the installation of suitable Log4j protection or with the installation of updates for all vulnerable applications?

 

 

 

 

What can administrators do?

A security gap that has existed for years has been discovered in the Apache Log4j component of the Java programming language, which enables attackers to send manipulated requests to servers or vulnerable applications. The malware is then executed in the server in order to compromise, control or hijack the server. Since the reaction time of the system administrators is highly critical in this case, there is simply no time to wait for updates from all vulnerable applications to be installed. Because the security gap is only closed when the last update of a vulnerable application is installed.

But when the manufacturers of the different server applications come out with a correction of the security vulnerability themselves differs, and each individual vulnerability is a danger.

The only practicable solution in this time-critical race is general Log4j protection that can be used for all server applications.

We offer a Log4j protection free of charge as open source.

According to the statement of the Apache Log4 project (https://logging.apache.org/log4j/2.x/security.html) on CVE-2021-44228 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228), this vulnerability can be blocked by setting the system property log4j2.formatMsgNoLookups to true when the Java virtual machine is started.

The problem with this seemingly simple solution is: where do you do it? At what point can you accommodate that these parameters reach the respective services? Complex script scenarios when starting services make it opaque, and every manufacturer has different structures for this.

In the following we offer a simple, general and universally applicable solution on Linux systems with systemd services. We provide our solution in accordance with the CC-BY-SA license. Our solution can therefore be freely passed on, used commercially and further developed as long as our name - Tarja - is still used. Liability, support etc. are excluded, as is usual with this license. By using the following code you agree to the named license.
By using the following link you agree to the named license.  

https://github.com/tarja1/log4shell_fix

 

 

 

What can end users do?

A security hole was discovered in a widespread Java component that has allowed attackers to infect or control third-party computer servers for years. Thousands of applications such as Amazon, Apple iCloud, Steam or Twitter are affected.

End users and their end devices are normally not affected by this security gap.

The system administrators need to react.

The effects of this security gap are grave worldwide. Due to the enormous number of servers and applications at risk, system administrators have to be faster than the attackers who are exploiting this security gap, which is now known to all.

All servers and all vulnerable applications must be protected by installing software updates and the security gap is only closed when the software update for the last vulnerable application is installed. Time is the critical factor here for system administrators. It just takes too long to install so many updates. To gain time, system administrators use application-independent protection to protect their servers as quickly as possible and then gradually install updates for all vulnerable applications.