What is log4j?
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.
Vulnerabilities in log4j
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:
- Successful exploitation of the vulnerability allows Remote Code Execution (RCE), allowing the attacker to gain access to the underlying system that is running log4j
- The ability to perform this attack (potentially) without authentication because the logs could also be generated for unauthenticated operations
- The ability to piggy-back on the compromised system to exploit other resources that might not have been part of the public internet
- The library is used across multiple operating systems, environments (On prem, Cloud - AWS, GCP, etc.), applications, if not directly then potentially as a bundled package
- Mitigation for the crafted string is extremely difficult due to the sheer amount of variations that could be implemented for the payload string
Here’s a demonstration of the vulnerability being exploited:
Since the public disclosure of the vulnerability, multiple CVEs have been published for log4j:
- CVE-2021-44228 - A vulnerability was identified that logging a specially crafted string could use LDAP and JNDI to invoke arbitrary code. This had a severity rating of 10 (Critical)
- CVE-2021-45046 - It was identified that the patch released for fixing CVE-2021-44228 was incomplete against non-default configurations for log4j and allowed code execution under non-default configurations
- CVE-2021-45105 - It was identified that log4j versions from 2.0-alpha1 through 2.16.0 did not mitigate uncontrolled recursion from self-referential lookups allowing attacker to have control of Thread Control Matrix causing denial of service
Identifying vulnerable log4j JARs on Windows
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 -
To know the architecture of our Windows machine:
- Navigate to the start menu
- Search for “This PC”
- Right click on the “This PC” icon and select the properties option
- Note the architecture mentioned under properties
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:
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
Notes on interpreting results
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
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.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.