WhiteSource has made available an open source tool to detect vulnerable instances of Log4j logging software. The recently disclosed flaw allows cybercriminals to launch a remote code execution (RCE) attack via Java applications.
Rami Sass, WhiteSource CEO, said WhiteSource is also testing an extension to that command-line interface (CLI) tool that will enable IT teams to automatically remediate the Log4j vulnerabilities identified as CVE-2021-44228 and CVE-2021-445046.
The WhiteSource tool is available on GitHub, and Sass said it scans projects to find vulnerable Log4j versions and then surfaces the actions required to remediate vulnerabilities whether they reside within the IT environment itself or via a dependency on an external application.
Given the severity of the Log4j vulnerabilities, most organizations are moving quickly to address the issue. The challenge they face is there may be many instances of Log4j that IT organizations are no longer tracking, for one reason or another. The WhiteSource tool is designed to reduce the time and effort required to discover every instance of Log4j that needs to be updated—or, at the very least, reconfigured—to remediate the vulnerabilities, said Sass.
WhiteSource estimates attackers are already launching millions of attempts to exploit the Log4j vulnerabilities because cybercriminals already realize the window of opportunity is already closing. Overall, Sass said the open source community is getting more adept at responding to newly discovered zero-day vulnerabilities. The Log4j vulnerability is only the latest in a series of vulnerabilities that have been discovered in recent years, he noted. Most enterprise IT organizations are either already well on their way to implementing security incident response platforms that speed up response times or they are planning to implement such a platform shortly, said Sass.
In the longer term, Sass said IT teams should also expect to see automation become more prevalent in remediating these types of vulnerabilities as security tool providers gain more insights into what’s actually running within an IT environment.
In the meantime, however, the level of disruption caused by the Log4j vulnerabilities has been significant. The open source community is trying to strike a balance between responsible disclosure of vulnerabilities and the need to encourage IT teams to remediate code as quickly as possible. In the meantime, IT teams should assume that some cybercriminals have probably known of these vulnerabilities for some time. It’s now a question of determining the degree to which they may have already been exploited.
Cybersecurity professionals clearly need to work more closely with application developers to better understand what open source components may exist within an application. In fact, that need is exactly why there is so much recent focus on software bills of materials (SBOMs) that, as part of a set of DevSecOps best practices, make it easier for organizations to assess their overall level of risk. Otherwise, the sheer number of vulnerabilities discovered will simply overwhelm developers as they attempt to strike a balance between adding new application features and prioritize vulnerability remediation all at once.
