Threat Alert: Critical Log4J vulnerability leaves millions of applications and systems at risk

Billed as possibly the ‘single biggest, most critical vulnerability of the last decade’ the Log4Shell vulnerability has put millions of computers at risk of being taken over by hackers. In our blog post, KYND explains the issue and how we can help.

*Update Dec 20 2021:
The Apache Software Foundation (ASF) has now disclosed a third vulnerability in Log4j which is capable of Denial of Service and Remote Code Execution. This issue affects all versions from 2.0-beta9 to 2.16.0. We would highly advise you to patch to

Log4j 2.17.0

to close this new issue, if this isn't possible immediately then you should consider following the mitigation steps as outlined by the ASF:

• In PatternLayout in the logging configuration, replace Context Lookups like

  ${ctx:loginId}or $${ctx:loginId}

  with Thread Context Map patterns

  (%X, %mdc, or %MDC)

  .
• Otherwise, in the configuration, remove references to Context Lookups like

  ${ctx:loginId}

  or

  $${ctx:loginId}

  where they originate from sources external to the application such as HTTP headers or user input.

ASF has further noted that Log4j versions 1.x have reached end of life and are no longer supported.

*Update Dec 15 2021:
A second Log4j vulnerability has been disclosed after the patch to fix the initial Log4Shell exploit was deemed as incomplete. We would advise you to patch to Log4j 2.12.2 or Log4j 2.16.0 to close this new issue, if this isn't possible immediately then you should consider disabling JNDI as an alternative measure.

The issue

On Friday 10th December, a critical zero-day exploit was discovered in a popular Java library called Log4j; The library is widely adopted and used in many commercial and open-source software products as a logging framework. The vulnerability CVE-2021-44228 is critical, since attackers can exploit it to execute code and grant themselves privileged access to systems.

Why is this such a big deal?

The scope and breadth of this critical exploit are exceptionally broad and far reaching due to Log4j’s ubiquitous usage. It can affect any software, services, or components that use an affected version of Log4j. A non-exhaustive list of vulnerable software has been published, and is being maintained by NCSC-NL here.

The range of possible exploit mechanisms is vast, and trivial to execute. To demonstrate how widespread and easy it is to exploit - there are reports of people being able to trigger the exploit through simple web forms, Twitter handles, and even through Minecraft’s chat functionality.

The exploit code for attackers to insert has been made publicly available and so malicious users are actively attempting to exploit this against victims.

Sophos has already detected hundreds of thousands of attempts since December 9 to remotely execute code using this vulnerability, and log searches by other organizations (including Cloudflare) suggest the vulnerability may have been openly exploited for weeks. 11/16 pic.twitter.com/dbAXG5WdZ8

— SophosLabs (@SophosLabs) December 13, 2021

What should you do?

As this is a severe vulnerability under active exploitation, we recommend acting with urgency to patch and update any vulnerable instance of Log4j to Log4j-2.15.0. We expect this to be a time-consuming task due to the ubiquitous usage of the Log4j library and would advise using the NCSC-NL list as a starting point. We would additionally recommend evaluating logs for any intrusions and a review of network security.

How KYND is helping customers?

Since the discovery of the Log4j vulnerability, we have been busy at work testing and implementing a detection capability for this new vulnerability. We are now directly testing externally-facing services for evidence of this vulnerability on behalf of our customers and partners.

If you would like KYND to help your organisation please contact us.

The technical details

CVE-2021-44228 affects Log4j between versions 2.0 and 2.14.1.

If patching/upgrading isn't immediately possible you can mitigate the vulnerability:

For version >=2.10: set log4j2.formatMsgNoLookups to true

For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from log4j completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting

You may check for exploitation attempts in your logs using the following:

Web server Linux/Unix command - sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/

Searching network logs for - jndi:ldap or /Basic/Command/Base64/