Executive Briefing: Log4j Vulnerability

Log4j is a big deal, and it should be taken seriously. In cybersecurity, we score vulnerabilities on values from 0 to 10, with 10 being the worst. Log4j is a 10 out of 10. Every published vulnerability receives a score, known as its Common Vulnerability Scoring System (CVSS) score. This vulnerability allows attackers to compromise a system on your network by sending a single line of code smaller than the size of a Tweet to a system using log4j.

The log4shell vulnerability was announced publicly on December 9, 2021. Log4j is a software package (sometimes called a library) – think of it like a module or plugin that software developers can use within applications they are developing to collect logs from applications and systems. Estimations have suggested that Log4j has been used in over 100 million instances worldwide, with Java as its software language. The list of vendors using log4j continues to grow and includes names such as Apple, CloudFlare, Amazon, Tesla, VMware, and others.

Here is one problem with log4j – it isn’t a standalone application like Windows 10, Microsoft Office, or Adobe. You cannot have your IT organization simply look at a software inventory system and tell you if it is installed anywhere. Because it is a component of other applications, it requires the developer to identify if log4j is in use, whether it is a homegrown application your organization wrote, or something purchased by an external party. Since log4j can be installed in anything from a security camera to an enterprise class application hosted in the cloud, it makes things challenging.

Even if your organization has patched all instances of log4j in applications you control, it does not mean vendors have provided updates. Also, legacy software that may be in your environment that no longer has support or custom-built applications where the developer has long left the organization could also use log4j.

Apache, the vendor that develops log4j, has released patches to mitigate the risk. When your IT staff finds log4j, they may be able to install upgrades to remove this critical vulnerability. Unfortunately, though, the new patches have introduced other vulnerabilities, some also critical, but none as bad as the original. The reason I said IT may be able to install patches is because some applications cannot be patched and require IT to come up with another mitigation strategy.

What makes this vulnerability particularly bad? Because log4j is usually embedded in applications that are running on servers, that means attackers are targeting servers in your environment. Once an attacker sends a single line of code no bigger than a Tweet to a vulnerable log4j instance, it can force the application to run the commands the attacker sends to it, like telling the server to connect to a system owned by the attacker and download additional hacking tools or begin infecting the network with ransomware. Because applications generally have administrative or elevated privileges to run, it gives the attacker the same level of access that the log4j service has. This means an attacker could install and execute malicious software on the server and then move to other systems in your network.

There are several free and commercial products that will help your IT team discover log4j in your environment. It will require them to install these tools and begin looking for network traffic associated with log4j running and also scanning systems to see if they have files associated with log4j on them. If your team already has vulnerability scanning software from one of the major vendors, they should already have what they need to look for log4j in the environment.

Because log4j could be on systems that your IT team is not aware of, I recommend taking a risk-based approach to this remediation. It’s always best to start with any system that is connected to the public Internet, as attackers will often find these first. Then, once those are mitigated, start with systems that are your biggest risk, such as those that contain sensitive data or are critical to operating your business.

Earlier in this post, it was mentioned that this isn’t necessarily something that can be fixed by applying a simple patch. Where patching is not an option, your IT team or MSP should come up with another strategy to mitigate the threat. This may be disabling the log4j service, using a cyber defense tool such as a Web Application Firewall (WAF), Endpoint Detection and Response (EDR) tool, or an Intrusion Prevention System (IPS) to detect and block attempts to exploit the log4j vulnerability. You can ask your IT department about what they have done to detect and block these attacks.