Update on Log4Shell Vulnerability

14 December 2021

The Plutora Engineering team are continuing to monitor the situation regarding the Log4Shell vulnerability and have been working closely with vendors to ensure all systems are secure.

As per my previous statement (below), the core Plutora platform is not exposed as it is based on Microsoft technologies and does not utilize the log4J libraries for logging.

We have been working closely with Amazon Web Services (AWS) to ensure all services are secured. AWS notified the team of one service (Elastic Search/OpenSearch) that is exposed to the vulnerability. This service is not directly accessible to the public web, so it is not of concern. The team has since patched the service as per AWS guidance,

On 14 December at 8AM (PST) we were notified by Salesforce that the Tableau Server version that we host is exposed to the vulnerability. Tableau is working to supply a software patch. The Plutora DevOps team preempted this outcome and installed a Web Application Firewall (WAF) in front of our Tableau Servers by 13 December 9PM (PST). This WAF is configured to block Log4Shell attacks.

The team has reviewed logs and so far we have NOT identified any suspicious activity. Our infrastructure is constantly monitored by Trend Micro Deep Scan and other AWS Security services that have NOT detected any malicious activity.

This situation is continuing to evolve and the Plutora team will continue to provide updates as necessary.

13 December 2021

On December 9th 2021, Apache published a zero-day vulnerability (CVE-2021-44228) for Apache Log4j being referred to as “Log4Shell”. This vulnerability has been classified as “Critical” with a CVSS score of 10, allowing for Remote Code Execution with system-level privileges.

When exploited, this vulnerability allows an attacker to run arbitrary code on the device, giving full control over to the attacker. Any device exploited should be considered compromised, potentially along with any devices that trusted the compromised device.

Our Response

As soon as Plutora learned of this vulnerability, we promptly evaluated all cloud-hosted systems to determine what might be impacted and worked with all third parties.

Plutora’s Engineering teams have NOT identified any material exposures to the vulnerability, and are confident in the safe use of Plutora products. While we consider our initial response complete, we remain in a state of active monitoring and readiness to respond.

This situation is evolving and we fully expect news of additional affected technologies to become known over the coming days and weeks ahead. All technology professionals will need to monitor for the latest developments and continually reassess their exposures.

Our top priority was to complete an initial comprehensive assessment and response. This has been completed. The focus of those activities centered around the following:

• Assessing usage within Plutora products

• Inspecting infrastructure systems in our asset inventories

• Researching vulnerable third-party technologies

• Inventorying Plutora’s third-party vendors to engage them and understand their response

Other Mitigations

We also recommend customers check whether any other (non-Plutora) software they are running may be impacted and check-in with applicable vendors for available patches.

Customers unable to patch affected software should also consider the mitigation strategies outlined below.

• Deploy a WAF with rules specific to the exploitation observed around this vulnerability.

• In log4j versions from 2.10 to 2.14.1:

  • Set the system property log4j2.formatMsgNoLookups to true, or

  • Remove the JndiLookup class from the classpath. For example: zip -q -dlog4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Next Steps

The Plutora team will continue to provide updates as necessary.

Regards,

Simon Farrell

Chief Technology Officer