Last Updated: January 10, 2022 (This post will be continuously updated)
What is log4j and the Exploit, Log4Shell?
A zero-day exploit in the popular open source Java logging library log4j2 was discovered on Friday, December 10, that results in remote code execution (RCE) by logging a simple string. This library is used in hundreds of millions of commercial and open-source applications as a logging framework for Java. The vulnerability, CVE-2021-44228, and the exploit, named Log4Shell, is easy to execute and could result in full server control. All an attacker needs to do is target a vulnerable application and log a special string. An attacker who can control log messages or log message parameters can then execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
Affected versions of log4j include 2.0-beta-9 through 2.16.0, and the patches that have been issued are as follows:
- On December 10, 2021, Apache released Log4j 2.15.0 for Java 8 users to address a remote code execution (RCE) vulnerability—CVE-2021-44228 (rated “Critical” with a CVSS severity rating of 10/10).
- On December 13, 2021, Apache released Log4j 2.12.2 for Java 7 users and Log4j 2.16.0 for Java 8 users to address a RCE vulnerability—CVE-2021-45046 (rated “Critical” with a CVSS severity rating of 9/10).
- On December 17, 2021, Apache released Log4j 2.17.0 for Java 8 users to address a denial-of-service (DOS) vulnerability—CVE-2021-45105 (rated “High” with a CVSS severity rating of 7.5/10).
The more time that passes before an organization patches this vulnerability, however, the higher the risk of a severe malicious incident occurring. As a result, Resilience encourages all of its insureds to check whether you are running vulnerable versions of log4j and patching any vulnerable systems as soon as possible. It is also important to continue to monitor developments of this vulnerability and related exploits.
Threats Associated with Log4Shell
Since the vulnerability became publicly known, threat actors have been conducting mass scanning to identify vulnerable systems to exploit. Threat actors have various objectives when exploiting the vulnerability (from profit to cryptomining to data exfiltration to espionage), and the true extent of the damage has yet to be revealed.
Microsoft reported on December 16 that nation-state groups from China, Iran, North Korea, and Turkey are now abusing the Log4Shell (CVE-2021-44228) vulnerability to gain access to targeted networks.
Cybercriminal gangs who specialize in gaining access into organizations have also started leveraging the log4j vulnerability to gain initial access into targeted networks, with Conti being one of those groups. Ransomware that leverages Log4Shell has already begun to emerge, the first of which is named Khonsari. While Khonsari is a relatively basic ransomware variant, this serves as a harbinger for more sophisticated threats to come.
First of all, do not freak out, and be wary of emails from outside your organization with links or attachments attempting to take advantage of the chaos surrounding with log4j.
The most effective solution is to patch vulnerable systems immediately: Any organization using log4j should update to the latest versions as soon as possible, and as new versions come out, to update the recent version in order to reduce any possible exposure. The vendor initially addressed the reported vulnerability in version 2.16.0, however, 2.16.0 was vulnerable to denial-of-service attacks and the latest patch, 2.17.0 addresses the initial RCE vulnerability and the denial-of-service vulnerability.
The latest version is 2.17.0 and can be found on the Log4j download page.
Alternative solutions, or if patching is not available:
- If you cannot firewall or segment the potentially affected product from your environment, consider shutting it off completely (i.e., power it off until you can apply the appropriate solution);
- If running End of Life (EL) 1. version, it should not be used and it is recommended to upgrade to a current supported version;
- As a workaround, pattern layout lookups within message text can be disabled by setting the “formatMsgNoLookups” option to “true”. Please note that this option is only available in version 2.10.0 and later;
- If updating versions is not possible, network administrators can also mitigate exploit attempts by setting the system property “log4j2.formatMsgNoLookups” to “true”; or by removing the JndiLookup class from the classpath.
Affected Services and Third-Party Risk
For your reference, a non-exhaustive list of popular potentially vulnerable services is below.:
- Apache Druid
- Apache Solr
- Apache Struts2
- IBM Qradar
- Palo Alto Panorama
- Ubiquiti UniFi
- VMWare Horizon
- VMWare vSphere
- VMWare vCenter
Your organization should also contact vendors and third-party providers to ensure that they are patched against Log4Shell. You should ask whether they use any software the relies on log4j, and if so, if they’ve executed any mitigations.
- Department of Homeland Security, Cybersecurity and Infrastructure Security Agency log4j vulnerability guidance: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
- Department of Homeland Security, Cybersecurity and Infrastructure Security Agency log4j mitigation and related vulnerabilities: https://www.cisa.gov/uscert/ncas/alerts/aa21-356a
- List of vendors with responses to log4j vulnerability: https://4jfinder.github.io/
- List of IPs attempting to exploit the vulnerability: https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
- List of products and services that may be affected: https://github.com/NCSC-NL/log4shell/tree/main/software