Log4J: Yet Another Explanation
Log4j, discovered at the end of 2021, has easily eclipsed the major vulnerabilities of the past decade in terms of damage it can do with minimum effort and the pervasiveness of the vulnerability. For these reasons it has been assigned a CVSS score of 10, the highest that can be assigned to a vulnerability. There have been many explanations available online that try to explain this vulnerability. Here is my attempt to make it as simple as possible and hopefully my style of explanation will help some pepole.
Log4j logging library and Java Naming and Directory service (JNDI)
The vulnerability stems from Log4j, which is a widely used open-source library used for logging errors, user, and traffic information. It is a feature-rich library, one of the features is a lookup of java objects at run time. For example, one could specify a format string in the logs which will go get additional information from servers such as username for a particular user from LDAP, IP address of a particular domain from DNS etc. For this lookup log4j library uses an API called Java Naming and Directory service (JNDI) which can obtain additional information from services such as DNS, LDAP, RMI etc.
How does the exploit work?
A successful exploitation is the interplay of log4j library and JNDI. Criminals exploit the lookup feature of log4j library by crafting a request that logs some information such a failed login attempt or information from the http header. This logged information includes a string that contains a JNDI lookup request. The vulnerability wouldn’t be as severe if the attack was limited to just making a lookup request because this only allows a bad actor to steal information from a user’s machine. But In addition to allowing runtime lookup to arbitrary server, log4js also allows an attacker to execute the java class objects returned by the server, thus making it a critical remote code execution vulnerability.
How to detect if you are vulnerable?
Certain conditions must be met for a successful exploitation of this vulnerability. First the application should be using log4j2 version 2.14.1 or lower, and then the application should be logging inputs from the users, also JNDI lookup is allowed, and finally app is using an older version of java that allows running objects that come from a URL. So workloads on cloud and on-prem must be carefully investigated for all of the mentioned conditions to successfully detect this vulnerability.
What is the impact?
Threat actors are using this vulnerability to compromise user machines to use them for crypto mining, spam, ransomware, information stealing, denial of service attack or just to sell the foothold to other cybercriminals.
Remediation
The quickest fix is to update to the latest version of log4j2 and JRE. These latest patches remove the capability to do JNDI lookups and execute code obtained from URLS. If lookups are necessary, then access can be restricted to only whitelisted servers. Other remediations involve secure software development practices, sanitizing user input and carefully selecting what information to log.
