Log4J: An Exploit that has Global Ramifications

What is Log4J?

Log4J or Apache Log4J is a Java library that offers utility in logging. Logging is the recording of activity by an application. Logging is very useful in determining what your application is doing and increasing the understanding of the application. The most general use case is to catch errors in a try catch clause or another Exception handling method. Log4J is extremely popular, with close to 30 million in downloads in the last 4 months alone[5]. Over 7000 open-source projects have Log4J as a dependency.

What is the vulnerability?

When using Log4J (or any logger), when an error occurs, data is sent to servers, databases, etc of the program with the intended error information or logged information. Attackers intentionally caused errors but instead of just sending the logged data they also sent a malicious payload that resulted in a code injection. This resulted in a remote code execution. An example of the execution could be “read file ‘/naveed/supersecretpasswords’, upload https://getpwned.ru”, where my passwords file could be uploaded to the internet. The range of the remote code execution is unlimited.

Intended usage of JDNI and LDAP Server — Sysdig[6]

The most common form of the exploit has been utilizing the JNDI Interface which looks up objects, detects changes, and binds remote objects. Hackers were able to use their own LDAP server to send the malicious payload through the JNDI Interface.

Attackers usage of JDNI Interface to sent a Malicious Payload — Sysdig[6]

The malicious payload is then executed within the Application and the exploit begins. There have been commonalities in what types of attacks are used through the payload. These include RAT infestations (Meterpreter, Blandabindi, and HabitsRAT), DDoS attacks (Webtoos Malware), Obfuscated HTTP requests, coin-miners, Cobalt Strike, and many more[2]!

Who has been affected and how widespread is the Vulnerability?

Since the vulnerabilities public disclosure on December 10th, 2021, over 44% of corporate networks have been attacked. Cloudflare’s CEO tweeted in early December that they have seen over 400 exploit attempts per second (you are seeing that right, per second) on its network. The most devastating of exploits send malware through the return data. Large corporations and institutions have been attacked such as Microsoft and University servers aimed at gaining industry secrets. Several Countries are involved as well. Chinese, and Iranian hacker groups have been identified as contributing to attacks and further development of the Log4J Exploit. The effects of the exploit do not end after packages have been fixed and the exploit patched. Hackers have been using the exploit to further increase the vulnerability of applications and servers by inserting their own exploits to use at another time.

Has the Log4J exploit been fixed?

In short, no, the exploit has not been fixed. Of the 500 identified packages dependent on Log4J, 187 of them have fixed the exploit and 314 have not currently. While there have been several patches and remedies, there has not been a significant update to the Maven Central repository. The vulnerability is several layers deep for over 80% of the packages used. This requires a complete rework of the inner workings of the packages as most of the packages are over 5 level deep in their Log4J implementation[3]. Since December a massive effort by open-source contributors has resulted in over 13% of have been fixed and the ongoing effort continues[3]. Microsoft has come out with a statement that the Log4J exploit will last several years, and this sentiment has been agreed upon by several experts in the field.

Code Examples of Exploit Implementation:

Questions for Students

  1. Have you used a Logger package before?
  2. Have you been affected in any way? (New Patches you have had to install, Minecraft Servers down, etc)

References

(1) https://logging.apache.org/log4j/2.x/security.html
(2) https://threatpost.com/microsoft-rampant-log4j-exploits-testing/177358/
(3) https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

(4) https://cyber.gc.ca/en/alerts/active-exploitation-apache-log4j-vulnerability

(5) https://blog.sonatype.com/why-did-log4shell-set-the-internet-on-fire#:~:text=log4j%2Dcore%20is%20the%20top,total%20population%20of%207.1%20million.

(6) https://sysdig.com/blog/exploit-detect-mitigate-log4j-cve/

(7) https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-44228/

Join the Conversation

19 Comments

  1. Since the Log4J exploit (I think it’s also known as “Log4Shell” as a reference to the fact that RCE allows for reverse/bind shells to be spawned on the vulnerable machines) was discovered, it’s been a pretty popular exploit to include in CTFs. I’ve participated in a couple of them and tried to perform the exploit myself (although never successfully). It’s crazy to think how such a relatively simply looking input string can cause such massive damage. It makes you wonder just how many of these vulnerabilities are out there in these popular packages/distributions that haven’t been discovered or revealed yet.

  2. Interesting post! Since the beginning of the year, I have been hearing about the log4j exploit, but I never knew why it was such a big talking point, and why it was so important, but this post really highlighted everything in a short and simple to understand manner.

  3. Pingback: Bilad Alrafidain
  4. Pingback: ต่อผม
  5. Pingback: dark168

Leave a comment