e2e's response to log4j vulnerabilities

This blog will be updated regularly as we understand more about the log4j software vulnerabilities.

—– 13/01/22, 10:00 update —–

We have released a new blog, reviewing the first month of log4j, covering what we’ve seen so far, what we can expect and repeating the top advice from e2e. You can find the blog here.

—– 21/12/21, 09:00 update —–

We have released a separate blog with updated guidance, based on all we currently know about the log4j vulnerabilities.

—– 20/12/21, 14:00 update —–

A further update of Apache Log4j has been realeased, which addresses a further DoS vulnerability.

NCSC has continued updating its’ guidance page on the log4j vulnerabilities.

CISA has an up to date list of all affected/not affected products and tools that should be checked, with patches completed as soon as possible.

Many software vendors have either released patches, or are still currently evaluating the impact on their services, continue to check with your software vendors and patch as appropriate. We recommend that you follow up-to-date guidance from the vendor, regardless of whether you have log4j installed or not.

—– 15/12/21, 12:00 update —–

A further update of Apache Log4j has been released, as the original patch has been found to be insufficient to provide protection in certain configurations (CVE-2021-45046). While not as impactful as the original Log4j vulnerability (CVE-2021-44228), we still recommend all customers patch to the latest released version of Log4j (2.16.0) as soon as possible.

https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046

Relatedly, while several software vendors have either determined that they are not impacted, or impacted and have issued patches, there are still vendors continuing to evaluate their products to determine this. Please remain vigilant for emergency security patches released by software vendors that you use in your business.

—– 13/12/21, 16:00 update —–

Executive Summary

On Friday the 10th December, e2e issued a threat brief regarding the log4j software package being vulnerable to unauthenticated remote code execution (CVE-2021-44228). As a commonly used software package integrated into other software, over the weekend, the scope of this impact has become more widely understood. Numerous software vendors have indicated that they could be or are vulnerable to this, with new software patches being released.

This issue has been widely publicised, with widespread untargeted scanning of the internet quickly following, as security researchers and cybercriminals attempt to identify vulnerable systems. Shortly after this, activity has been seen installing malware on vulnerable systems to e.g. mine for bitcoin or participate in other botnet activity.

This situation will persist for some time as vendors evaluate their software and issue patches as appropriate. Organisations should prepare for a sustained period of emergency software patches being released that will need to be installed to appropriately protect against this vulnerability.

Is e2e affected by this?

We confirmed quickly on the 10th of December that our software Cumulo and the related collectors are not vulnerable, and are not using the log4j software component.

Like all other organisations, we are tracking the updates from the software vendors that we use and will patch our systems promptly as these are released.

What are we doing?

Like other vulnerability announcements, this is routine work for the SOC. Since Friday we have deployed detections looking for specific evidence of the vulnerability exploitation. Our external vulnerability scanning has also been upgraded to proactively detect log4j usage on our customers externally where possible.

Crucially, we are looking for the evidence of post-exploitation activity and not just the initial attacks. This is a normal procedure for us; it is not always possible to detect the inbound attacks (especially with 0-day exploits), but we can detect the post-exploitation activity that an attacker will undertake.

We continue to monitor the situation and increase our detection capabilities as appropriate.

What you can do

Proper patch management (as vendors will patch eventually) and comprehensive security monitoring is the best response to this situation.

Even if you are confident that your organisation does not use the log4j software package, it is highly likely that you are using software from a vendor that does. You should refer to your software vendors support page for their guidance on if they are vulnerable to this, any mitigation guidance, and how to ultimately remediate this vulnerability (likely through a software patch).

We recommend that you deploy Endpoint Detection and Response (EDR) software if the impacted device supports it and provide the logs to e2e. This will help to detect and potentially block the post-exploitation activity. You should also ensure you have the correct logging in place – i.e. create or update your logging policy (sysmon/auditd) to ensure you have good visibility of potentially impacted devices. If this is not already being shared with e2e, this can be added into Cumulo.

Finally, review and update your Incident Response plans as appropriate. Given the potential impact and ease of exploitation it is plausible that these might be needed until more comprehensive vendor software patches are released.

Further information

If you are an e2e customer, please continue to engage with the SOC via Cumulo.

If you are not an e2e customer, then please get in touch via our contact us form to talk about how we can support you.

A good overview of potential, fixed & known software vulnerabilities is available here.

Written on December 13, 2021