Introduction
Log4j is a Java library, used by many development and product teams and is a key Java-logging framework. It is widely used in business system development, included in various open-source libraries, and directly embedded in major software applications.
Apache log4j 2 has historically been vulnerable to process and deserialize user inputs. Two previous deserialization vulnerabilities, CVE-2017-5645 and CVE-2019-17571, were previously discovered, resulting in code injection and further RCE due to a lack of necessary processing against provided user input data.
- CVE-2017-5645: For Apache log4j 2.x before 2.8.2, the log4j servers will deserialize any log events received from other applications through TCP or UDP socket servers. If a crafted binary payload is being sent using this vulnerability, it can lead to arbitrary code execution.
- CVE-2019-17571: For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget.
Log4j Vulnerability
A flaw was found in the Apache Log4j logging library in versions from 2.0.0 and before 2.15.0. A remote attacker who can control log messages or log message parameters, can execute arbitrary code on the server via JNDI LDAP endpoint according to the Github Advisory Database.
A vulnerability in the open-source Apache logging library Log4j sent system administrators and security professionals scrambling over the weekend. Known as Log4Shell, the flaw is exposing some of the world’s most popular applications and services to attack, and the outlook hasn’t improved since the vulnerability came to light on Thursday 9 December 2021. If anything, it’s now excruciatingly clear that Log4Shell will continue to wreak havoc as long as key systems remain unpatched.
This issue has been assigned CVE-2021-44228 and rated with a severity impact of Critical. Logging untrusted or user-controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user-controlled input.
A common pattern of exploitation risk, for example, is a web application with code designed to process usernames, referrer, or user-agent strings in logs. These strings are provided as external input (e.g., a web app built with Apache Struts). An attacker can send a malformed username or set user-agent with the crafted exploit string hoping that this external input will be processed at some point by the vulnerable Log4j 2 code and trigger code execution.
In order to exploit this flaw, you need:
- A remotely accessible endpoint with any protocol (HTTP, TCP, etc.) that allows an attacker to send arbitrary data,
- A log statement in the endpoint that logs the attacker-controlled data.
The attack leverages the remote code execution flaw to download an additional payload, a .NET binary, from a remote server that encrypts all the files with the extension “.khonsari” and displays a ransom note that urges the victims to make a Bitcoin payment in exchange for recovering access to the files. In simple terms, the bug could force an affected system to download malicious software, giving the attackers a digital beachhead on servers located within corporate networks.
Source: https://thehackernews.com/2021/12/hackers-exploit-log4j-vulnerability-to.html
The vulnerability impacts default configurations of a number of Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink, which are utilized by numerous organizations from Apple, Amazon, Google, Twitter, and thousands of others, including Fortinet. The vulnerability is simply triggered by sending a specific JNDI string to the Log4j software which triggers the install of the malicious software as shown.
Log4j is used heavily in external/internet-facing and internal applications which manage and control industrial processes leaving many industrial operations like electric power, water, food and beverage, manufacturing, and others exposed to potential remote exploitation and access. Because this vulnerability is in a Java library, the cross-platform nature of Java means the vulnerability is exploitable on many platforms, including both Windows and Linux.
As many Java-based applications can leverage Log4j 2, organizations should contact application vendors or ensure their Java applications are running the latest up-to-date version. Developers using Log4j 2 should ensure that they are incorporating the latest version of Log4j into their applications as soon as possible in order to protect users and organizations.
Update/Upgrade Options
The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.
To address this vulnerability, Crossvale recommends customers apply the latest security updates to remediate this vulnerability. Please review the Apache CVE and the Apache security advisory for further details:
- Apache CVE: CVE-2021-44228
- Apache security advisory: Apache Log4j Security Vulnerabilities
All systems, including those that are not customer facing, are potentially vulnerable to this exploit, so backend systems and microservices should also be upgraded. The recommended action is to update Log4j 2 to 2.15.0. A service restart will be required.
Conclusion
Many organizations will need to expedite their processes. Embedded software with long release cycles may be at risk for longer durations. Additionally, Log4j is not a casual thing to patch in live services because if something goes wrong an organization could compromise their logging capabilities at the moment when they need them most to watch for attempted exploitation.
Work with Crossvale to quickly verify whether an application portfolio that you’re scanning with us is affected and at elevated risk of being exploited. At Crossvale, we are actively responding to the reported remote code execution vulnerability in the Apache Log4j 2 Java library dubbed Log4Shell (or LogJam). We are investigating and taking action for products and services that may be potentially impacted, and will continually publish information to help customers detect, investigate and mitigate attacks.
In addition to monitoring the threat landscape for attacks and developing customer protections, our security teams have been analyzing our products and services to understand where Apache Log4j may be used and are taking expedited steps to mitigate any instances. If we identify any customer impact, we will notify the affected party. Our investigation to date has identified mitigation steps customers could take in their environments as well as on our services.
References
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
https://thehackernews.com/2021/12/hackers-exploit-log4j-vulnerability-to.html
