Log4J Vulnerability: Security Flaw and Solution

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 were impacted by this Log4j2 vulnerability, and it’ll cause huge issues if left unchecked. How can you protect your organization? Let’s find out.

Log4j 2 is a logging framework for Java. Those of us in development and security make an effor to log 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 create a log, but you 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, now in its second edition, is utilized by millions of third-party enterprise applications, cloud services, and manufacturers, including IoT devices. It’s literally been to Mars. The Mars 2020 drone, Ingenuity, is logging data with Log4j. 

Unfortunately, a bug in the Log4j 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. The vulnerability was both widespread and difficult to pinpoint. 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. Luckily, not all applications were exposed. Your application would need to be logging the field that an attacker could send that modified text to. 

If you think your systems might still be vulnerable to the Logj4 exploit, then you can take three steps right now to protect your organization. 

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.

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.

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.

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 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.

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 kept up with the newly-discovered vulnerabilities by releasing new versions with patches that address the issues. 

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.

This Log4j Vulnerability 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.