By now, you’ve probably heard about the critical zero-day vulnerability associated with a popular Java logging library called ‘log4j’ that is currently circulating in the wild. It has been categorized as vulnerability CVE-2021-44228 by MITRE, and has been given the highest possible severity score of a 10, which by definition makes it critical. The critical-level scoring is warranted, given the specific nature of this vulnerability, since an exploit crafted by a malicious actor could result in providing the attacker with full remote access and/or full privileged arbitrary remote code execution on affected systems.
ThreatBlockr’s central cloud-based SaaS platform (our GMC) is not impacted, as it does not make use of any Java components. Similarly, neither our legacy 1.0 ThreatBlockr software codebase nor our newer ThreatBlockr 2.0 software codebase is impacted, for the same reasons: we do not leverage Java on any of those systems or environments.
We did have one legacy backend licensing service that leveraged Java, but it does not make use of the ‘log4j’ library in question. Still, out of an abundance of caution, we have removed the unused log4j componentry on that specific legacy server.
This new zero-day associated with the ‘log4j’ java library is truly a critical vulnerability, and as such we strongly urge all customers to work with any and all of their third-party software suppliers to patch this vulnerability as soon as possible. In the meantime, ThreatBlockr customers who have properly deployed us in their networks can continue to work confidently and be at peace with their overall security posture. Any attacker leveraging this, or any other, zero-day attack vector using a known bad IP or domain as cataloged by our world class third-party intelligence partners will by definition be blocked, regardless of whether the attack was an inbound or outbound vector. And as you know, our third party threat intelligence is kept up-to-date in real-time across our entire customer base.
As always, for best coverage, we strongly recommend that our customers double-check their configuration to ensure that all of the out-of-the-box third-party threat intelligence in our platform is enabled for your created policies, with reasonably aggressive risk thresholds, with, as needed, false positive mitigation by way of our straightforward allowed list paradigms.