If you find yourself baffled by the influx of events and newly discovered vulnerabilities affecting the popular Apache Log4j Java logging library, this post is for you. This post aims to survey the entire flow of events since the first discovery of CVE-2021-44228, AKA Log4Shell, to the present date, explain the important aspects of each related vulnerability, as well as provide practical remediation and mitigation advice.
By now, we’re all likely tired of talking about Log4j and nodding our heads over Zoom when we all discuss the ramifications of exploitation of this small, but very pervasive and powerful vulnerability. At the risk of adding another layer of complexity to the information we have learned about Log4j, I think we are remiss not to mention IT-OT (Information Technology-Operational Technology) convergence and how it could be an enabler for Log4j to impact our critical infrastructure.
Most enterprises, as well as small organizations globally are now painfully familiar with the Log4j2 vulnerability (CVE-2021-44228). It has taken over the lives of all cybersecurity professionals and it appears it is here to stay for a while. Most enterprises are scrambling for solutions, applying patches if they can find the vulnerability, and trying to implement mitigation strategies. But unfortunately what security teams are doing to tackle the Log4j beast is not always enough.
It’s not just about the big name companies who are vulnerable to the Apache Log4j2 vulnerability (CVE-2021-44228). Tech small businesses – which offer customers digital products but which often have tight budgets and understaffed security teams – are an important story when it comes to the implications for Log4j exploits. Research now finds that almost all environments have vulnerable Log4j libraries.
The popularity of the Log4j library, coupled with the ease of exploitability and severe potential impact, means Log4Shell’s blast radius is enormous – that’s old news by now. However, what’s being revealed these last few days is not just how popular it is, but how deeply rooted it is in the software we use – and this depth is creating some unique challenges in detecting it.
Just like you’d find all the ingredients on a package of food, a software bill of materials is a list of all the components contained in a software product. Vendors typically create these bills to describe what the components are. In addition, a Software Bill of Materials also includes information about these components’ dependencies and their hierarchical relationships.
Given the holiday season, I suppose it’s timely to label the recent Log4j vulnerability as the “vulnerability gift that just keeps on giving.” A quick scan of the headlines is all one must do to understand my sarcasm: Cyberscoop reports that The US Cybersecurity and Infrastructure Security Agency (CISA) warns that the Log4j vulnerability will likely affect hundreds of millions of devices and that the vuln “is one of the most serious…if not the most serious” seen by t
