[Update] Immediate Actions to Protect Against Exploitation of the Apache Java Logging Library Log4j Vulnerability
Published on 14 Dec 2021 | Updated on 31 Dec 2021
Fifth Update on 29 Dec 2021:
Apache has released Log4j version 2.3.2 (for Java 6), 2.12.4 (for Java 7) and 2.17.1 (for Java 8) to address an arbitrary code execution vulnerability.
- CVE-2021-44832 - A vulnerability that exists due to a lack of additional controls on JNDI access within Log4j. Attackers with write access to the Log4j logging configuration could configure the JDBCAppender to reference a JNDI URI data source and load arbitrary Java code. This could lead to arbitrary code execution and affects versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4).
Users of Apache Log4j are advised to upgrade to the latest version accordingly.
Fourth Update on 22 Dec 2021:
Apache has released Log4j version 2.3.1 (for Java 6), 2.12.3 (for Java 7) and as previously updated 2.17.0 (Java 8) to address CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228 vulnerabilities. Users of Apache Log4j are advised to upgrade to the latest version accordingly.
Third Update on 20 Dec 2021:
Apache has released Log4j version 2.17.0 to address multiple vulnerabilities.
- CVE-2021-45105 - A vulnerability that exists due to the absence of protection from uncontrolled recursion from self-referential lookups. Attackers could exploit the vulnerability by sending a malicious input data that contains a recursive lookup, resulting in a Denial of Service (DoS) attack.
- CVE-2021-45046 - Initially classified as a DoS vulnerability, it has been discovered that an attacker could exploit this vulnerability by sending a crafted string, which could lead to remote code execution. Its Common Vulnerability Scoring System (CVSS) score has been revised from 3.7 to 9.0.
- CVE-2021-4104 - A vulnerability that exists in Log4j 1.2 JMSAppender due to the deserialisation of untrusted data. Attackers with write access to Log4j configuration could exploit the vulnerability by using JMSAppender to perform JNDI requests, which could result in remote code execution. This vulnerability only affects Log4j 1.2 if it is specifically configured to use JMSAppender, which is not enabled by default.
Users of Apache Log4j are advised to upgrade to the latest version 2.17.0 immediately.
Second Update on 17 Dec 2021:
Log4j version 2.15.0 did not fully mitigate the CVE-2021-44228 vulnerability with certain non-default configurations, potentially resulting in a denial of service attack (CVE-2021-45046). Users should upgrade to 2.16.0 (Java 8) or 2.12.2 (Java 7).
Previous temporary mitigation measures which include configuring the system property (log4j2.formatMsgNoLookups) to true, or modifying the logging configuration to disable message lookups are no longer recommended as they have proven to be insufficient. Users who are unable to upgrade to 2.16.0 or 2.12.2 should disable lookups by removing the jndiLookup class from the log4j-core jar file.
Users who are currently using Log4J Version 1.x can also refer to this advisory for guidance.
Apache has released Log4j version 2.12.2 which has fixed CVE-2021-44228 for Java 7. Users who are unable to upgrade to Log4j version 2.16.0 (Java 8), are advised to upgrade to Log4j version 2.12.2 instead.
Original Advisory published on 14 Dec 2021:
Security researchers have flagged the critical remote code execution (RCE) vulnerability in the Apache Java logging library Log4j (CVE-2021-44228) aka. Log4Shell as one of the most serious vulnerabilities that they have seen. There are reports that this vulnerability is actively being exploited. The proof-of-concept code has also been published.
Hundreds of millions of systems are likely to be affected as Log4j is widely used in many applications and is present in many services as a dependency. These include enterprise applications, including custom applications developed within an organisation, as well as numerous cloud services.
Successful exploitation could allow an attacker to gain full control of the affected servers. Given the severity of the vulnerability, vendors and users are advised to implement the mitigation measures listed below immediately:
Vendors (i.e. product developers that use Log4j in their products) should:
- Identify, mitigate, and develop patches for affected products that utilise Log4j
- Inform end users of your products that contain this vulnerability and strongly urge them to prioritise software updates.
Users (e.g. enterprises and other users who are using products with Log4j) should:
- Patch to the latest updates immediately
Users of Apache Log4j affected versions between 2.0 and 2.16.0 are advised to upgrade to the latest version 2.17.0 immediately. The patch is available for download here: https://logging.apache.org/log4j/2.x/download.html. As the latest patch version of Log4j 2.17.0 requires Java 8, users utilising Java 7 will be required to upgrade to Log4j version 2.12.2 instead. Users should prioritise patching: starting with mission critical systems, internet-facing systems, and networked servers, and then prioritise patching other affected information technology and operational technology assets.
The Log4j library is frequently used in software. A non-exhaustive list of vulnerable products is provided below:
- Determine if Log4j is used in other instances within the System
As Java applications can include all the dependent libraries within their installation, administrators should check for other instances where Log4j is used. Users can perform a file system search to determine if Log4j is installed elsewhere. This includes searching inside EAR, JAR and WAR files. More specific steps on searching can be found here: https://www.randori.com/blog/cve-2021-44228/
- Deploy Protective Network Monitoring and Review System Logs
Users that have Web Application Firewalls (WAFs) should ensure applicable rules are applied to protect against the vulnerability. These could include blocking URLs containing exploit strings like “jndi:ldap”. Users are also advised to implement outbound traffic restrictions so that Log4j servers cannot openly communicate and attempt to download arbitrary malicious payload from the Internet . The concept of “deny by default” should apply to servers – with authorised outbound traffic flows explicitly defined and enforced. However, WAFs should not be relied on as the only control, and users should also adopt other measures to defend their network as certain variants of the string may bypass WAF rules.
The attack may involve JNDI remote class loading, which refers to the downloading of a remote malicious .class file onto the server. Users that deploy or maintain their Java applications can look out for alien Java .class found within the CLASSPATH. A list of other exploit strings can be found here: https://www.mandiant.com/resources/log4shell-recommendations
Users can also search for outgoing LDAP, DNS and RMI connections to Internet destinations not seen before 1 December 2021. If detected, users should search the initiating host for the presence of Log4j. If DNS queries are logged, queries by the host should be reviewed to check for any possible exfiltration over DNS protocol.
Users can also use these commands and rules to search for exploitation attempts: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
For users who are unable to upgrade to 2.17.0 or 2.12.2, disable lookups by removing the jndiLookup class from the log4j-core jar file. More details can be found here: https://logging.apache.org/log4j/2.x/security.html
For users of Log4j 1.x
Log4j 1.x is not vulnerable to CVE-2021-44228. However, it has reached its end-of-life (as of 2015) and is no longer supported by Apache for bug and security fixes. In addition, it contains security vulnerabilities. Specifically, Log4j 1.2 when configured to use JMSAppender is vulnerable to CVE-2021-4104 deserialisation of untrusted data when the attacker has write access to the Log4j configuration.
Users are advised to consider upgrading to Log4j version 2.17.0 (or higher). However, users should note that Log4j 2.x API is incompatible with Log4j 1.x. As such, extensive re-coding and testing of your Java applications would be required when doing the upgrade.
For Log4j 1.x users who are unable to upgrade, these vulnerabilities may be mitigated by removing the JMSAppender class file from the classpath. More details can be found here: https://access.redhat.com/security/cve/CVE-2021-4104
Reporting a compromise
Singapore organisations affected by this vulnerability should report to SingCERT if any evidence of compromise is found. A report can be made via our Incident Reporting Form at https://go.gov.sg/singcert-incident-reporting-form (Incident Category: Malware/Device Related, Incident Type: Others).
As there have been reports globally of widespread scanning for this vulnerability, organisations may have received HTTP requests with the JNDI string as a form of scanning activity. Please notify SingCERT only of cases where you have identified malicious Java being loaded into one of your systems, or where any follow-on activity has occurred after receiving these HTTP requests.
More information is available here:
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/
https://auscert.org.au/bulletins/ASB-2021.0244
https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://logging.apache.org/log4j/2.x/download.html
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages
https://github.com/NCSC-NL/log4shell/tree/main/software
https://www.randori.com/blog/cve-2021-44228/
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://www.cyberscoop.com/log4j-cisa-easterly-most-serious/
