On December 9th, a Critical 0 Day vulnerability (CVE-2021-44228) was disclosed by Apache regarding their Log4j utility. This document provides an overview of our investigation and other mitigatory efforts.

Description

A zero-day vulnerability has been identified in Apache Log4j. Apache is open source software and Log4j is a Java-based logging audit framework within Apache. The vulnerability has been categorized as “Critical” with a CVSS score of 10 (the highest score possible) and all versions up to 2.15.0 are vulnerable. Many application frameworks in the Java ecosystem use this logging framework by default and when using this vulnerable version, any incoming data that gets logged can lead to an RCE (remote code execution).

Below is a summary and a link to The National Vulnerability Database:

CVE-2021-44228: The vulnerability is triggered by sending a specific string to the Log4j software, which means it is simple to exploit and the broad use of the framework means there are multiple attack vectors. There are examples where connecting to an SSID containing the exploit string sends a log to the OS vendor server and triggers the vulnerability in their network.
CVE-2021-45046: It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data.

It is important to quickly assess the impact and risk both internally and within your third-party population. Take action now and follow these steps to assess the potential impact to systems and remediate accordingly.

Step 1: Determine if you are at risk.

If you or a third party are running any version of Apache Log4j up to and including 2.15.0, the system is vulnerable.

To test if your applications are vulnerable to CVE-2021-44228, run the “Log4Shell” Vulnerability Tester provided by Infraguard by clicking here.
To assess whether your Third Parties are vulnerable, customers can access the “Log4j Vulnerability Response Survey” in the Whistic platform under our Questionnaire Standards Library by clicking here.
If you’d like to download the questionnaire as a spreadsheet, click here.

Step 2: Immediately patch servers that have been impacted.

Update Log4j to 2.16.0 using the version update provided by Apache by clicking here, after appropriate testing and validation.
Run all systems and services as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack.
Apply the Principle of Least Privilege to all systems and services.

This method is the only complete remediation.

Does this affect Whistic?

As a result of our investigation, we have determined that this vulnerability does not directly affect Whistic. The Log4j library is a commonplace library in the Java programming language, and while a significant portion of Whistic is built on Java, the Log4j utility is not used within the application. Whistic uses ElasticSearch, Logstash, and FeatureHub, all of which use Log4j by default; as soon as we were made aware of this fact, we effectively removed these services from the Whistic environment until a patch was made available.

On Monday, December 13th, upon confirming an update to version 2.15 was available for each of the above-mentioned services, we installed and tested the update prior to restoring these services.

Update: On Wednesday, December 15th, Whistic was notified of a vulnerability associated with Log4j v.2.15. Upon discovering this vulnerability, we also were made aware that v.2.16 was released, which would mitigate this issue. This patch was immediately applied and tested for efficacy on each of the above-mentioned services.