15/12/2021

Update on Log4Shell Vulnerability (CVE-2021-44228) 

As posted previously there have been a number of vulnerabilities to Log4j services based on an update to CVE-2021-44228 – Vulnerability, has now had major developments regarding the Log4j vulnerability since our last advisory.

This update aims to consolidate what we know so far, provide guidance on vulnerability & post-exploit enumeration, updates on the latest patching information. The situation is continuing to evolve, and we will provide further updates as appropriate.

Summary:

A second vulnerability was found on Monday 13th of December, in the Java logging library Apache Log4j in version 1.x. JMSAppender in Log4j 1.x, which is vulnerable to deserialization of untrusted data, CVE-2021-4104. This allows a remote attacker to execute code on the server, if the deployed application is configured to use JMSAppender.  

A third vulnerability involving Apache Log4j was also found on Tuesday 14th of December, CVE-2021-45046. This could allow attackers to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.  

Apache has already released a patch, Log4j 2.16.0, which mitigates both issues. The CVE suggests Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. 

This vulnerability is being actively exploited by numerous threat actors, and reports show it has been used in conjunction with a number of attacks, including but not limited to: Botnet Armies, Crypto-Mining Malware, Cobalt Strike Beacons, Ransomware and Data Exfiltration.  

It is clear the number of combinations on how to exploit Log4j gives an attacker many alternatives to bypass newly introduced protections. The dynamic growth associated with this vulnerability ultimately means one layer of protection is not enough, and only a multi layered security posture can provide the most resilient protection.  

Vulnerability & Post-Exploit Enumeration:

The NCSC have published a detailed advisory which contains valuable advice on discovering unknown instances of Log4j within your organisation, it is recommended to keep checking this article as it is continually updated: https://www.ncsc.gov.uk/news/apache-log4j-vulnerability  

The NCSC-NL have created a comprehensive list of software and its status: https://github.com/NCSC-NL/log4shell/tree/main/software  
 

There are several tools which can help with vulnerable host discovery and patching, see: 

  1. NMAP: https://github.com/Diverto/nse-log4shell  
  2. OWASP: https://github.com/OWASP/Nettacker  
  3. IBM X-Force: https://github.com/xforcered/scan4log4shell 
  4. Huntress: https://log4shell.huntress.com/   

For those investigating Log4j exploitation attempts. This tool pulls the exploit payloads (java code) from the LDAP address provided in the JNDI string. https://github.com/MalwareTech/Log4jTools  

Patching:

Option 1: Upgrade to 2.16.0 

Apache Log4j has released a version that fixes the Log4Shell vulnerability as of version 2.16.0. This version disables JNDI by default and removes the message lookup feature. https://logging.apache.org/log4j/2.x/download.html

Option 2: Enable [formatMsgNoLookups]  

Please note; this provides limited protection and does not protect against all vulnerabilities as per 2021-45046. This option should only be used over the 2.16.0 upgrade where circumstances deem necessary.  
 
Hardcoding the formatMsgNoLookups flag to true. If you are using Log4j version 2.10.0 to version 2.14.0 and can’t yet update, you can still set the flag manually. 

Set formatMsgNoLookups=true when you configure Log4j by performing one of the following: 
 

Pass as a JVM Flag  

You can pass this as an argument when you invoke java. 

 
java -Dlog4j2.formatMsgNoLookups=true … 

 
Set Environment Variable  

Alternatively, this feature may be set via Environment Variable. 

LOG4J_FORMAT_MSG_NO_LOOKUPS=true java … 

 
Or you can set this using the JVM arguments environment variable. 

JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true 

Option 3: JNDI Patch

It is possible to modify the JNDI in place to stop the attack at the language level.

Refence(s):

Questions:

If you have any questions or concerns about this advisory, please contact us via our support desk –support@empsn.org.uk

Keeping Up To Date With Us Is Easy, Sign Up To Our Newsletter Today!

Stay in touch with emPSN, so that you get the latest e-safety advice and invites to our community events.

Our partners