Threat Advisory: Java Library Vulnerability 'Log4Shell' Exploited

A new remote code execution vulnerability has been discovered affecting a common software library used in many systems and applications. A Java library, log4j2, is widely used in embedded systems to cloud services such as Apple iCloud. It is often part of common internet-facing web services that use Apache as part of the stack. The vulnerability has published exploit code and there is evidence of it already being exploited by malicious actors.

What does it do? 

Systems and applications process a lot of information and then log events to support troubleshooting, performance, and security. By providing an application with specific input, which is passed onto the logging function, full control of the server is achieved as a result of the vulnerability. 

What is affected

Any system that uses the Apache log4j library, version 2.0 through 2.14.1. This is likely to be a lot of web-facing systems.

On December 15th a new vulnerability, CVE-2021-45046, was found affecting the patched version of Log4j (2.15.0) in certain non-default configurations.  

How is it exploited

It varies depending on the actual system, however, it can be as simple as entering a maliciously crafted text string into a website form. 

As an example, Apple was vulnerable by changing the name of an iPhone managed within iCloud to a maliciously crafted text string. 

Remediation

Version updates as outlined below should be performed to remediate the associated CVEs:

• Version 2.15 of log4j has been released that permanently resolves CVE-2021-44228.
• Version 2.16 of log4j has been released that permanently resolves CVE-2021-45046. 

Many applications will need to package the updated library into their own product updates so there may be delays in being able to update exploitable systems. 

Temporary Mitigation

Versions of Apache log4j 2.10.0 or newer

Set formatMsgNoLookups=true in the Apache log4j configuration. 

Versions of Apache log4j 2older than 2.10.0

1. Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files. see details at https://issues.apache.org/jira/browse/LOG4J2-2109
   
   
2. Remove the JndiLookup class from the classpath
   
   
3. Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that the classloader uses a replacement instead of the vulnerable version of the class. 

Temporary mitigations are likely to be suitable in a small percentage of environments where they have been custom developed. 

Vendors

Cloudflare WAF rules have been created to block external exploitation attempts. 

https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/ 

Note: Exploitation that initiates internally can create a connection outbound, bypassing the WAF. 

Fortinet IPS signatures have yet to be updated. 

Tenable is yet to release plugins to identify vulnerable systems.

[Updated: 4:06pm 11 December 2021 AEST]

Fortinet FortiWeb, FortiADC and Fortigate IPS have signatures available. Note: Fortigate IPS default behaviour is allow. 

Tenable plugin is now available. 

[Updated 11:33am 12 December 2021 AEST]

Additional Technical Detail

Requirements for exploitation: 

• A server with a vulnerable version of log4j
• an endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string
• a log statement that logs out the string from that request 

Further information

https://www.randori.com/blog/cve-2021-44228/

https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability

https://www.theverge.com/2021/12/10/22828303/log4j-library-vulnerability-log4shell-zero-day-exploit

https://www-cnblogs-com.translate.goog/yyhuni/p/15088134.html?_x_tr_sl=auto&_x_tr_tl=en

Need help with your organisation's cybersecurity? Contact us to discuss how we can help you be more secure and reduce your business risk.