The vulnerability found in the Log4j logging system should be old news for you at this point. However, what your company does about it is still worthy of your attention.
What Is It?
Log4j is a Java language library for logging events within an application. These logs facilitate troubleshooting when something goes wrong and provides visibility into the performance of applications. This library has been around for years and is favored by many, many development teams.
One of its features is that Log4j resolves variables within log messages. The bad actors force an application to log a message that contains a variable that in turn points to a malware web server that’s outside your organization. Log4j’s variable resolution mechanism then causes it to download the malware. You’re not protected because outbound web connection requests are typically allowed from any system within the enterprise. Many applications require access to the global internet for a variety of purposes, making it difficult to use outbound firewall rules.
What’s affected?
A lot of software has included Log4j. In some cases, software developers may not be aware that Log4j has been included by some other library they’ve used in their software. Candidates include healthcare, building control systems, any applications that provide a web interface, and network management, just to name a few. The problem is that applications that use Log4j typically run with elevated privileges, so malware that’s executed can do anything. Then, once in that system, it’s relatively easy to leave back door exploits that could be activated much later or to migrate to other systems.
It’s going to be tough to track down all the applications and verify that they don’t contain a vulnerability. You can’t manage things you don’t know exist. Ideally, you’ve been identifying all applications used by your organization so you can monitor and manage them. If not, this is a good time to start.
What Are Attackers Doing?
The original set of attackers were installing crypto-mining applications or botnet clients, which only disrupt operations because they steal CPU time. More recent attacks are expected to implement ransomware that encrypts data and holds it hostage. Organizations that have significant intellectual property or personally identifying information can expect data theft. This includes losing customer lists, product plans, chemical and pharmaceutical formulations, proposal documents, and pricing information.
What Should Your Organization Do?
CISA (see External References below) includes a list of actions that organizations should take. It’s very likely that you’ll have a mix of the above actions to perform, depending on each application, how it’s deployed, and how it’s used in your environment. The fastest step is to configure Log4j to not perform lookups. In some cases, you can remove the logging mechanism from existing software. Finally, install patches to software that your organization uses. Note that the 2.15.0 release on Dec 10th has already been superseded by 2.16.0. Have your team recheck CISA and vendor guidance frequently as the situation is far from over.
For some applications you can configure access lists that prevent external access or only allow access to specific address ranges for vendors. However, you’ll need to know a lot about an application’s network usage patterns to make this work, which prevents it from being recommended.
Various vendors are also providing guidance on what steps your organization can take. Splunk and Microsoft have good descriptions of the vulnerability and their recommendations for handling it (see External References).
For more information or if NetCraftsmen can help, please contact our Chief Technology Officer, John Cavanaugh directly at jcavanaugh@ncm2020.ainsleystaging.com.
External References
Cybersecurity & Infrastructure Security Agency (CISA) Log4j Vulnerability Guidance