It’s been nearly four months since Alibaba Cloud’s security team first reported a remote code execution (RCE) vulnerability within Apache Log4j (also known as Log4Shell). Due to the popularity and widespread use of this application, it very quickly became a top priority for security operatives and administrators around the world.
Within weeks, Apache issued a patch for the logging library vulnerability (CVE-2021-44228), accompanied by the highest severity rating of 10.0. Despite the quick response, it is estimated that more than 89% of all environments across businesses and cloud providers have vulnerable Log4j libraries. This particular RCE vulnerability posed an enormous threat to affected organizations, given how widely used the application is around the globe. Suddenly, adversaries had unlimited administrative access to a very vulnerable system.
The Story so Far
It was all hands on deck to try and get on top of the vulnerability. At the same time, threat intelligence sources started reporting mass scanning activity from several hosts checking for severs using Apache Log4j—the hunters had arrived.
From past experiences, experts concluded that attacks on RCE vulnerabilities usually began with automated reconnaissance scans to first identify targets with vulnerable versions of the software. Attackers then exploited the vulnerability using a uniquely crafted string which is processed by the vulnerable Log4j component, enabling unauthenticated remote code execution, potentially resulting in full access to the target system by the attacker.
Unfortunately, the first patch released on December 9, 2021, did not address the full risk, so a new CVE-2021-45046 was released and Apache distributed a second patch on December 13. This was followed by two additional patches on December 17 and 28, 2021.
The Stages of Response
While Apache worked quickly to release the necessary patches, criminals were moving equally as fast to exploit the vulnerability. To make matters worse, attackers required no prior access to the impacted systems to exploit the vulnerability, since it could be attacked remotely.
The initial recommendation was to disable the message lookup functionality by adjusting the LOG4J2.formatMsgNoLookups environment variable to true or even deleting the JNDILookup.class from impacted JAR files to help mitigate the vulnerability. Organizations quickly encountered another problem, however; as Log4j is often present in other files as a bundle or within a shared library, these workarounds were challenging, difficult to verify and not always possible due to their impact on systems that relied on Lookups for message formatting. While these recommendations did not mitigate the vulnerability risks completely, they did deliver a greater level of defense when combined with the latest patches.
Despite all the efforts made to mitigate the fallout from the vulnerability, security analysts soon discovered greater challenges when it came to detecting all instances of Log4j. Research from Rezilion showed that “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.” Rezilion tested nine Log4j vulnerability scanners and found that none of them could detect all formats of the vulnerability, thereby showing that no single solution could effectively respond to such a widespread vulnerability.
Elevating to Ransomware
There have been several cases where the original Log4j vulnerability became a tool used in wider ransomware campaigns. In particular, the Australian Cyber Security Centre (ACSC) reported that ransomware groups known to have previously targeted Australian organizations joined the horde already exploiting the Log4j vulnerability.
Unsurprisingly, the issue went from zero to hero in no time at all—and once ransomware entered the ring, the fallout risk became catastrophic.
Newly disclosed vulnerabilities offer huge advantages to criminal groups that have ransomware in their armory if they act fast, which is why it became imperative to circulate the necessary patches and mitigations as soon as possible.
An Increase in Infrastructure Vulnerabilities
Apache Log4j is used around the globe, which exacerbated the risk of exploit when the vulnerability hit. Combined with the difficulties posed by the pandemic, this fact made for a challenging time for affected organizations and the impacts are still seen today.
Known ransomware-as-a-service (RaaS) groups, including Conti, jumped on opportunities like Log4j and often targeted critical infrastructure sectors like health care, transportation and food. The burden these industries are facing due to the latest Omicron variant of COVID-19 leaves them in a vulnerable position and ransomware groups are making the most of it.
Organizations should continue to prioritize protective measures against Log4j and any future vulnerability that may surface. It’s a wake-up call for businesses who may have been lax with their attack prevention and risk mitigation strategies. Vulnerability and threat management is critical to defending against known and unknown weaknesses in an organization’s infrastructure—and businesses should act immediately.