The recently discovered Log4j vulnerabilities have serious potential to expose organizations across the globe to a new wave of cybersecurity risks. Bad actors can exploit this vulnerability by executing malicious payloads using remote code execution (RCE).
The immediate challenge that every organization faces is simply trying to understand exactly where they have applications that are using this popular Java library.
It is for situations like these that Cowbell partners with the best of the best in the cybersecurity industry, and in this case it is our Incident Response partner Crowdstrike who is stepping up as a leader to offer a free downloadable tool that helps any organization easily scan for any vulnerable log4j libraries in their environment.
The free CrowdStrike tool (dubbed the CrowdStrike Archive Scan Tool, or “CAST”) performs a targeted search by scanning a given set of directories for JAR, WAR, ZIP, and EAR files, and then it performs a deeper scan on those file types matching against a known set of checksums for Log4j libraries. The scanner helps organizations find any version of the affected Log4j library anywhere on disk, even if it is deeply nested in multiple levels of archive files.
CAST searches for approximately 6,500 SHA256 checksums unique to the known vulnerable releases. It will walk the files or directories scanning inside of ZIP-format archives to find every instance of these.
The tool is deployed by downloading the binary to your disk and then executing the binary with the directories or files you want to scan.
CAST reports back in the form of a JSON file when it locates vulnerable Log4j libraries. Organizations can use this output to get an understanding of where the Log4j libraries exist across their environment so they can prioritize the systems that need to be patched using the latest security updates released by Apache.
Using the CAST tool should only be undertaken by IT professionals (if you don’t have IT specialist on staff and believe you might be exposed, Cowbell can put you in touch with resources to help. Contact us at evfxratvarrevat@pbjoryyplore.nv).
- The CAST tool can be found on GitHub: https://github.com/CrowdStrike/CAST
- Download the appropriate version of the cast tool for your server environment here: https://github.com/CrowdStrike/CAST/releases
- Copy the CAST tool to a temporary directory on your server. Ensure the CAST tool has the proper permissions to be executed in your server environment.
- This tool currently has two verbs: “version” and “scan”
# [path to temp directory]/cast version
version: 0.5.1, commit: d8d184fc49315e19f0d37015ed95ae500b2cca1d, date: 2021-12-22T19:41:22Z, builtBy: unknown
To output the CAST scan available options, run cast scan with the -h flag:
# [path to temp directory]/cast scan -h
Usage of [path to temp directory]/cast:
-maxmem uint
maximum sub-archive size to recurse (default 104857600)
-recursion uint
maximum in-memory in-archive recursion (0 disables)
(default 3)
-xdev
do not cross device boundaries (POSIX-only)
Some clarifications on scan options:
– maxmem is specified in bytes only; memory usage should be limited to prevent impacting the performance of end-users
– a recursion of 0 will disable sub-archive scanning, but will still check inside of any first-tier ZIP archive it encounters.
- An example of running against both a ZIP file and a set of directories
[path to temp directory]/cast scan -maxmem 1000000 -recursion 1 ~/tmp/zzz.zip /tmp ./
Note that you can specify individual files AND/OR directories to recurse. This enables leveraging pre-indexed filesystems, e.g.:
locate -0 *.jar | xargs -0 [path to temp directory]/cast scan
Sample output
{“container”:”~/tmp/zzz.zip”,”member”:{“path”:”/log4j-core-2.13.3.jar/org/apache/logging/log4j/core/net/JndiManager.class”,”size”:4885,”modified”:”2020-05-10T12:08:46Z”},”sha256″:”c3e95da6542945c1a096b308bf65bbd7fcb96e3d201e5a2257d85d4dedc6a078″}
{“container”:”~/tmp/zzz.zip”,”member”:{“path”:”/log4j-core-2.13.3.jar/org/apache/logging/log4j/core/util/NetUtils.class”,”size”:4315,”modified”:”2020-05-10T12:08:44Z”},”sha256″:”f96e82093706592b7c9009c1472f588fc2222835ea808ee2fa3e47185a4eba70″}
- This output essentially serves as a roadmap to where all affected Log4j files are located. You can now begin the process of patching these files with the latest updates from the Apache Foundation, Log4J 2.17.1, found here: https://logging.apache.org/log4j/2.x/security.html
