What is Apache Log4j? Apache Log4j is software that makes reading logs easy. It is a simple but powerful, reliable, and flexible logging framework for Java-based applications. It has made it possible for developers to write more robust applications with only minor changes to the code. However, Log4j wasn’t designed with security in mind. When you log something, you are exposing your application’s internal data and some user input so that it can be studied afterwards by anyone else who may want to reverse-engineer the application. Log4j logs everything!

A bit more about Log4j…

Log4j as we understand is a Java Library used specifically for logging. Logging is the process of recording all/different types of events for metrics, troubleshooting, analysis. The uniqueness of the log4j is its fast performance, which made most developers to use log4j in their development & production environment.   Java Log4j 1 was released from January 8, 2001, until 2015, when apache announced the end of its support for this version. Log4J 2 was released in 2014, is an upgrade to Log4j and provides significant improvements over Log 4j 1.x  

Apache Log4j vulnerability

The critical problem arose from the fact, Log4j’s JNDI lookup which could not differentiate between a genuine JNDI lookups / against malicious lookup. Any user request which gets recorded via log4j, poses a challenge of triggering the JNDI lookup. The result was the ability for the Log4j library to connect to a predetermined target, which if malicious results in numerous possibilities such as start from data exfiltration, Command & Control (remote code execution), and many more undiscovered ways.   To start the attack, all the attackers need is a simple string in a request or a message that will be logged. It always works, and it neither needs the user to click on links or misconfigure the system, nor does it necessitate access to any internal systems. Many versions of the library had this exploitable feature enabled by default.   Apache Log4j2 versions 2.0-beta7 through 2.17.0 are vulnerable to such remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can take control of remote servers and create havoc.

Is the vulnerability in Log4j widespread?

Well, the answer to this question is a resounding YES! From iCloud, Steam, Fortinet, IBM, Microsoft, Cisco, Vmware, Red Hat, Salesforce, Siemens, and many other companies all seemed to have got exposed to this vulnerability. Log4j is extensively utilized across consumer, corporate systems & vendors, who use log4j to build enterprise applications, which in turn got vulnerable. Patches and security upgrades have already been published by dozens of companies. As per reports its difficult to guess the exact number of users impacted but its estimated to be well over 3 billion.

What can we do for Apache Log4j vulnerabilities?

The first step towards protecting against Log4J, is to identify if log4j library is utilised within the organisation, Vulnerability Scanners help in quick identification of the library & its version.   The next step is ensured JNDI lookup feature is disabled, by installing the patches released by Apache Foundation. There were different versions which got released due to intermediate vulnerabilities, hence the last stable version of log4j and its patch is critical. As on date the latest recommendation is to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later)     The third step is to ensure no malicious connection happens from the production/development servers to external servers directly. A Outbound proxy, that can inspect and allow only trusted connections is vital. With the added protection of NGFW as a perimeter / first level of defence, improves the security of the Organisation a notch higher.   The final step in this entire process, is to bring in a proactive, intelligence protection mechanism such as an Endpoint Detection & Response, which can detect and prevent known/unknown threats such as Log4j exploitation by an attacker. EDR , Proxy, NGFw are 3 foundational controls any organisation need to build better security controls

Conclusion

To sum up patching to latest version of log4j is the only full proof solution. As on date the latest recommendation is to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). Application servers should be installed behind a latest WAF. A vulnerability audit of applications & the code using commercial tools is strongly advised to find the vulnerabilities & patch them.   About SNS Secure Network Solutions India (SNS) provides a quantifiable, risk-based approach to build cyber security based on globally recognized frameworks and standards. We have been protecting business for the last 20 years! Write to us at [email protected]