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

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

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

Here, we’ll explain the elements below. We’re deliberately keeping this as understandable as possible to make this accessible to anyone that 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?

First thing first, what is precisely Log4Shell?

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

Java Development Kit initially did not include logging APIs, so Java logging libraries (such as Log4j) quickly expanded across companies. More, Log4j is 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 widely popular library.

The Log4Shell vulnerability

Ok, let’s figure out what’s happening here with the Log4Shell vulnerability. Log4j library is used to keep records of all activity in your application (debugs, logs, or errors, for instance).

We think of logging libraries as passives, this is often true. Although some of them, like Log4j, embark functions that interact with protocols. They can engage 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 pretty much free to wander in your systems: launch a malware attack, lateralize and wait for the opportunity to deliver the payload. 

To sum this up, this is what we call a 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. One particularity of Log4j, which makes the vulnerability unique, 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 resulted in a server compromise, for instance. Many world-class companies publish posts to inform their customers that they’ve discovered vulnerabilities and are working on them.

What should you do?

• The obvious one: Find and patch vulnerable versions of Log4j libraries in your system

The first and foremost thing to consider against this risk is to know which one of your assets is at stake. Sounds easy, doesn’t work as easy. 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. More, 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 around the world are advising 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 in the function of their sensibility and difficulty of patching. Some assets are naturally easier to patch because you can restart them at any time. Others, on the opposite, are crucial, and reboots cannot be quickly done 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.

• Indirect solution: mitigation

Patching all the Log4Shell vulnerabilities will likely take months to be correctly done. You need to act while some are doing it.

To that end, you need to stay sharp, afoot of the evolving threat. We’ve seen that attackers are getting their hands on this Log4Shell vulnerability. They’re increasingly using it and trying to develop variants.

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

Threat Intelligence databases have already begun to pour precious intel of 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?

Ok, think about what we’ve stated above. It relies on the communication between your different assets, 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). 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, it’s way easier to check for vulnerabilities across your assets.

• 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 to exist. 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 produced by their customers’ products and services.

Conclusion

The Log4Shell 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 need to 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 a long and tedious job to achieve the KRI lower acceptable bound.

Between these two steps, there’s the mitigation. No doubt that this exploit will 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 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 alone.