Log4j is a Java-based logging utility that allows logged messages to hold format strings that reference outside information through the JNDI (Java Naming and Directory Interface) or in other words it is a development framework that allows developers to add error and event logging into their Java applications.
In Apache, Log4j allows the remote retrieval of information across a variety of protocols, including LDAP (Lightweight Directory Access Protocol).
And the interesting fact is that Log4j is used by millions of Java applications on the internet.
JNDI (Java Naming and Directory Interface) is an API (Application Programming Interface) which provides naming and directory functionality to applications written using Java Programming Language.
LDAP (Lightweight Directory Access Protocol) is an open and cross-platform protocol that is used for directory service authentication. Directory services store a lot of important information like user account details, passwords, computer accounts, etc which is shared with other devices on the network.
JNDI enables Java applications and objects with a powerful and transparent interface to access directory services like LDAP.
On December 10th, 2021, a public vulnerability for Apache Log4j 2.0 was discovered and called Log4Shell (CVE-2021-44228). It is an RCE (Remote Code Execution) vulnerability, and according to recent statistics, nearly a third of all web servers worldwide have been compromised, making Log4j a potentially catastrophic circumstance for the technology world.
Since it is an RCE vulnerability and a public exploit, even amateur hackers can trigger exploitation on organizations in a matter of time. Threat actors have already exploited several infected applications and managed to install malware including miners, botnets, and Cobalt Strike beacons, that can even perform DOS (Denial-Of-Service) attacks.
And according to latest reports from BitDefender, it was found the ransomware family ‘Khonsari’ can also be installed directly via Log4Shell exploits.
The first step towards mitigation is to scan and ensure whether your application is using the vulnerable Log4j versions ≤ 2.14.1.
If it has been detected, try updating to version 2.16.0, which is said to completely disable the JNDI by default.
Another mitigation strategy is to add the Java parameter -
In versions from 2.10 to 2.14.1, this will set the system property
‘log4j2.formatMsgNoLookups’ to true or remove ‘JndiLookup’ class from the ‘classpath’.