Arctic Wolf, a provider of managed security services, this week made available a script that helps scanning tools to discover Log4Shell vulnerabilities.
Ian McShane, field CTO for Artic Wolf, said Arctic Wolf has been using a Log4Shell Deep Scan script to detect both CVE-2021-45046 and CVE-2021-44228 vulnerabilities within nested JAR files, as well as WAR and EAR files.
In many cases, developers have copied a subset of the Log4j log management tool into their applications to make it easier to monitor behavior. The challenge is that many scanners can’t discover that code when it is nested within a file, said McShane.
The script created by Arctic Wolf works with both Windows and macOS/Linux operating systems. The script conducts a deeper scan of a host’s filesystem to identify Java applications and libraries with vulnerable Log4j code. Once identified, the script will flag it and identify its location within the host’s filesystem.
McShane said most organizations will likely find themselves spending the next several weeks searching all the Java applications they’ve deployed for Log4j vulnerabilities. The Log4Shell Deep Scan script is being made available on GitHub to any provider of scanning tools that chooses to incorporate it free of charge.
In the longer term, McShane said it’s apparent that the industry will need to address how IT vendors vet open source code. The core Log4j log management tool is maintained by a small handful of individuals. IT vendors have widely used that code without contributing much help to the maintainers of that project to ensure that code is secure.
Less clear is to what degree this vulnerability may encourage IT organizations to retire some Java applications. Such a move is not likely to be taken likely; as other programming languages gain traction, many organizations are modernizing their application portfolios. In some cases, those efforts are being made as part of a larger review of the overall software supply chain.
In the meantime, security teams should expect to see more zero-day vulnerabilities involving open source code that is often maintained by a small number of contributors and maintainers with limited cybersecurity expertise. Those cybersecurity teams would be well-advised to either set up a security incident response team based on modern DevOps processes or rely on the expertise of an external service provider.
Security incident management is, essentially, a subset of IT incident management. Organizations that invest in it are going to see benefits that go well beyond simply the ability to quickly apply a patch. Security issues simply make everyone more cognizant of the need for a set of best practices that make it easier to respond to any unexpected event.
Unfortunately, too many organizations rely on the heroic actions of a few to respond to any crisis. The issue is that heroes are not always available when needed. Instead, the goal should be to institute a set of processes that don’t require anyone to go above and beyond the call of duty to deal with issues that inevitably arise at inconvenient times.
