As news of the Apache Log4j logging library bug has spread, it has quickly become known as one of the most significant recent global cybersecurity vulnerabilities

You have likely heard the news of the Apache Log4j (also known as Log4Shell) vulnerability that emerged in early December 2021 and was almost immediately exploited in the wild, sending security operations centres and administrators into a panic across the globe.

As news of the Apache Log4j logging library bug has spread, it has quickly become known as one of the most significant recent cybersecurity vulnerabilities, due to the ease of exploitation and the widespread use of Apache Log4j. This Java library logs error messages in applications and services used by enterprise applications and cloud services.

It has been estimated that more than 89 percent of all environments across organisations and cloud providers have vulnerable log4j libraries.

Log4j – What Happened?

On November 24th, 2021, Alibaba Cloud’s security team reported to Apache a critical remote code execution vulnerability (RCE) impacting at least Apache Log4j 2 (versions 2.0 to 2.14.1).

A remote code execution (RCE) vulnerability in such a widely used piece of code is significant as attacks against RCE vulnerabilities often are designed to give an attacker administrative access to a vulnerable system.

On December 9th 2021, Apache issued a patch for the vulnerability, with the Common Vulnerabilities and Exposures designation of CVE-2021-44228 and the highest severity rating of 10.0 at the time.

Also, on December 9th, 2021, hot on the heels of Apache’s announcement of the vulnerability, the first proof-of-concept exploit was published on GitHub.

By December 10th, threat intelligence sources began to report mass scanning activity from multiple hosts checking for servers using Apache Log4j. Attacks attempting to exploit RCE vulnerabilities are typically prefaced with automated reconnaissance scans used to identify the vulnerable version of software on the target.

Once a target is identified via a scan, the Apache Log4j vulnerability can be exploited by a specially crafted string parsed and processed by the vulnerable Log4j component, permitting unauthenticated remote code execution, potentially resulting in full access to the target system by the attacker.

However, Apache’s initial patch did not address the risk entirely, resulting in a new CVE-2021-45046 and a second patch on December 13th, 2021.

Apache addressed related vulnerabilities with a third patch on December 17th (CVE-2021-45105) and a fourth patch on December 28th (CVE-2021-44832).

How is Log4j Being Exploited?

There is no requirement for attackers to have prior access to impacted systems. Remote exploitation of the vulnerability executes the logging event using commands like curl. Processing of the log results in the vulnerable system running the string. In the attacks seen thus far, the string has been used to execute code from malicious domains.

Initial reports suggested disabling message lookup functionality by adjusting the log4j2.formatMsgNoLookups environment variable to true or deleting the JndiLookup.class from impacted JAR files would mitigate the vulnerability. However, Log4j is often present in other files as a bundle or within a shared library, making these workarounds cumbersome, difficult to verify, and not always possible due to impacts on systems that rely on Lookups for message formatting.

These initially suggested workarounds were found not to mitigate the risks completely; however, they may provide greater defence-in-depth when combined with the latest patches.

There is also a significant challenge in detecting and mitigating all instances of the Log4j on any given network. According to Yotam Perkal, vulnerability research lead at Rezilion, “Java files (such as Log4j) can be nested a few layers deep into other files and may be packaged in many different formats which creates a real challenge in digging them inside other Java packages.”

After testing nine Log4j vulnerability scanners, Rezilion found that none could detect all formats, illustrating that no single tool can detect every edge case in a scenario where there are a great many edge cases.

Expect an Increase in Ransomware Activity that Utilises Log4j Exploits

The Australian Cyber Security Centre (ACSC) has indicated that ransomware groups known to have previously attacked Australian organisations are now leveraging the Log4j vulnerability. ACSC expects this will increase ransomware activity that utilises Log4j exploits as a vector.

For example, the Conti ransomware is a ransomware-as-a-service (RaaS) affiliate program that has been successfully deployed to target networks worldwide, including Australia.

Multiple Australian organisations have been impacted by Conti ransomware in November and December 2021.

Threat actors who utilise ransomware such as Conti typically take advantage of any newly disclosed vulnerabilities, such as Log4j, as quickly as possible after disclosure, before the window of opportunity closes and network owners apply patches and mitigations.

Critical Infrastructure Vulnerability Exacerbated by Pandemic Impacts

Worryingly, Conti affiliates have been observed targeting critical sectors, most notably healthcare organisations. Part of Australia’s National Critical Infrastructure, the Healthcare and Medical sector is currently experiencing the extreme burden of the Covid-19 Omicron variant wave. Ransomware attacks on this sector could not come at a worse time.

The pandemic’s impacts are also rippling through other Australian Critical Infrastructure sectors, including Food and Grocery and Transport. Australian supply chains are currently vulnerable as the Omicron variant surge exacerbates existing stressors, such as pallet and transport capacity shortages. Limits are being introduced to certain Grocery items in Australian supermarkets, while the demand for online Grocery orders are surging as people isolate themselves to prevent the further spread of Covid-19.

Ransomware attacks against these and other sectors are now more likely, thanks to the Log4j vulnerability. This highlights the urgency for all organisations to implement protective measures against this severe vulnerability, as the current confluence of circumstances threatens Australia in ways that were unimaginable a few years ago.