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[1]
in the hope of finding unpatched or incompletely patched
targets.
As human error still accounts for 95% of all security breaches[2], 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[3], the level of stress
only intensified. Yet, a 2015 NASA study[4]
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[5]
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.
3 — The odds of missing at least
one instance of Log4J are high: All version of Log4J from
the September 2013 V2.0-beta9 onwards carry those vulnerabilities.
Yet, as all Java files, Log4J can nested a few layers deep into
other files, and can easily be missed when frenetically applying
patches, and, to make matters worse, Log4J is extremely popular,
with a reported 80% of Java affected packages[6] that cannot be updated
directly and require coordination between different project teams
to effectively patch.
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[7] 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[8] 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[9].
References
- ^
cyber-attackers are likely to continue
trying to exploit it (www.techtarget.com) - ^
for 95%
of all security breaches
(thehackernews.com) - ^
growing
list of affected vendors (gist.github.com) - ^
2015
NASA study (human-factors.arc.nasa.gov) - ^
distinct
patches (logging.apache.org) - ^
80% of
Java affected packages
(www.darkreading.com) - ^
Scanners’ Log4J blind spots
(thenewstack.io) - ^
running
comprehensive continuous security validation
(cymulate.com) - ^
cymulate.com
(cymulate.com)
Read more https://thehackernews.com/2022/01/how-can-you-leave-log4j-in-2021.html