Log4Shell a year on

A year ago, in December 2021, the Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library caused a sensation. Although by the spring it was no longer on the front pages of IT media outlets, in November 2022 it reemerged when it was reported that cybercriminals had exploited the vulnerability to attack a US federal agency and install a cryptocurrency miner in its systems. That’s a good reason to explain what Log4Shell actually is, why it’s too early to write it off, and how to protect your infrastructure.

What is the Apache Log4j library?

Because the Java SDK did not initially support logging, developers had to write their own solutions, and by the time the official Java Logging API appeared, there were already quite a few of them. One is Apache Log4j, a popular open-source Java library in development since 2001. It’s by no means the only logging solution in Java, but certainly one of the most popular. Many alternative solutions are essentially offshoots of Log4j that appeared at different stages of the library’s development.

What is the Log4Shell vulnerability?

The Log4j library allows to log all system events automatically. It uses a standard set of interfaces for accessing Java Naming and Directory Interface (JNDI) data. In November 2021, it turned out that during logging it’s able to run JNDI commands passed to it by an event, for example, in the Header field of a request, in a chat message, or in the description of a 404 error on a web page.

The vulnerability allows cybercriminals, at least theoretically, to do whatever they like on the victim’s system (if no additional security measures kick in). In practice, most often attackers used Log4Shell to install illegal miners and carry out ransomware attacks. But there have been more exotic uses for it too, including targeted attacks, spreading the Mirai botnet, and even RickRolling — playing the (annoyingly addictive) “Never Gonna Give You Up” hit by 80s crooner Rick Astley.

Why is it so dangerous and still a threat?

Java is one of the main programming languages; it’s used for many backend systems — from small corporate servers to industrial automation systems and IoT devices. Most of these systems implement logging in one way or another. For years, the easiest way to do this was to use the Log4j library. When, in December 2021, it was reported to contain a vulnerability, experts declared it would be a huge problem for many years to come. Here’s why:

• Log4j is used in a vast array of Java applications. At the time of discovery, the vulnerability was present in more than 35,000 packages (artifacts) in Maven Central (the largest Java package repository), which represents 8% of their total number. According to experts, around 40% of networks worldwide were at risk from Log4Shell.
• Besides conventional computers and servers, Java is also used in industrial, medical, and other specialized equipment. That equipment, too, is known to make use of the Log4j library.
• End users of solutions with Log4j inside, if blissfully unaware that the software contains a vulnerability, may put off updating it.
• Developers of solutions that use the Log4j library could well have gone bust long ago, left the market, or otherwise pulled support for their programs. Even if end users wanted to update, that option might no longer be there, while switching to other software may not be so easy.
• Log4j is an open-source library, which means that programmers can copy, modify, and use it in their projects. Unfortunately, not all developers strictly adhere to licensing rules, and do not always indicate code authorship. So, in theory, the same vulnerability could be found in a third-party project where officially there’s no Log4j.
• Log4Shell was a zero-day vulnerability, meaning that cybercriminals exploited it before information about it was published. There’s evidence to suggest that attackers first tried it out at least nine days before it was made public.
• Among the affected programs were VMware products, in particular the popular virtual desktop infrastructure solution VMware Horizon. Many registered attacks penetrated the system through this very software.
• Program updates will have little effect in the event that intruders are already inside the system. By no means all attacks begin immediately after penetration, and it’s quite possible that many systems contain backdoors to this day.

Actual damage

In fairness, we should note that so far no catastrophic consequences of Log4Shell exploitation have been recorded — or, at least none that the general public has been made aware of. All the same, the vulnerability caused a major headache for developers and security experts, including ruined Christmas holidays for thousands of IT staff worldwide. Companies that are serious about security (both theirs and their clients’) have had to fork out considerable sums to locate the vulnerability in their systems and software, and eliminate it.

Below, we spotlight some of the most notable Log4Shell incidents known:

• On December 20, 2021, the Belgian Ministry of Defense confirmed an attack on its infrastructure using the vulnerability. Understandably, the details were not disclosed.
• On December 29, 2021, media reports said that a certain scientific institution in the United States had been attacked through Log4Shell. According to CrowdStrike, the APT group, Aquatic Panda, exploited an unpatched VMware Horizon. The suspicious activity was stopped in time, but the incident itself indicates that serious hacker groups have embraced the vulnerability.
• Also in December 2021, news broke about a Log4Shell exploitation on the servers of Minecraft: Java Edition, hosted not by the game publisher (Microsoft). The company confirmed the report and drew attention to the simplicity of the attack’s implementation: the cybercriminals transmitted malicious code in a regular in-game chat, which was enough to run it both on the server side and on the vulnerable client. This case is of interest less from the victims’ perspective and more in terms of the technical implementation: under certain conditions, an attack can be carried out simply through an internal chat. This is worrying, since chats now reach far beyond the world of gaming: for many companies, they are the preferred method of communicating with customers. In many fintech and other applications, this is how customer support is delivered.
• In June 2022, the US Cybersecurity and Infrastructure Security Agency (CISA) and the US Coast Guard Cyber Command (CGCYBER) issued an alert that the vulnerability was still being actively exploited. The advisory stated that cybercriminals used a loophole in the same VMware Horizon to penetrate the internal networks of two unnamed government agencies. On top of that, the attackers were said to have gained access to 130GB of sensitive data related to law enforcement.
• In November 2022, CISA, jointly with the FBI, issued another advisory about a Log4Shell attack on one more government agency. The attackers penetrated the system back in February, were detected in April, and remained active in June–July. During this period, they created an account with administrator privileges, changed a legitimate administrator’s password, and uploaded mining software to the server. The attack is believed to be the work of Iranian government-sponsored hackers, so some experts consider the mining to be just a smokescreen to hide their real motives.

How to protect your infrastructure

Any company can fall victim to Log4Shell, often simply due to not knowing about vulnerabilities in their systems and software. If you’re unsure whether your systems, tools, products, or services use the Log4j library, it makes sense to conduct a thorough security audit. Other than that, to stay safe, follow these tips from our experts.

• If Log4j features in your software you make, use the latest version of the library available on the project page.
• Read the official guide from Apache Logging Services and follow it where necessary.
• If Log4j is used in third-party products, update all vulnerable software.
• Use robust security solutions able to detect attempts to exploit vulnerabilities on servers and workstations.
• Monitor suspicious activity inside the corporate perimeter using EDR-class solutions or external services like managed detection and response. This will allow you to find and kill attacks in the early stages.