Updates
13/12/21
- Additional research shows that 2.15 is also vulnerable. The latest secure version is 2.15.0-rc-2 or later (NOT 2.15.0 as previously thought) to mitigate the vulnerability. The upgrade is located here: https://logging.apache.org/log4j/2.x/download.html
Purpose
The purpose of this alert is to bring attention to a bug present in the Java logging library, log4j2. The use of this library is extremely common, and Triskele Labs advises that any organisation utilising Java-based software to immediately check for the presence of this library and follow the remediation steps outlined below. The bug results in an unauthenticated Remote Code Execution (RCE) vulnerability. Active exploitation of this vulnerability is likely occurring in the wild as Proof-of-Concept (POC) Code has been released.
Details
On 9 December 2021, researcher Chen Zhaojun from Alibaba Cloud Security team issued a notification describing a critical vulnerability known as CVE-2021-44228 present in the popular Java logging library log4j2. Default installations of widely used enterprise Java-based software utilise this library. The library is commonly present on Apache and Apache struts implementations.
The impact of exploiting this library is remote code execution resulting in full server control. CVE-2021-44228 impacts Log4j 2 versions 2.0 to 2.14.1. There are reports from Log4j maintainers that the 1.x series may also vulnerable to exploitation when using the JMS Appender class.
Exploitation of this vulnerability results in unauthenticated Remote Code Execution which grants Threat Actors the ability to install malicious software and webshells or perform other malicious actions.
The Triskele Labs CTI team advises that Proof-of-Concept (POC) code exploiting the vulnerability was made available on 10 December 2021 on a public Github located at https://github.com/tangxiaofeng7/apache-log4j-poc. This publicly available POC code enables Threat Actors a direct route to exploiting vulnerable versions of Log4j present on servers in the wild.
Mitigation Actions
If you are utilising versions 1 – 2.14.1. of Log4j, Triskele Labs recommends adopting an assumed breach mentality and reviewing logs for impacted applications with unusual activity. Triskele Labs recommends upgrading Log4J to Version 2.15.0 immediately to ensure permanent mitigation. The upgrade is located here: https://logging.apache.org/log4j/2.x/download.html
If an immediate upgrade is not possible, Triskele Labs advises that a temporary mitigation can be implemented with the following steps listed by Cybersecrity company LunaSec:
- Modify every logging pattern layout to %m{nolookups} instead of %m in your logging config files, as defined in https://issues.apache.org/jira/browse/LOG4J2-2109.
- Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application's or stack's classloading documentation to understand this behaviour.
Detection Capabilities
Organisations can check for vulnerable versions of this library by checking for hashes present in software inventories, listed on: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes.
Detection of exploitation can be performed by following the guide located here: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Triskele Labs DefenceShield customers with Assess (our Vulnerability Scanning service) are being assessed currently. All customers with our Monitor (our 24x7x365 SIEM) are - as always - being monitored for Shells and Lateral Movement.
References
References used for the generation of this release:
