Recent research has uncovered critical security flaws in Amazon Elastic Kubernetes Service (EKS) that could expose sensitive AWS credentials and enable privilege escalation within cloud environments.
The vulnerabilities, rooted in misconfigurations and excessive container privileges, highlight the ongoing challenges of securing Kubernetes-based container platforms at scale.
Amazon EKS is a managed service that simplifies running Kubernetes clusters on AWS, automating the management of the Kubernetes control plane and integrating with AWS services for networking, security, and storage.
One of its features, EKS Pod Identity, allows pods to securely access AWS resources by granting temporary credentials via the eks-pod-identity-agent running on each node.
This agent exposes an API on a local IP address, allowing applications in pods to obtain the necessary credentials for their associated IAM roles.
The security risks emerge when containers are misconfigured or granted excessive privileges.
In particular, pods with the hostNetwork: true setting can monitor network traffic on the node, potentially intercepting credentials transmitted in plaintext between the eks-pod-identity-agent and the requesting pod.
Since these credentials are not bound to a specific host, a malicious actor could use them to gain unauthorized access and escalate privileges within the AWS environment.
A proof-of-concept demonstrated that using standard tools like tcpdump, attackers could capture AWS credentials sent over unencrypted HTTP.
This vulnerability is aggravated by the fact that credential binding is not enforced, allowing intercepted credentials to be reused elsewhere in the environment.
Another attack vector involves API spoofing. Even if certain network capabilities (like CAP_NET_RAW) are removed, containers with other privileges (such as CAP_NET_ADMIN) can manipulate network interfaces.
This enables a rogue pod to disable the legitimate eks-pod-identity-agent and replace it with a malicious HTTP server, intercepting requests and harvesting authorization tokens to obtain valid AWS credentials.
Vendor Response and Shared Responsibility
The vulnerabilities were reported to Amazon via the Trend Zero Day Initiative (ZDI) and documented as ZDI-CAN-26891.
AWS responded by stating that the observed behavior is not considered a security issue, but rather expected within the trust boundary of the node.
According to AWS, it falls under the customer’s responsibility to ensure that containers are appropriately scoped and do not possess unnecessary privileges, in line with the shared responsibility model.
Mitigation and Best Practices
Security experts emphasize the importance of adhering to the principle of least privilege when configuring containers.
Organizations should proactively manage container capabilities, restrict the use of hostNetwork: true, and monitor for excessive privileges using security tools.
As Kubernetes adoption continues to grow, these findings serve as a stark reminder that even managed services require vigilant security practices and continuous monitoring to protect sensitive cloud assets.
Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates
Attackers abused compromised ConnectWise Cloud Backup credentials to access Microsoft 365 customer environments, prompting ConnectWise…
Anthropic says an internal Claude research model reconstructed how the National Security Agency generated seeds…
Two WordPress Core vulnerabilities can be chained to execute remote code without authentication, according to…
A newly disclosed OpenBSD kernel exploitation chain combines a shared memory accounting flaw with a…
GhostAction attackers have expanded their GitHub credential theft campaign with a second stage that disguises…
Indian authorities have warned that SideCopy hackers are targeting Indian organizations, including academic institutions, with…