With the last month of 2021 dominated by the log4J vulnerabilities discovery, publication, and patches popping up in rapid succession, odds are you have patched your system against Log4J exploitation attempts. At least some systems, if not all. You might even have installed the latest patch – at the time of writing, that is 2.17.1, but, if the last rapid patching cycle persists, it might have changed by the time this is published.
In the meantime, defenders might have been working overtime to plug Log4J born security gaps, but so did cyber-attackers. Log4J’s well-deserved fame also alerted cyber-attackers to a potential entry pathway into their target. And, while log4J will hopefully vanish from the headlines, cyber-attackers are likely to continue trying to exploit it in the hope of finding unpatched or incompletely patched targets.
As human error still accounts for 95% of all security breaches, cyber-attackers actively rely on these human errors to exploit them and take advantage of a false sense of security derived, assuming that patches have been applied successfully.
The Log4J saga is a perfect storm to generate a high number of patching errors as it combines:
1 —Acute stress: Log4J was named the worse vulnerability in decades and qualified by Cloudflare as “so bad we’re going to try and roll out at least some protection for all @Cloudflare customers by default, even free customers who do not have our WAF.”
The pressure to patch before any vulnerability could be exploited by cyber-attacker was intense. As the crisis worsened with a combination of new patch publication and a growing list of affected vendors, the level of stress only intensified. Yet, a 2015 NASA study demonstrates that “Situational stress can adversely affect the cognition and skilled performance of pilots, as well as experts in other domains.”
2 — Frantic patching cycles: Between December 6 and December 27, four distinct patches were published, each consisting of a new version of the Log4J, so each required upgrading it to a new version, and do so without breaking anything. So many updates in such a short time negatively impact the level of trust in the value of the patch and i increase the odds of patching errors or oversight.
This is welcome news for cyber-attackers who are likely to continue weaponizing Log4J vulnerabilities for months and years to come.
The best defense against current and future Log4J related exploits is to validate that your patching is comprehensive and adequately applied. Running Log4J updated vulnerability scanners is a good starting point but, unfortunately, no single scanner can spot all the indirect or transitive Log4J dependencies, especially when it gets pulled in as a transitive dependency that lacks an explicit definition of Log4J.
Scanners’ Log4J blind spots mean that validating the efficiency of the patching process through offensive testing is a non-optional necessity. This methodology determines if the rules you have set up to deflect Log4J malformed requests are effective or if more tuning is required. A log4J execution method could be used by red teamers out-of-the-box.
Using these offensive testing techniques, some clients effectively detected supply chain induced Log4J vulnerabilities before the supplier had published a patch.
The advantage of running comprehensive continuous security validation is that the resulting tightening of first- and third-party security controls do limit exposure to unknown unknowns as it exposes weak spots and provides actionable recommendations to close them.
To avoid the risks stemming from the deadly combination of acute stress, frantic patching cycle and hidden instances, whether for Log4J or the next big one – and even small one – it pays to tun continuous validation that not only scan for vulnerabilities but also safely tests if production-safe payload were effectively detected and stopped, and thoroughly assesses the effectiveness of your security policies and controls pre- and post-patching.
For more information, visit cymulate.com.