Last week, reports emerged about a "new" zero-day vulnerability found in an extremely popular Java library: Log4j.

This vulnerability was named as Log4Shell and tracked as CVE-2021-44228.

As people around the globe began to learn about it, the panic rapidly expanded. Attacks based on this vulnerability are growing rapidly, and security teams face a hard time dealing with an exploit deeply embedded in their system.

We'll explain the elements below. We're deliberately keeping this as understandable as possible to make this accessible to anyone who has some skin in the game; accessibility is our mantra:

• What everything is about with Log4j;

• What it means to you as a security and risk manager;

• Where Mindflow can bring some help.

Is Log4Shell serious business?

Log4Shell is a vulnerability in Log4j, an open-source Apache product developed in 2001. Log4j is a logging library commonly used by Java applications.

The Java Development Kit initially did not include logging APIs, so Java logging libraries (such as Log4j) quickly expanded across companies. Log4j is also used inside other frameworks, like Elasticsearch, Kafka, and Flink, on which many websites and services are based.

Being around for 20 years and answering developers' needs makes Log4j a popular library.

The Log4Shell vulnerability

Okay, let's figure out what's happening with the Log4Shell vulnerability. The Log4j library is used to keep records of all application activity (debugs, logs, or errors, for instance).

We often think of logging libraries as passives, which is usually true. However, some of them, like Log4j, embark on functions that interact with protocols. They can engage in processing before saving logs, such as executing commands to generate advanced event information to communicate it with other sources, like your internal directory services. As such, even though that wasn't intended in the first place, libraries like Log4j can create an unexpected attack surface.

According to this vulnerability, attackers only have to use a particular syntax in a string, which can be nested and combined to complicate detection. The attackers can trick the application by submitting a value that developers saved into the logs to request and execute their code. As such, they can execute arbitrary code. Then, as you know, they're free to wander into your systems: launch a malware attack, lateralize, and wait for the opportunity to deliver the payload. 

To sum up, this is what we call Remote Code Execution: the attacker can command the operation of another person's computing device or computer. This helps explain why the Log4j vulnerability has scored 10 out of 10 in CVSS (Common Vulnerability Scoring System), making it a "Critical" vulnerability.

Who's impacted?

Most of the other significant cyber-attacks involve one or a limited number of software programs. One particularity of Log4j, which makes the vulnerability unique, is that it is embedded in every Java-based product or web service. It isn't easy to remediate it manually.

Furthermore, many companies don't have a clear view of every program they use and the software components within each of those. Why? Open-source software can be incorporated wherever developers want, and they've done it heavily because Log4j was useful. Right now, when a vulnerability appears, exposed code can lie anywhere. 

From the news, we've learned that everything can be affected. A chat message in Minecraft, for instance, resulted in a server compromise. Many world-class companies publish posts to inform their customers that they've discovered and are working on vulnerabilities.

What should you do?

1. Find and patch vulnerable versions of Log4j libraries

The first and foremost thing to consider against this risk is to know which one of your assets is at stake. It sounds easy, but it doesn't work as efficiently. Many companies still don't know all their assets. With the multiplication of connected devices or even any internet-facing assets, your network attack surface grew exponentially as they increased.

Even companies that have already run assets mapping, especially those at risk, have to do it again, given the popularity of Log4j. Moreover, some apps could rely on it that you wouldn't even know, or you couldn't say precisely if one of your providers could be impacted by this exploit—a mess.

But let's stay focused on your company. Administrations worldwide advise us to "discover unknown instances of Log4j" and patch them, in addition to fixing the known suspects.

To that end, you could parse your file systems and hunt for specific signatures or hashes of Log4j (in its different versions) to understand which assets are at risk and build an inventory.

Once you have this inventory, you could triage it according to their sensibility and difficulty of patching. Some assets are naturally easier to patch because you can restart them anytime. Others, however, are crucial, and reboots cannot be done quickly besides potentially having unexpected impacts, such as blocking the whole application.

However, this isn't the end of the story. You could clear your system from vulnerabilities by patching every Log4j library you have and still be breached if your system had already been targeted. You could also induce a new vulnerability each time you deploy a new application with a vulnerable version of Log4j. Finally, the attacker may have already delivered the payload, creating another set of threats.

2. Indirect solution: mitigation

Correctly patching all the Log4Shell vulnerabilities will likely take months. You need to act while some are doing it.

To that end, you need to stay sharp and aware of the evolving threat. We've seen that attackers are gaining access to this Log4Shell vulnerability, increasingly using it and trying to develop variants.

This is where Threat Intelligence will play an essential role in the coming months. Uncovered attacks by defenders worldwide will provide us with precious information to increase our resilience: IPs, URLs, or even Indicators of Compromise found in previous episodes.

Threat intelligence databases have already begun to pour precious intel into the first attacks. This intel would be best implemented in your Firewall rules to block most basic attacks. Sure, it won't 100% protect you, but let's be clear about the fact that the most attacks you'll encounter will be replicates. By staying afoot of the threats and their variants, even in a reactionary stance, you can avoid many risks.

Where can Mindflow help?

Okay, think about what we've stated above. It relies on the communication between your different assets and your different tools. This is an orchestration matter, and we can help in doing it. There are two solutions we've identified that would help you in significant ways:

Configuration Management Database

Consider your Configuration Management Database (CMDB). It is hard to keep up-to-date without the proper tools, even with adequate ones. In an automated fashion, Mindflow, thanks to its integrations, can connect different tools you use, such as your Endpoint protection platform (EPP), Cloud security posture management (CSPM), or Cloud Workload Protection Platform (CWPP), to help you have an automated and most up-to-date CMDB. From there, checking for vulnerabilities across your assets is way easier.

Automated Threat Intelligence

As we said, the community lever will be crucial. Here, we've been working to integrate multiple threat intelligence providers in our platform, some of the most active and up-to-date. Some are the biggest community-based, relying on AI and feedback loops. Others are among the most significant security providers around. Their experts rely on this unique ability to work straight from the telemetry their customers' products and services produce.

Conclusion

Log4Shell's vulnerability is unique because of three factors. First, it's based on a widely used library. Second, because of that, it's challenging to patch every asset using it (it's already hard to know every asset you have, eh). Third, and lastly, it's easy to exploit.

These points above lead us to think, among many others in our field, that Log4Shell will stay with us for many months, maybe years to come.

You must act fast to prevent the attacks, beginning with a complete reassessment of your network attack surface. Here, use the power of automation and AI to map your assets at risk on the Internet.

Then comes the patching, which will be long and tedious to achieve the KRI lower acceptable bound. Between these two steps, there's the mitigation. This exploit will undoubtedly be increasingly used. Variants will emerge and have already done so. Here, as we said above, Threat Intelligence sharing is paramount. This is where collective defense matters the most. We will only succeed by harnessing our collective power against this threat.

In cyberspace, like IRL, everything is connected. One successful breach on a value chain can impact the other hand of it (SolarWinds, remember?). Nobody is isolated here. A critical vulnerability is a global concern.

Community actions, such as common TI platforms, intel sharing, and feedback, will help us in this mess. Tackle the Log4Shell challenge as a group instead of as an individual.