Log4Shell Threat Far From Gone: Attackers Continue To Target Vulnerability

The quantity of cyber-attacks targeting the Log4Shell complex of vulnerabilities in Log4j still remains extremely high, according to new Threat Spotlight analysis from Barracuda Networks.

The Log4Shell vulnerabilities have now been around for more than two months, and Barracuda researchers observed that the volume of attacks attempting to exploit these vulnerabilities has remained relatively constant, with a few dips and spikes, over the past two months. It is predicted that this attack pattern will continue, given the popularity of the software, the exploitability of the vulnerability, and the payoff when a compromise happens.

Subscribe
Notify of
guest
1 Expert Comment
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Tim Mackey
Tim Mackey , Principal Security Strategist, Synopsys CyRC (Cybersecurity Research Center)
InfoSec Expert
March 4, 2022 10:50 am

It’s not surprising that attackers continue to attempt to exploit a high profile vulnerability like Log4Shell within months of its release. After all, the long-tail phenomena where older vulnerabilities remain in the wild for years is an unfortunate reality. That being said, it’s important to differentiate attempted attacks from successful exploits.

Any organisation that has yet to patch Log4Shell is unlikely to know that they have any usage of log4j within their systems. That lack of awareness is a partly a result of a lack of understanding of the dependencies powering applications where that lack of awareness is a risk to the business. In effect, the ability to manage a comprehensive patch management program depends upon an understanding of all software running in the business, and all components powering that software. It simply isn’t sufficient to rely on suppliers to proactively issues patches as they themselves might not be aware of the usage of a vulnerable library deep within their application, or the application might represent a legacy version that no longer receives security fixes.

Regardless, reliance upon supplier statements should be subject to a “trust but verify” model where the Software Bill of Materials (SBOM) created by the supplier is validated by Software Composition Analysis (SCA) tools during both procurement and with any updates. 

Last edited 8 months ago by Tim Mackey
1
0
Would love your thoughts, please comment.x
()
x