Apache Log4j CVE-2021-44228 Log4Shell Vulnerability

Log4Shell - Log4j

UPDATE 1: 16/12/2021 – Added new vulnerability information and update from Sophos MTR Team.


On December 9 2021, a severe remote code vulnerability was revealed in Apache’s Log4J , a very common logging system used by developers of web and server applications based on Java and other programming languages. The vulnerability affects a broad range of services and applications on servers, making it extremely dangerous—and the latest updates for those server applications urgent. This vulnerability impacts millions of websites and applications across the globe.

The vulnerability is officially recorded as CVE-2021-44228, and commonly referred to as Log4Shell. It has been classified as “Critical” with a CVSS score of 10, allowing for Remote Code Execution with system-level privileges. 

In other words, it gets a full 10 out of 10 for it’s impact and scale, allowing an attacker to remotely run software on a vulnerable system over the internet. 

Since this information was made public, RODIN has been reviewing it’s internal systems to identify if any components are vulnerable while also reviewing customers environments using the latest information from software vendors.

RODIN can confirm that none of the software used by RODIN to manage customer environments use the Log4J component and were not impacted by this vulnerability. 

We have identified a number of software platforms used by our customers that are impacted and are working with those vendors to get work arounds in place, or the software upgraded where they are available. 

It is important to note that the Log4J component is bundled with many other software applications, meaning in many cases we need to rely on the vendors to advise if their platforms are vulnerable or not and what actions are required. 

For RODIN customers, we can confirm that Sophos, our security vendor of choice, and our RODIN Voice platform, based on 3CX, is NOT impacted and no further action is required.

RODIN will continue to use all available options available to identify if our customer environments have vulnerable software, however IT IS CRITICAL that you reach out to your software providers and get confirmation if upgrades or work arounds are required.

For our Managed Cyber Security customers using the Resilience or Comprehensive packages, or Sophos Managed Threat Response customers, the Sophos MTR team has been conducting threat hunts across customer estates using the latest intelligence. Should they observe any suspicious or malicious activity stemming from this vulnerability and CVE, they will take action to stop the attack and notify RODIN of the actions.

If you are concerned and want verification if you have been impacted by this vulnerability, a service such as Sophos MTR is the only way to identify any indicators of compromise (IOC) in your environment. Due to the ongoing increase, sophistication and scale of vulnerabilities being identified, we recommend all clients use Sophos MTR to protect their environments.

We will continue to keep this page up to date as more information is released, and provide important reference sites below for further information:

Sophos Advisory: https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce

Sophos Explanation: https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

Consolidated list of Vendor Responses Advisories: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Consolidated list of software impacted: https://github.com/NCSC-NL/log4shell/tree/main/software

Official CVE Reference: https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Sophos MTR Team Update as of 16/12/2021:

// Overview

Since our last update
there have been several developments on CVE-2021-44228 which are detailed

Given how quickly things
have evolved with this vulnerability, another CVE (CVE-2021-45046) was
introduced into the log4j library. This was introduced, as the fix to address
the previous vulnerability in version 2.15.0 was incomplete in certain
non-default configurations. This new vulnerability, while not as severe as the
previous RCE, can result in a denial-of-service against the application.

To address the new CVE
(CVE-2021-45046), log4j has issued another version 2.16.0 which completely
removes the JNDI from log4j.

Customers who have
already upgraded to log4j 2.15.0 should evaluate upgrading to the newly
released 2.16.0 version to address this second vulnerability. For those who are
still in the process of patching, it is recommended to go directly to log4j
2.16.0 at this time.

It has also been
determined that several previously suggested mitigations are no longer
effective against this exploit. For those who were unable to upgrade log4j and
instead set the “log4j2.formatMsgNoLookups” property or the environmental
variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to True, it is now critical to upgrade
to the latest version of log4j to mitigate CVE-2021-44228.


// What you should do

  • Three links are listed in the references below of
    lists being maintained of known vulnerable software and applications. If
    you are aware of these existing within your environment, install the
    latest patches from the vendors.
  • Those who have already upgraded to log4j 2.15.0 need
    to assess the possible impact of the newly reported CVE-2021-45046 in
    their estate as it could cause a denial-of-service condition. It is still
    suggested to upgrade to log4j 2.16.0.
  • Those who have not begun the patching process, should
    immediately upgrade to Apache Log4j 2.16.0 or higher on all relevant
    applications in the environment. 
  • Those who implemented the previously recommended
    mitigations by configuring the “log4j2.formatMsgNoLookups” property or the
    environmental variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” to True, need to
    upgrade to log4j 2.16.0, as these mitigations were determined not to be
  • If the tools are readily available, continue running
    vulnerability scans (both internal and external) to identify possible
    vulnerable applications and log4j libraries


// What Sophos MTR is doing

The MTR team has been
threat hunting across our customer’s estates to determine possible exposures.
In addition to the increased threat hunting around this activity, our team is
continuing to monitor for any signs of post-exploit activity.

  • Sophos is continuing to publish new protections
    against this threat as it evolves. This includes both protection
    capabilities for CIXA, XG, and our other products, as well as detection
    capabilities leveraged by our MTR team.
  • The MTR team is currently focused on threat
    mitigation of observed post-exploit activity within our customer estates,
    the MTR team will operate according to your defined response preferences.
  • With this being a dynamic and evolving threat, we are
    continuously monitoring for changes in attacker behaviour so we can better
    monitor and protect your estate.

Subscribe to Our Newsletter

Sign up to receive all the latest news updates straight into your inbox.