Linode Security Digest December 12-19, 2021

Note: This post was updated on December 15, 2021 and again on December 20, 2021.

This week, we’ll talk about the Log4j2 vulnerability that has many organizations scrambling to patch their systems, but first, we’ll address some concerns from our customers regarding the vulnerability.

Linode’s Response To Log4j2 

• We thoroughly assessed this critical zero-day vulnerability’s risk scope and impact across our entire infrastructure within the first few hours of the public release on Friday, December 10th.
• We observed failed exploit attempts with the help of our defense in-depth security control architecture.
• We have not observed any Indicators of compromise related to this vulnerability in our environment and  we’re continuously monitoring our infrastructure for known IoCs about this vulnerability and others.

Log4j2 Critical Remote Code Execution Vulnerability (CVE-2021-44228)

Log4j2 is the successor of the commonly used Apache logging utility Log4j. This component is written in Java, and it is a part of the Apache Logging Services. According to Oracle, The Java Naming and Directory Interface (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written in Java. 

Last week, Apache published in its Log4j security vulnerabilities page that log4j-core versions between 2.0-beta9 and 2.14.1 contain a serious vulnerability. This vulnerability allows attackers who can control log messages or log message parameters to execute arbitrary code loaded from LDAP servers. In practice, this is exploitable by external attackers. This vulnerability was rated with a CVSS score of 10 out of 10 since it allows an attacker to execute arbitrary code on each affected system. This issue is mitigated by the 2.15 update, which disabled the JNDI lookup behavior based on two Jira issues in early  December and late November. Apache also released 2.17 to address other issues that were later found about the component.

Effects of the Vulnerability

Log4j2 is a popular Java logging framework used by multiple vendors across numerous products. This vulnerability can be easily exploited by manipulating the User-Agent string of HTTP request headers and sending the request to vulnerable systems. Although the User-Agent is not the only header that can be used in this type of attack, a malicious payload will cause the vulnerable Log4j2 component to trigger a JNDI lookup on the malicious server. When the malicious URI embedded in the HTTP headers contains the path to a malicious Java class file, this file is injected into the server’s process and allows the attacker to access the affected system. Multiple payloads and bypasses are currently being observed in the wild, which makes it more difficult to protect against it using common defense mechanisms.

A Diagram Of The Attack

The following diagram from the Swiss Government Computer Emergency Response Team can help understand how the attack works and how to mitigate it.

Affected Products

Many vendors have released statements to aid in the mitigation of this vulnerability, and these statements could be a useful resource for our affected customers. You can find the links down below to read more about the affected products by vendors. This is not a comprehensive list of all the affected products. For a  complete list of affected vendors and their products, you can see the list curated by SwitHak on Github or another list shared by TechSolvency.

• Apache
• Atlassian
• Elastic
• Cisco
• CloudFlare
• Debian
• GitHub
• Minecraft
• Oracle
• RedHat
• Security Onion

Official Mitigation Methods

On the security page of Log4j, Apache states that there are multiple methods to address this vulnerability, but it should be noted that these methods may not work the same in all vulnerable products. Please refer to the vendor’s security statement about the vulnerability for more information.

• Java 8 (or later) users should upgrade to release 2.17.0 to address this vulnerability alongside other recently found vulnerabilities.
• Users requiring Java 7 should upgrade to release 2.12.2.
• If these two steps are not possible, the mitigation is to remove the JndiLookup class from the classpath (shown as log4j-core-*.jar) using a command similar to the one below:

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

We’re proud to share the knowledge with our community to help them mitigate vulnerabilities, whether they’re as critical as this one or less impactful. Feel free to leave a comment below to share your thoughts and suggestions.