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. Geographically, Barracuda Networks uncovered that 83 per cent of the attacks on their systems came from IP addresses in the United States, with 50 per cent being associated with Amazon Web Services and other large data centres. Threats analysed also came from Japan, Germany, Netherlands, and Russia.
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.