In December 2021, a zero-day remote code execution vulnerability (CVE-2021-442281, Base Score 10.0) was found in Apache Log4j, a widely used Java logging library. The vulnerability was publicly disclosed via GitHub on Dec 9, 2021. The vulnerability allows attackers to take full control of systems without authentication. The vulnerability is also known as "log4shell".
Many recommendations out there suggest the user to find the filenames by typing the GNU/Linux command
find / -iname "*log4j*"
or to find live processes with log4j in their names
ps aux | grep –i 'log4j'
lsof | grep –i "log4j"
The problem with those approaches is that you won't find the vulnerable jar files if the file names have been renamed. You know, sometimes some vendors simply rename libs to whatever reason original jar files. Also in Java's classpath the name of the .jar file is irrelavant, from a security perspective it is the vulnerable classes in the jar file that really matter.
So a better approach is not to search only for their names, search also for their hashes!
This receipt can be used at any time a new critical vulnerability is found - even if it is not in log4j. Nonetheless I will use the log4j example to demonstrate how it works.
1. Identify the files/libs that are vulnerable
CVE-2021-44832 tells us that the issue has been fixed in Log4j 2.17.1 (for Java 8), 2.12.4 (for Java 7) and 2.3.2 (for Java 6). See also https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44832
In other words all other older releases are vulnerable.
2. Download all vulnerable libs
If you don't find older libs on the apache page, you can go to mavencentral to download all vulnerable libs. Go to https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
You should download all vulnerable libs and not just those that are affected by CVE-2021-44832.
3. Create hashes from the libs
Since we want to minimize false positives and minimize hash collisions, we use a non-broken, crytographic well known modern hash algorithm: SHA-3-256
which is the default in Jacksum 3.4.0. Go to the directory where all the libs have been stored and run
jacksum -a sha3-256 --header --no-path -O log4j.hashes .
Note: you don't need to specify -a, because the default is already sha3-256, but it is not guaranteed that future Jacksum releases have the same default algorithm, so it is recommended to specify the algorithm even you don't need to. You can set --header to print invocation args so you will know by which Jacksum version, which algorithm, and when the hashes were generated. Set the option called --no-path, because we don't need the path, we are just interested in the file name. The file will be written to log4j.hashes, and it will be overwritten if it exists.
4. Optional: test with the current working directory
jacksum -w log4j.hashes .
5. Optional: edit log4j.hashes and add CVS info to it
For example you could change the line from
d5a4aa7b06fd43b142caae4381e94ddbff840886470135b0f4314181e2b9bb27 log4j-core-2.17.0.jar
to
d5a4aa7b06fd43b142caae4381e94ddbff840886470135b0f4314181e2b9bb27 original: log4j-core-2.17.0.jar, vulnerability: CVE-2021-44832
and repeat that with additional comments.
6. Go and let find all files that match any of the hashes in log4j.hashes
You can use Jacksum 3.4.0 or later to do that job:
jacksum -w log4j.hashes /
Hint: with this approach you can not only find vulnerable libraries, you can also find copyright protected material, pornography, software in particular versions - anything that you know the digital hashes of.
Bonus: search your system for any Jacksum libraries:
jacksum -w jacksum.hashes /
Downloads
You find Jacksum at https://jacksum.net, and https://github.com/jonelo/jacksum. If you don't like the CLI, you can also use the File Browser Integration which comes with a GUI called HashGarten which is available for Microsoft Windows, macOS, and GNU/Linux.
