Christos Betsios, Cyber Operations Officer at Obrela Security Industries outlines the technical details behind the Apache Log4j vulnerability.

Apache’s Log4j has been the target of one of the most significant cyber incidents in recent memory. If businesses are still unaware of the vulnerability, then the chances are that it is already too late. Put simply, Log4j is software that contains vulnerabilities within specific versions. Primarily, the software was used as a logging framework, meaning it allows developers to monitor or log digital events on a server.

Internal teams can subsequently review those logs for typical operation or abnormal behaviour. Software should safeguard against data coming from untrusted users online. Still, the flaw allowed unauthorised users to gain an initial foothold which granted them access to sensitive data and even manipulated the server’s options. If left unpatched, attackers could use this vulnerability to take over server applications, connected devices and infiltrate enterprise networks. There are already reports of malware, ransomware and other automated threats actively exploiting this vulnerability. Practically every facet of enterprise is impacted, from datasets to AI.

A Technical Explanation of the Log4j vulnerability

Due to improper input validation, the Log4j library exists in an arbitrary server an untrusted user could gain access to. Since developers assumed that the data returned into the logs was counted as a regular text, no further input validation was conducted. This allowed untrusted user inputs to make their way into the logs. A malicious user would include the Java Naming and Directory Interface (JNDI) lookup, pointing to a managed setup server in a URL parameter.

The local gene algorithm communicates with the attacker’s Lightweight Directory Access Protocol (LDAP) server in the directory formation included values for the example factor in the Java codebase. These two values include the Java class from the attacker, which is then loaded into the memory and executed by Log4j, which completes the code execution part. This way, the attackers can run their malicious commands on the remote server, using the vulnerable version of the software.

When creating a new piece of software, it is always crucial to perform threat modelling before development, identify potential gaps, and predict mechanisms such as input validation. In conclusion, this is a critical task that is rarely neglected, so we don’t encounter situations like the one we are currently facing.

Who Could Have Been Behind the Log4j Attack?

Opportunistic cybercriminals scanned businesses for shell vulnerabilities. Initially, the flaw was responsibly disclosed to the Apache foundation by researchers as early as the 24th of November. Although, it seems that it was already exploited before the vulnerability became widely known. Researchers have linked high-profile actors, from Iran, North Korea, and Turkey to the initial vulnerability exploitation because the flaw is reasonably simple to exploit.

However, lately, we have seen various groups of cyber criminals working together, collaborating to leverage the vulnerability. This results in initial access and lateral movement on VMware because VMware products also leverage Log4j. Due to the ubiquity of Apache’s software and the relative ease of the vulnerability’s exploitation, practically every bad actor from script kiddies to nation state-funded cybergangs have taken advantage of this vulnerability to get the initial foothold within an organisation to exploit it for monetary gain.

Was the Log4j Vulnerability the Victim of Irresponsible Disclosure?

While responsible disclosure is one of the key concepts of cybersecurity, one could argue that the news coverage surrounding the Log4j incident led to more cybercriminals taking advantage of it. This is because it was a relatively simple vulnerability and the constant reporting brought it to the forefront of media attention. If businesses weren’t quick enough to patch the vulnerability, the media coverage alerted the cybercriminals, giving them an advantage.

This is a recurring issue. Following the publication of a proof of concept regarding how to exploit this vulnerability, Apache released a patch. However, the vulnerability was already in the public domain. Actors around the globe started to scan across all networks for exposed systems to try to exploit this vulnerability. So, as soon as the media shared this story and more technical details became available, the vulnerability became easier to exploit, with malicious actors taking advantage of this. Even responsible disclosure has risks.

What could you do to mitigate the Log4j vulnerability?

Currently, almost all organisations struggle to identify and secure their vulnerable assets. Many organisations are struggling to identify vulnerable systems within their environment. Businesses often don’t have the proper software or asset management lists in place, letting them know about the vulnerability, viruses and general threatscape. Suppose you do not have the right mechanisms in place. In that case, it is imperative that you partner with a managed service provider that can provide the proper detection mechanisms to identify a potential exploitation attempt. Businesses must also identify other software that could be affected by the Apache libraries and apply any patches released by third parties.

For organisations using different versions of Log4j or software that includes the library, they must implement a library review of potentially impacted applications for odd behaviour. Cybercriminals are opportunists; they will target any open opportunity. Businesses must assume a breach mentality and review the logs for impacted applications or any unusual activity. If unusual activity is identified, it is advised to seek the guidance of early response experts who can perform an effective containment, eradication, and recovery. Organisations must stay one step ahead of the cybercriminals and update all their software to the most secure version or risk falling victim to a cyberattack.

What to be aware of Going Forward

If you don’t have the finances to support an internal cybersecurity team or have misplaced your crystal ball, predicting and preventing a vulnerability such as this can be almost impossible. We recommend focusing on vulnerabilities that persist because of human errors such as habit, workflow, or company culture. Adopting a Zero Trust model is the best way to prevent an incident like Log4j before it occurs. Due to remote working, organisations will continue to heavily rely on VPNs and SaaS, which means that attackers will try to exploit those and prey on the different organisations.

In 2022, we expect all the above to lead to more supply chain attacks. All it requires to bring a company or country to its knees is a simple click on a link containing a phishing email received by an employee of a software company. Then the attackers can access the company’s environment and start moving around until they get on the right repository to deploy that piece of malware. Finally, given that critical infrastructure relies on OT, its adoption is widely expanding, which will likely bring more OT vulnerabilities to the forefront in 2022. Considering the impact of supply chain attacks in 2021 this attack vector will be one of the main targets for attackers since they frequently target critical infrastructure, especially for nation-state deputies.