Log4j is a Java based logging library developed by volunteers and maintained under the Apache Software Foundation (ASF). It’s pluggable nature and cross-platform operability makes it one of the most extensively used logging utilities. Aside from being used directly, it also comes bundled with a lot of softwares, especially Java applications, as the default logging library.
On 9th December a zero-day vulnerability, dubbed “Log4Shell”, was disclosed to the public. This vulnerability gave the attacker the ability to execute arbitrary code on systems by making the log4j library log a specially crafted string. The severity for this security issue is 10, the highest possible vulnerability score. This is one of, if not the most, serious security vulnerabilities in the past decade due to multiple reasons:
Here’s a demonstration of the vulnerability being exploited:
https://www.youtube.com/watch?v=dguVlEpPFgg
Since the public disclosure of the vulnerability, multiple CVEs have been published for log4j:
Use log4jscanwin, a tool created by Qualys, to scan Windows machines.
The following steps will help identify the existence of vulnerable versions of log4j JAR files present on a Windows machine:
Log on to the Windows machine
Use a browser to download the ZIP archive for the latest version of log4jscanwin from https://github.com/Qualys/log4jscanwin/releases/latest
Once downloaded, extract files from the archive, it should contain two directories inside the root folder - x86, x64
To know the architecture of our Windows machine:
Next, navigate to start menu, search for CMD, right click and select the option “Run as administrator” (The administrator password would be required if this task is being performed by a non-admin user)
Inside CMD, navigate to the extracted folder and then to the folder containing the exe file based on the machine’s architecture that was determined in step 4
To start the scan, run the following command:
Log4jScanner.exe /scan
Once the scan is complete, it would list any identified log4j JAR files along with relevant information if the version is vulnerable
Stop at step 8 with the list of softwares containing vulnerable versions of log4j where patching is required to be performed
Additionally, to perform a sanity check against the log4j JAR files that were identified but not classified vulnerable, check if they are false negatives by:
Calculating their SHA1 sums by running the following command in PowerShell
get-filehash -Algorithm SHA1 '<path\to\JAR\file>'
Navigate to this CSV of SHA1 hashes curated from vulnerable log4j JAR files and search if the hash calculated in step ‘a’ exists in the CSV
If the hash matches an existing entry in the CSV, the corresponding JAR file that was identified from the tool (but considered not vulnerable) might also be potentially vulnerable
Log4jscanwin would identify all log4j JARs, but sometimes these JAR files might not be available directly as a JAR. For instance, the JAR could be present under another archive file such as Web Archive (WAR) files. Jenkins is a great example that uses WAR files. When log4jscanwin identifies a log4j JAR inside another archive file, for example “jenkins.war”, the path would look like
path\to\jenkins.war!path\inside\war\to\log4j.jar.
In this case, the result would either be conclusive that the JAR is vulnerable, warranting no further action other than patching it but if the result is inconclusive and you want to verify the SHA1 hash of the JAR yourself, you can use a tool like 7zip to extract files from the WAR file and then navigate to the path of the log4j JAR file, calculate the hash and compare it with the hashes present in the CSV mentioned in the previous section.
Another important thing to note is that it is the Java Naming and Directory Interface (JNDI) that causes the vulnerabilities and not log4j itself. Thus, if the JNDI class is missing from log4j, it is safe to use and not vulnerable to CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105.
Once you have confirmed the existence of vulnerable versions of log4j running on your Windows machines, it is necessary to patch them to mitigate the security issue. Depending on the environment, the mitigation steps differ. For example, if the security issue is found in a managed cloud environment such as AWS, wait for the vendor to patch it. For software that might use log4j as a component, check if the vendor for the software has released an update which includes the patch, and if the update with the patch exists, apply the update as soon as possible.
It should also be noted that some articles mention updating to log4j-2.16.0 as the mitigation. This is no longer true as CVE-2021-45105 is present in all log4j versions from 2.0-alpha1 to 2.16.0 and thus, users must update to log4j-2.17.0 to mitigate all three zero-days identified for log4j.
Log4j is an extensively used, Java based logging utility which was recently found to be vulnerable to a zero-day exploit. Since this software is prevalent in many systems across a diverse range of environments, the attack surface of this vulnerability is extremely wide. This issue is classified with a CVSS score of 10, the highest possible score. From the moment the first zero-day exploit was made public, two more zero-days have been identified.
This is a critical issue and thus needs to be identified in our environments, so any vulnerable versions of log4j can be patched, or at least proper monitoring be set until the vendor releases a patch. Log4jscanwin is a tool that can be utilized to scan our Windows workloads to identify vulnerable log4j JARs and then apply appropriate mitigation strategies to secure ourselves and improve the security posture of our organization.