Please note that out of respect for your email volume, we will provide updates via our Knowledge Bank until this issue is resolved. Please check that location regularly for the latest information. We will only send email if urgent action is required on your part or if we have a major update.
On Friday December 10, 2021 news of active exploitation of a previously unknown zero day vulnerability (CVE-2021-44228) in a common component of java-based software, referred to as log4j, became widely known.
This package is an integral component in many platforms and across both business / on premises and cloud delivered software.
We have reviewed the available information and believe that by virtue of our general approach of minimising Internet exposed services and rapid response to installation of security patches the direct impact on systems hosted by us or maintained by us for clients is minimal. However, this is a rapidly evolving situation, and we wish to reassure clients that we continue to take the threat very seriously and will be implementing mitigations or fixes as they become available.
The extent to which this software package is integrated into the world’s technologies and platforms is still being discovered, making response a fluid activity for any security program.
This rest of this article provides details of Your IT Departments response to the Log4Shell vulnerability as well as an FAQ for customers to assess their potential exposure.
The Vulnerability
The log4j vulnerability is potentially the most impactful critical vulnerability that we have seen this year.
This indicates an attack attempt to exploit a Remote Code Execution Vulnerability in Apache Log4j. The vulnerability is due to insufficient sanitising of user supplied inputs in the application. A remote attacker may be able to exploit this to execute arbitrary code within the context of the application.
Exploitation of the vulnerability requires a single HTTP request containing malicious input from anywhere in the world, to an internet-facing server that is running a vulnerable instance of log4j. The result is a full system compromise and the exploit requires no authentication. This is as bad as it gets, especially given how widely this common software component is deployed.
Our Response
We are working closely with our Partners and Vendors to identify any risks to our clients. We are contacting individual clients with any identified issues. Through work over the weekend and the early part of this week we have been able to identify a very limited number of affected third-party technologies that we utilise. Where these have been identified remedial actions have been implemented.
This situation is evolving and we fully expect news of additional affected technologies to become known over the coming days and weeks ahead.
Your IT Department remains in a state of active response and readiness in order to:
Recheck check our initial assessments
Monitor for additional intelligence emerging about the scope of technologies impacted
Reassess for exposure as necessary
Leverage commercial and open source threat intelligence to monitor for changes in attack patterns and adapt response activities if/as necessary
Continue to engage with vendors to assure our Third-Party risk is understood and appropriately mitigated
Sources of Attack
It’s now widely reported that TOR exit nodes are generating a lion’s share of the scanning activity and Your IT Departments monitoring confirms this. We have implemented geo-locking of affected systems to block all inbound connections from TOR exit nodes.
Looking Ahead
The days and weeks ahead will be challenging as exploits mature and evolve, more becomes known about common technologies that have this vulnerability embedded within them, and more third-party disclosures come out regarding technology susceptibility.
Coin miners and DDoS botnets are just the start of what we will see in the days ahead. It is reasonable to predict that mass exploitation will occur in the near future. It is also likely that ransomware affiliate groups will include this exploit in their playbooks and ransomware threat actors will embed exploitation of this vulnerability into their malware kits.
Update 15/12/21
Following advice from our partners at WatchGuard we have configured all WatchGuard appliances to the latest IPS signature sets.
Are WatchGuard products impacted?
The WatchGuard engineering team is doing a comprehensive review of all products:
- Firebox, WatchGuard System Manager, and Dimension – Not affected
- WatchGuard EPDR and Panda AD360 – Not affected
Some product components in WatchGuard Cloud were running a vulnerable version of log4j2, but use a version of JVM that is not vulnerable to the common and trivial LDAP attack vector. These components have been updated out of an abundance of caution.
- AuthPoint – Updated
- Threat Detection and Response – Updated
- Wi-Fi Cloud – Updated
WatchGuard are continuing to investigate internally for any additional potential impact. Please check Secplicity and the KB article for latest updates.
Update 16/12/21
Further updates from Partners on specific services:
Bluedog:
We are not impacted, the log services we are using are not exposed to the public world. All elastic services used have been patched or mitigated to avoid exploitation.
CyberSmart:
We can confirm that we do not use Log4j in our products
Heimdal Security:
“Heimdal™ Security has acknowledged the existence and inherent criticality associated with the use of the log4j logging framework. Consequentially, we would reassure our customers and business customers who are using Heimdal™ web-based services that the log4j vulnerability does not impact the quality of our service nor the data integrity, or the client’s privacy.
Keeper Security:
Keeper Response to CVE-2021-44228
Based on a recent public disclosure, our security team has researched the vulnerability regarding an open-source Java logging library developed by the Apache Foundation called Log4j (vulnerability number CVE-2021-44228).
Keeper Enterprise software is not subject to a cyberattack vulnerability, based on the affected library. However, as a precaution and to maintain the most modern and secure libraries, we have updated all Keeper infrastructure with the latest Log4j version. We have published a security update to Keeper SSO Connect On-Prem Version 16.0.2 and Keeper Automator Version 1.0.5.
KnowBe4:
KnowBe4 is aware of the recent log4j vulnerability (CVE-2021-44228) and has been investigating this issue in-depth. We can confirm that no KnowBe4 products are affected by this at this time and therefore no actions are required to be taken by our customers.
https://blog.knowbe4.com/log4j-vulnerability-knowbe4-not-affected
FAQ
Q: Is there anything we need to do?
A: Some third-party systems used by your company may be affected, please monitor your email for Vendor advice and provide this to Your IT Department as soon as you have it.
Q: Are we still vulnerable?
A: While systems may still be vulnerable, the ability for attackers to exploit them is severely limited in this circumstance. We are actively monitoring for attack attempts and will continue to implement workarounds and patches as they become available.
Helpful Resources
- Log4shell software flaw threatens millions of servers as hackers scramble to exploit it – ABC News
- Critical RCE Vulnerability: log4j – CVE-2021-44228 (huntress.com)
- CVE – CVE-2021-44228 (mitre.org)
- “Log4Shell” Java vulnerability – how to safeguard your servers – Naked Security (sophos.com)
- Inside the Log4j2 vulnerability (CVE-2021-44228) (cloudflare.com)
- CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell) – Blog | Tenable®
- Apache Log4j vulnerability actively exploited, impacting millions of Java-based apps – ARN (arnnet.com.au)