Posts within the Executive Briefing Insight Category are developed by Natsar to help non-technical decision-makers understand cybersecurity topics and their impacts to an organization’s business and mission.
At Natsar we are dedicated to helping executives and decision-makers understand cybersecurity. This post will provide a non-technical overview of the Log4j (also known as log4shell) vulnerability and provide a resource for executives to use when talking with their IT teams or Managed Service Providers (MSPs).
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 is assigned 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. Log4j uses Java as its software language and is estimated to be used in over 100 million instances worldwide. The list of vendors using log4j continues to grow and includes names such as Apple, CloudFlare, Amazon, Tesla, VMware, and others.
Here is one of the problems 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 have support or custom built applications where the developer has long left the organization could also be using log4j.
Apache, the vendor that develops log4j, has released patches to mitigate the risk. When your IT staff does find 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 begin moving to other systems in your network.
There are a number of 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 begin looking 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. In cases where patching is not an option, your IT team or MSP should be coming 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.
- Who is leading our response to log4J?
- What attempts have been made to locate log4j in our environment? What were the results of those attempts?
- Have we determined if all systems connected to the Internet have been remediated from log4j?
- Are we contacting vendors and suppliers to determine what products in our environment are vulnerable?
- Have we seen any attempted or successful attacks using the log4j vulnerability?
- Have we setup systems to detect and block attempts to exploit log4shell?
- What is our status with patching the log4shell vulnerability? Do we have a regular cadence of updates and a burn-down list of hosts?
- Have we patched all known systems using log4j? If not, why not?
- How is IT working with other parts of the organization that may run their own IT systems and applications?
If your organization has an Incident Response (IR) plan, now would be a good time to review it and see if it is up to date and being used to respond to this vulnerability. If your organization does not have a formal incident response plan, now would be an excellent time to create one. Whether your plan uses in-house resources such as a dedicated IR team, or it is completely outsourced to another provider, all organizations need to have this documented as part of their business continuity and disaster recovery plans.
Experts agree, log4shell is going to be with us for years to come and may very well be one of the most problematic issues we have faced in the history of the Internet.
At Natsar, we are continuously improving our products and services. Please let us know how we did and if this information and resources were helpful to you.