Dec 14, 2021
0 0

[Updated] Log4j zero-day “Log4Shell” arrives just in time to ruin your weekend

Written by

We research. You level up.
Protect your devices, your data, and your privacy—at home or on the go.
“Thanks to the Malwarebytes MSP program, we have this high-quality product in our stack. It’s a great addition, and I have confidence that customers’ systems are protected.”
Featured Event: RSA 2021
Activate Malwarebytes Privacy on Windows device.
Save 25% on your first year of business protection now. See pricing >

Exploits and vulnerabilities
Posted: by
Last updated:
If you’re running a service that relies on Apache Struts or uses the popular Apache Log4j utility we hope you haven’t made plans for the weekend.
An exploit listed as CVE-2021-44228 was made public on December 9, 2021. The exploit is simple, easy to trigger, and can be used to perform remote code execution (RCE) in vulnerable systems, which could allow an attacker to gain full control of them. All an attacker has to do is get the affected app to log a special string. For that reason, researchers have dubbed the vulnerability “Log4Shell”.
The vulnerability has a CVSS score of 10.0 out of a possible 10. It impacts Apache Log4j versions 2.0-beta9 to 2.14.1. Mitigations are available for version 2.10 and higher.
Log4j is an open source logging library written in Java that was developed by the Apache Software Foundation. Millions of applications use it, and some of them are enormously popular—such as iCloud, Steam, and Minecraft—so the potential reach of this problem is enormous.
A logger is a piece of software that keeps a record of what’s happed on some part of a computer system. Logs can be used to determine if software is running smoothly, or to investigate events leading up to an error if something goes wrong. Generally speaking, IT and security folks want to log as much as they can.
As is the case for many loggers, Log4j also performs some basic operations to make the output easier to understand for us mere humans. One of these operations is variable substitution, which look for patterns like ${something}, and replaces them with other pieces of information.
This vulnerability lies in the replacement of the string ${jndi: This pattern triggers the Java Naming and Directory Interface, which can load Java resources from another computer, anywhere on the Internet.
Unfortunately, lots of applications log data that comes from their users without first sanitising it, and it’s possible for attackers to sneak variable substitution patterns into logs by including them in things like HTTP headers, or input fields.
The vulnerability is triggered with a simple string, sent to a vulnerable server:
When the vulnerable application logs the string it triggers a lookup to an attacker-controlled remote LDAP server ( in our scenario). The response from the malicious server contains a path to a remote Java class file that’s injected into the server process.
Having tricked the vulnerable application into loading their Java class, attackers can use it to execute commands with the same level of privilege as the application that uses the logging library.
After the 0-day was posted on Twitter, along with a proof-of-concept that was published on GitHub, the exploit has already been spotted being used in the wild by CERT New Zealand, CERT Austria, and CERT Germany. Along with many others, they are seeing automated systems trying to exploit the vulnerability.
Given how common this library is and how serious the consequences of a relatively easy-to-exploit vulnerability can be, this is a recipe for disaster. Many organizations will not even realize they are vulnerable.
According to researcher Marcus Hutchins, in the case of Minecraft, attackers were able to get remote code execution on Minecraft servers by simply pasting the malicious string into the chat box. Similar examples exist for a number of other popular services.
Mitigations are available for versions of Log4j 2.10.0 and up. Version 2.15.0 is not vulnerable by default. Note that there may be other dependencies, such as your Java version, that need to be updated before you can upgrade. Fixing the vulnerability may not be straightforward, but it is urgent.
The Apache log4j project advises that if you are unable to upgrade, for whatever reason, you can use the following mitigations:
Sadly, there is little, if anything, that users of affected systems can do to make themselves less vulnerable to the consequences. No doubt many systems will be affected and system administrators will want to treat anomalies with extreme caution.
So, if you’re an administrator looking forward to a quiet weekend, you know what to do!
After close examination of this vulnerability, researchers found that it had been actively exploited prior to the public disclosure, going back as far as December 1. The mass exploitation however, started after the disclosure.
The majority of attacks so far seem to be coming from established botnets like Mirai and others, including some cryptomining botnets. But Microsoft warned that is has seen the some attacks that resulted in a drop of Cobalt Strike. Cobalt Strike is a collection of threat emulation tools provided by HelpSystems to work in conjunction with the Metasploit Framework. But cybercriminals are often using it as a backdoor that provides an ideal foothold to start lateral movement in a network.
As the security community wrestles with the vast scale of the Log4j problem, fears are growing that it may be “wormable” and that an Internet worm could appear in the next few days. (A worm is a piece of malware that infects vulnerable systems and then uses them to find and infect other systems.)
Because their rate of replication is exponential, worms can spread extremely quickly. In 2003, the SQL Slammer worm spread around the world in about ten minutes, and in 2017 the WannaCry ransomware worm spread around the world in a matter of hours, before its kill switch was activated.
The tireless (and let’s not forget—unpaid, volunteer) maintainers of Log4j have released version 2.16.0, which includes two changes. JDNI is now disabled by default, and support for message lookups has been removed completely.
Although that seems a pretty definitive change, this remians a fast-moving situation. Both attackers and red teams are pouring over the potential attack surface of Log4j and we recommend you stay up to date with the latest version, and be ready for further updates.
Stay safe, everyone!

Malware Intelligence Researcher
Was a Microsoft MVP in consumer security for 12 years running. Can speak four languages. Smells of rich mahogany and leather-bound books.
Silouette of person

See all threats
Threat Center

Malwarebytes Podcast

Book with bookmark

Suspicious person

Write for Malwarebytes Labs
Write for Labs

Want to stay informed on the latest news in cybersecurity? Sign up for our newsletter and learn how to protect your computer from threats.
Imagine a world without malware. We do.
© All Rights Reserved
Select your language
Cybersecurity basics
Your intro to everything relating to cyberthreats, and how to stop them.


Article Categories:

Comments are closed.