Patches meant to protect 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.”
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.”
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.”