Log4J Vulnerability: Security Flaw and Solution

December 21, 2021


On December 9, 2021, a bug (CVE-2021-44228) impacting multiple versions of the Apache Log4j2 utility was disclosed publicly via the project’s GitHub repository. This vulnerability allows for unauthenticated remote code execution. The Log4j2 open source logging library is widely used in millions of applications across the globe, and attackers are already trying to leverage this vulnerability to gain access to enterprise systems across the internet.

Businesses across the globe are being impacted by this Log4j2 vulnerability, and it’ll cause huge issues if left unchecked. How can you protect your organization? Let’s find out.

What is Log4J?

Log4j is a logging framework for Java. Basically, those of us in development and security try to do good by logging things in applications. This helps developers with troubleshooting and helps security analysts find anomalies in those logs. Let’s say you’re developing some application and want to do good, but don’t really want to write all the code to generate those logs. That’s where Log4j comes into play. It’s a free open-source framework, which enables you to easily wrap it into your project and save a ton of time. 

Log4j is utilized by millions of third-party enterprise applications, cloud services, and manufacturers, including IoT devices. It’s literally on Mars. The Mars 2020 drone, Ingenuity, is logging data with Log4j. 

Unfortunately, a bug in this library allows for a vulnerability we’re calling Log4Shell. This allows an attacker to send a message to a vulnerable application, giving them the potential to execute malicious code. 

Factors like the vulnerability being so widespread, the fact that it’s difficult to pinpoint all the places it exists and the vulnerability being extremely easy to exploit makes this a perfect storm. All an attacker needs to do is simply prepare a malicious file, place it on a server they control and send some modified text to a field that’s being logged by the application server. 

Once the server logs this string, Log4j will retrieve and execute the malicious code from the attacker’s server. The potential for an attacker to then control the application and move elsewhere within an organization’s network is very real. 

Does this mean every software using Log4j is vulnerable to this exploit?

Not at all! The caveat is that your application would need to be logging the field that an attacker could send that modified text to. Think of it like this: Let's say you have a Java application which allows your users to log in with an account. Do you want to log all the attempted usernames? Probably! But that's also a great example of a field the attacker could use to submit that modified code instead of a username.

3 steps internal teams should take to test Log4J vulnerabilities

Assess systems and determine the location of Log4J

The first step any organization should make is to assess their systems and determine where the library containing Log4j is being used. This is more difficult than it sounds. Third-party vendors, open-source software, any application on your network can contain an extension that uses a Java library. Then having to drill down to whether that library is the vulnerable version of Log4J can be a lot of work. Keep in mind, one of the reasons Java is so widespread is that it works everywhere. This isn’t limited to standard Windows domains or a specific industry.

Perform a vulnerability scan

You can find those instances in a variety of ways. In a perfect world, we would all have software inventory tools perfectly configured to let us know all the software and dependencies being used across the organization. In reality, most of us will need to be a bit more scrappy. Vulnerability scans can be a great place to start. If you have endpoint tools installed like Tanium or osquery, those will be huge assets for both identifying and remediation. Scripting skills will also be extremely helpful here.

Apply the Log4J patch

After the difficult task of a security or dev team discovering and confirming that their systems are using Log4j, they’ll want to immediately patch where possible. In some cases, they may be at the mercy of the manufacturer to push out the patch. Organizations utilizing software or other solutions where the manufacturer hasn’t patched to the latest version can temporarily use an alternative or back up software. If that’s not a possibility, it’s essential to improve the monitoring and detection capabilities on the network.

Is the Apache patch enough?

Patching Log4j is more complicated than doing a single sweep through your network and applying a patch. Since Log4j is used as an open-source logging plugin for thousands if not millions of applications, it will take a while for organizations to even figure out what applications within their network are using it.

"Everyone should assume compromise"

Everyone should assume compromise if they have any applications that use Java as part of their environment. Monitoring network traffic is now extra critical for catching any anomalous network activity.

Second and third vulnerabilities to consider

Since the initial vulnerability was reported, second and third additional security flaws have been discovered. These additional vulnerabilities can trigger DDoS attacks on a network. 

Apache is doing its best to keep up with the newly-discovered vulnerabilities by releasing new versions with patches that address the issues. The most current version was just released, Log4j 2.17.0, but companies should expect more to come in the near future.

Check for updates from Apache and, when patching, update to the most recent version.

While major corporations are understandably putting all their focus and manpower towards patching and remediating the most critical systems right now, another concern is home networks. Think about your home routers and all those cool IoT smart-home devices that are not patched or updated as often. These are some of the secondary implications everyone needs to keep in mind when they consider how this might affect them.


We foresee the community talking about this vulnerability for a long time as criminals develop new exploits to leverage the Log4j vulnerability. Enterprises will need to invest heavily in their incident response and security analytics if they intend to avoid becoming compromised.

As more and more information is released, this vulnerability will evolve. We want to help you be prepared for whatever form it takes.

Next steps

This course covers a Q&A session discussing the Log4j vulnerability, known as Log4Shell. We’ll cover what it is, why it’s such a critical and widespread vulnerability that can exist in a multitude of systems and how to identify if you’ve been affected.