First disclosed on 9 December 2021, the zero-day vulnerability in the ubiquitous Java logger Log4j 2, known as Log4Shell, sent shockwaves throughout the information security industry as businesses and other organisations scrambled to patch the much-feared flaw.
Log4Shell was given a 10/10 critical rating and is tracked as CVE-2021-44228. Early evidence suggested attacks using the exploit began almost immediately with cryptominers and low-level distributed denial of service (DDoS) attacks observed in the wild shortly after disclosure. Further analysis released days later showed nearly one million exploit attempts were made in the first three days after disclosure.
Microsoft has also confirmed the cyber security community's worst fear which is that ransomware attacks are already utilising the vulnerability after it was first discovered by Bitdefender. The Khonsari ransomware family has already been discovered on machines with evidence pointing to a Log4Shell exploitation to achieve infection.
The security vulnerability is thought to be one that will impact companies for months given how difficult it is to determine whether any given application or service uses the Log4j 2 library. Patching is highly recommended since Check Point researchers also recently revealed a global average of 40% of corporate networks have seen Log4Shell exploitation attempts in the first few days of the vulnerability's disclosure.
Affecting products and services aimed at both consumers and businesses, the critical-rated vulnerability was first discovered in the Java version of Minecraft, and it didn’t take long for the cyber security industry to realise that the specially crafted in-game chat messages that were affecting game servers could function as executable code in a wider range of online services.
Log4j 2 is an incredibly popular online Java library, used by almost all of the online services and products everyday people will be familiar with. Its role is to log information that helps applications run smoothly, determine what’s happening, and help with the debugging process when errors occur.
Patching the vulnerability is considered non-negotiable. The latest version of Log4j 2 (Log4j 2.17.0) mitigates the zero-day flaw and fixes other security issues present in other attempted fixes.
Who is affected by Log4Shell?
Most apps written in Java are thought to be affected and vulnerable, particularly Apache frameworks including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink. In addition, ElasticSearch, Flume, Logstash, Kafka, Netty, MyBatis, and Spring-Boot-starter-Log4j are also vulnerable.
Some of the most popular products and services on the internet - including Apple iCloud, Amazon, Steam and Twitter - rely on these frameworks to function. This is also thought to include a significant number of enterprise and cyber security applications too.
Not all products that use Log4j 2 are vulnerable; cyber security firm Radware said only software enabling and utilising Log4j message lookup substitution is affected. However, Google said more than 35,000 Java packages across the world are thought to wither directly or indirectly depend on vulnerable Log4j 2 versions. There is an issue that with some packages indirectly depending on vulnerable Log4j 2 libraries, developers may not have full visibility into a vulnerable product.
Log4Shell's patching nightmare, and the current safe version
Identity-focussed security for your zero trust journey
Steps to protect your business from identity-driven threats
From version 2.15.0, message lookup substitution is disabled by default which ended the Log4Shell vulnerability, but later developments revealed it was still an unsafe upgrade. Log4j 2 versions 2.0-beta9 to 2.14.1 are all vulnerable and exploitable to Log4Shell.
After it was first discovered to affect Log4j version 2.0-beta9 to 2.14.1, the 2.15.0 patch fixed the core issue. Businesses were encouraged to patch vulnerable products as soon as possible, but the update was later discovered to be vulnerable to a denial of service (DoS) exploit. The flaw was initially considered to be low severity (rated 3.7 and tracked as CVE-2021-45046), but it was increased to 'critical' status (9.0 rating) after researchers realised data exfiltration could be faciltated by exploiting the issue.
Version 2.16.0 was released shortly after only for it also to suffer from its own highly rated (7.5) DoS vulnerability, tracked as CVE-2021-45105. Apache has now released the latest 2.17.0 version and all organisations thought to have Log4j dependencies are advised to update instances to the third release since the critical vulnerability's disclosure.
How can Log4Shell be exploited and what can happen?
Cyber security vendors widely reported the RCE vulnerability in Log4j 2 was already being actively exploited in the wild shortly after the flaw was made public, with exploitation being easy to achieve at that.
In addition to logging basic data within an application, the Log4j 2 vulnerability leverages Java Naming and Directory Interface (JNDI) injection. In certain cases, logged data originates from user input - which can also be supplied by an attacker - and if this input contains special characters, and is logged using Log4j 2, the Java method ‘lookup’ will be called to execute the user-defined remote Java class in the LDAP server. This will lead to the RCE on the victim server that uses the vulnerable Log4j 2 instance, according to Unit 42 at Palo Alto Networks.
This can be achieved because JNDI does not enforce security controls on LDAP requests, meaning the application can contact a server hosting a malicious payload, download and execute it, all without any authentication.
At the moment, there are no known major exploitations of the vulnerability leading to devastating consequences. However, Microsoft reported the majority of attacks have been related to mass scanning - attackers trying to identify vulnerable systems, security companies, and researchers. It also said Cobalt Strike beacons have been dropped.
Radware reported Mirai-based DDoS botnets being actively deployed, adding that crypto-locking and crypto-mining malware can easily be delivered. Wider reports have already noted evidence of ransomware using the vulnerability as an entry point.
How to mitigate Log4Shell
Businesses are advised to assess to what extent their environments are exposed to Log4Shell and patch Log4j 2 instances accordingly. Log4j version 2.0-beta9 to 2.14.1 are affected with the general recommendation being, as with any vulnerability, to patch affected instances up to the latest available version which is Log4j 2 2.17.0.
Reuven Harrison, chief technology officer at Tufin, told IT Pro that businesses need to restrict outbound connectivity if they cannot patch immediately.
“To prevent these kinds of attacks, organisations should restrict egress (outbound) connectivity,” he said. “Each subnet, server and workload should be allowed to connect only to the endpoints that are required by business. All other destinations should be blocked.
“Blocking egress connections is easy with standard security controls such as firewalls, but defining the policy, which egress connections are allowed, is tough. Doing this properly requires continuous learning of legitimate application connectivity patterns, and enforcement in production environments.”
According to the National Cyber Security Centre’s (NCSC) advisory, the flaw can also be mitigated in previous releases (2.10 and later) by setting system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath.
The national cyber security body also noted that identifying which applications are vulnerable may not be an easy task, which is why early and transparent communication with customers, as with any incident, is important to enable them to apply any available updates too.
Keeping tabs on Log4Shell development
Given how wide-ranging this vulnerability is, the cyber security industry has banded together to help keep track of evolving exploits and fixes. There is currently a GitHub repository listing Log4Shell indicators of compromise (IOCs) with links to individuals and groups actively tracking Log4Shell’s exploitation, in addition to a range of threat reports from individual researchers and cyber security vendors.
There is also a Reddit ‘mega thread’ users can follow which is regularly updated by the community with links to third-party advice, evidence of exploitation, analyses, honeypots, and more.
