Log4J, a logging system used by java based program within enterprises and even used by Microsoft based minecraft could have been exploited by hackers. The vulnerability that utilized log4j to deliver malicious java script code into systems and later have remote control has been found and CISA had issued an alert (CVE-2021-44228) . An emergency release has been made available by Apache since then.

As of now, most of the vendors including AWS, IBM, Google cloud etc have given statements on what state they are in. If you are using any version less than 2.15 (< 2.15)

In simple terms, if you are having a web application, then there is a high chance that you are impacted by the log4j, log4shell zero-day attack, CVE-2021-44228 . There are several systems which uses Log4J. Therefore it is very important that the approach to mitigate, be in place. If you are working with 3rd party developers, then it becomes important for the 3rd part developers to be engaged in investigating the exploit as an emergency engagement. The vulnerability allows for unauthenticated remote code execution. Log4j is an open source Java logging library developed by the Apache Foundation. Several components such as the application server, distributed stream servers are all using Log4J. So if you are using any of the following components within your web application, then there is a high chance that your systems would have been impacted by the exploit. Some of the common systems include :

• Spring Boot that utilized log4j
• Apache Solr
• Apache Spark
• Apache Struts2
• Apache Tomcat
• Apache Hadoop
• Apache Druid
• Apache Flink
• Apache NIFI
• Apache Kafka
• Apache flume
• VMWare components (Some of them)
• and More…

Further more affected services include Cloudflare, iCloud, Minecraft: Java Edition,Steam, Tencent QQ, and Twitter, linkedin, webex, Redis etc are some of them. Looking at the list above, we could realize the impact this vulnerability could create.

The solution would be to simply replace all log4j versions with the latest. The challenge remains to be the one where developers will try to find which are libraries and systems are using the logj library to log files. In Java, libraries can be embedded with another library and can have one library deployed. This will make it difficult for developers to trace various log4j versions.

Some of the actions that could be taken include, scanning for the older versions of lof4j, scan sub libraries that carry the library, look for stack that is given above and try to replace the old version, finally, look for stealth mode attacker modules still residing within your servers.

All these boil down to the one small yet very significant question. Should enterprises take up code that is pre-compiled. How much of code review needs to be done. What process needs to be attached in reviewing ? what process need to be adopted for such opensource code compilation? and more. We know, opensource is the way to go for any organization. The fact that it gets tested by the world as opposed to a group of people testing it makes it very important to rely on opensource. The attack on log4j as some ignorantly point the blame on opensource needs to be neglected.