December 29, 2021

# Using log4jscanwin to identify Log4j vulnerabilities on Windows machines

A step-by-step guide on how to identify Log4j vulnerabilities on Windows machines using log4jscanwin

What is log4j?

Vulnerabilities in log4j

Identifying vulnerable log4j JARs on Windows

Notes on interpreting results

Mitigation

Conclusion

## 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:

1. Successful exploitation of the vulnerability allows Remote Code Execution (RCE), allowing the attacker to gain access to the underlying system that is running log4j
2. The ability to perform this attack (potentially) without authentication because the logs could also be generated for unauthenticated operations
3. The ability to piggy-back on the compromised system to exploit other resources that might not have been part of the public internet
4. 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
5. 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:

1. 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)
2. 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
3. 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
4. (Update) CVE-2021-44832 - A RCE is possible in v2.17.1 as well under controlled conditions. Vulnerability rated with moderate severity.

## 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:

1. Log on to the Windows machine

3. Once downloaded, extract files from the archive, it should contain two directories inside the root folder - x86 and x64.

4. To know the architecture of our Windows machine:

1. Navigate to the start menu
2. Search for “This PC”
3. Right click on the “This PC” icon and select the properties option
4. Note the architecture mentioned under properties

5. 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)

6. 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

7. To start the scan, run the following command:

Log4jScanner.exe /scan

8. Once the scan is complete, it would list any identified log4j JAR files along with relevant information if the version is vulnerable

9. Stop at step 8 with the list of softwares containing vulnerable versions of log4j where  patching is required to be performed

10. 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:

1. Calculating their SHA1 sums by running the following command in PowerShell
get-filehash -Algorithm SHA1 '<path\to\JAR\file>'
1. Navigate to this CSV of SHA1 hashes curated from vulnerable log4j JAR files and search if the hash calculated in step ‘1’ exists in the CSV
1. 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 the 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

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, CVE-2021-45105 and CVE-2021-4483.

## Mitigation

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.

## Conclusion

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.

## ***

This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.

Written by:

## Riyaz Walikar

Chief Hacker

Riyaz is a security evangelist, offensive security expert and researcher with over a decade of experience in the cyber security industry. His passion to break into some of the most well defended networks and systems in his career spanning 15 years has earned him a lot respect within the security industry. He has led Security Assessment and Penetration Testing teams at Pricewaterhouse Coopers (PwC) and Appsecco, and the Product Security Team at Citrix before co-founding Kloudle. Riyaz now specializes in cloud native, container and cloud security in general, helping build an easy to use security management platform to help companies enhance their visibility in the cloud, identify security misconfigurations and automate remediation for security gaps enabling compliance and operational security in multi-cloud environments. He is also an avid speaker and trainer and presents his research and findings at security conferences and community meetups around the world including BlackHat USA, BH Europe, BH Asia, nullcon and OWASP AppsecUSA.Specialties: Cloud (AWS, GCP, Azure, IBM, Others) Security, Cloud-Native Security, Kubernetes, Container Security, Web Application Security, Network and System Penetration Testing, Wireless Network Security, Malware Analysis and Reverse Engineering, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering. Certifications: CKA, CKAD, OSCP