Understanding the Log4j Vulnerability

On December 9th, 2021, a Log4j vulnerability was published and later to be designated CVE-2021-44228, and if exploited, it could allow hackers to remotely execute code on affected systems, an action called remote command execution.

How is it exploited?

Exploit code, nicknamed Log4Shell, was quickly made available to the public by malicious parties, and according to U.S. Cybersecurity & Infrastructure Security Agency (CISA), hundreds of thousands – if not millions – of attacks have been conducted since then to exploit that vulnerability. According to cybersecurity specialists, it could potentially be used to distribute malware and ransomware, steal sensitive data such as credit card info, social security, and healthcare data, as well as other malicious cyberattacks.

In recent history, the Smartwatch has become commonplace and, from a consumer’s point of view, it’s an extension of their phones. Peeling back the technology, the smartwatch is an IoT device; it collects data about the wearer such as Heart Rate, GPS location, Number of Steps, etc. and all that data gets sent to the phone and eventually the cloud, where the user can access data about their health over the course of a day. Involved in that simple watch are a local wireless connection from the watch to the phone, then a larger wireless connection from the phone to the internet, and a cloud provider where the data ultimately resides and is viewed.

But what is Log4j?

Apache Log4j is a free, open-source Java-based logging utility, distributed under the Apache Software License. It is essentially a Java library used to record events and communicate diagnostic messages to system administrators and users. An example is the infamous “Error 404” from a web server after clicking on a broken web link, so this is a key component of any software framework using open source-based software.

What products are impacted?

Any system exposed to the internet running Apache Log4 versions 2.0 to 2.14.1 software is potentially at risk. Logging is a basic, fundamental feature and Log4j is used by many enterprises and open-source software, including web servers, email services, and cloud-based services Apple iCloud or Amazon Web Services (AWS), the latter being used to host hundreds of thousands of other cloud services from third-party vendors, making the surface of attack almost infinite. That gives an idea of how critical the situation is.

Even our management and monitoring solution ISEC7 SPHERE leveraged Log4j, but was not affected by the vulnerability. Nevertheless, we took the preventive measure of completely removing Log4j from our solution and replacing it with Logback.

An ever-growing list of affected vendors was made available by CISA on the GitHub repository.

What should I do now?

1. If you haven’t already, make an inventory of all the organizations in-house and third-party on-premises software, as well as cloud-based services/SaaS used, identify the ones that are potentially affected, in most cases the corresponding vendor will have already sent an email notification for awareness.
2. Patch any software for which a patch is available from the vendor; if no patch is available yet, a workaround will be provided to mitigate the risks in the meantime. If not, then we recommend you isolate the affected system from the internet until it is patched.
3. For cloud-based services/SaaS, contact your vendor and/or check their website to ensure they are currently running safely.
4. And work with your vendor on resolutions for workaround and updated code build to address the vulnerability.

Looking back at this experience, even the most innocuous library can be an attack vector. How do you manage an environment with hundreds of servers and thousands of users and devices? What’s the best practice to ensure that your ecosystem is secured against preventable attacks and has a response to an potential vulnerability (via CVE) or an attack. Please feel free to contact the team at ISEC7 and we can help you take steps to secure your infrastructure.