Ausnutzung von Schwachstellen
An Investigation of AWS Credential Exposure via Overprivileged Containers
Overprivileged or misconfigured containers in Amazon EKS can expose sensitive AWS credentials to threats like packet sniffing and API spoofing, highlighting the need for least privilege and proactive security to detect and reduce these risks.
Save to Folio
Summary
- Misconfigured or overly privileged containers in Kubernetes environments can facilitate unauthorized access to sensitive AWS credentials, exposing the environment to privilege escalation and malicious activity.
- Trend™ Research identified exploit scenarios involving overprivileged containers, including packet sniffing of unencrypted HTTP traffic to access plaintext credentials and API spoofing, which uses network settings to intercept Authorization tokens and gain elevated privileges.
- The AWS shared responsibility model highlights the importance of collaboration, with the service provider ensuring infrastructure security while customers are equally responsible for managing privilege scoping within their containerized applications to maintain a secure environment.
- Trend Vision One™ Container Security allows organizations to enforce proactive security policies that detect and mitigate containers operating beyond intended privilege levels —helping prevent exploit scenarios such packet sniffing and API spoofing, while reducing the overall attack surface and minimizing security risks.
Kubernetes-based container platforms play a critical role in the cloud for orchestrating and managing containerized applications efficiently and at scale. They automate deployment, scaling, and operations, making them ideal for microservices and various workloads. Among its key benefits include cloud portability, cost efficiency through better resource utility, accelerated development cycles via automation and self-healing, and simplified management of distributed systems, all of which enable resilient and scalable applications.
Amazon Elastic Kubernetes Service (EKS) is a managed service that streamlines running Kubernetes on Amazon Web Services (AWS) and on-premises. It automates the management of the Kubernetes control plane, ensuring high availability and scalability, while seamlessly integrating with other AWS services for networking, security, and storage. This enables users to focus on deploying and managing their containerized applications.
Misconfigured or overly privileged containers pose significant security risk since they can provide attackers with unauthorized access and control over sensitive data and system resources within an environment. Implementing measures such as ensuring proper configuration and limiting container privileges to only what is necessary is crucial to maintaining a secure containerized infrastructure.
In this blog post, we will examine packet sniffing-based and API spoofing-based attack scenarios, which are used to exploit excessive privileges granted to containers. Our aim is to demonstrate how these misconfigurations can be abused to extract sensitive AWS security credentials directly from within containerized applications, highlighting a critical concern in cloud environments.
We will also show how to use Trend Vision One™ to detect and respond to excessive privileges by enforcing customizable policy settings within the Container Protection section of the Trend Vision One portal.
The exploitation of the Amazon EKS Pod Identity service
Amazon EKS Pod Identity is a feature introduced by AWS to simplify the process of granting AWS credentials to pods running in an EKS cluster. It offers an alternative and complementary method to IAM Roles for Service Accounts (IRSA), enabling secure access to AWS resources such as S3 buckets or DynamoDB tables from within Kubernetes applications.
Setting up Pod Identity begins with installing the eks-pod-identity-agent add-on on the Amazon EKS cluster. This agent operates as a DaemonSet in the kube-system namespace, ensuring that an instance of the agent is running on each worker node.
The agent exposes a simple API that accepts the Kubernetes service account token in the Authorization header and calls a specific AWS API action: eks-auth:AssumeRoleForPodIdentity. This API is exposed on a link-local address (169.254.170.23 for IPv4 and [fd00:ec2::23] for IPv6) on port 80.
The amazon-eks-pod-identity-webhook mutating admission controller is automatically updated to inject the AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE environment variables into pods that use a service account associated with a Pod Identity. These environment variables are recognized by the AWS SDKs.
When an application in a pod using an AWS SDK makes a request to an AWS service, the SDK automatically identifies the relevant environment variables and retrieves temporary credentials from the EKS Pod Identity agent running on the node. The agent then interacts with the eks-auth:AssumeRoleForPodIdentity API to obtain the necessary credentials for the associated IAM role.
Packet sniffing-based attack scenario
The EKS Pod Identity agent operates on each node and exposes an API on a local IP address seemingly over unencrypted HTTP.
This presents a security risk since any pod with ‘hostNetwork: true’ settings can potentially monitor network traffic on the node, enabling the interception of any credentials being sent from the API endpoint 169.254.170.23:80. Since the AWS environment doesn't bind these credentials to a specific asset, malicious actors can use them to gain elevated privileges within the environment.
A trivial proof-of-concept (PoC) using the standard tcpdump utility demonstrates that credentials are being transmitted in plaintext. Given that AWS credentials are not bound to a specific host, they can be used by a third party to assume elevated privileges.
API spoofing-based scenario
Removing the CAP_NET_RAW capability from a hostNetwork enabled container may not fully mitigate the risk if other privileges allowing network interface manipulation, such as CAP_NET_ADMIN, become enabled. As long as a rogue pod can manipulate Network Interface Card (NIC) settings, it can disable the eks-pod-identity-agent HTTP daemon by deleting the local link IP address the process is bound to. This allows an attacker to assume control over the HTTP service running on 169.254.170.23:80 and deploy their own HTTP server. This server would be capable of intercepting incoming HTTP requests containing Authorization tokens, which the attacker can subsequently use to obtain valid AWS credentials.
We have developed a PoC written in Python, utilizing common libraries such as pyroute2, to demonstrate the exploit described above.
Conclusion and recommendations
The findings presented in this blog highlight critical security considerations when using Amazon EKS Pod Identity for simplifying AWS resource access in Kubernetes environments. Misconfigurations, particularly involving containers with excessive privileges, can expose AWS credentials and create significant risks, including privilege escalation and unauthorized actions within a cloud environment.
Through the demonstration of packet sniffing and API spoofing scenarios, we have showcased how overprivileged containers can be exploited to intercept or manipulate sensitive credentials. These vulnerabilities underscore the importance of adhering to the principle of least privilege, ensuring container configurations are scoped appropriately, and minimizing opportunities for exploitation by malicious actors.
Vendor disclosure
The two techniques described above have been reported to Amazon via the Trend Zero Day Initiative ™ (ZDI) program and recorded as ZDI-CAN-26891. AWS’s statement is as follows:
"Our team has completed the investigation and determined that the behavior described in your report is not a security issue, but rather expected behavior that falls within the trust boundary of the node itself and is on the Customer Side of the Shared Responsibility Model. It is the responsibility of the node or cluster operator to ensure that applications with elevated permissions are appropriately scoped. The ability for the node to assume pod identity roles is expected and aligns with the trust boundary’ model, as outlined in the EKS pod security best practices and the shared responsibility documentation.”
Identifying and preventing excessive container privileges using Trend Vision One
The proactive management of container capabilities is a vital aspect of securing containerized environments. Employing the principle of least privilege when configuring containers is crucial to minimizing the attack surface and reducing potential security risks.
Detection of excessive privileges in containers
Trend Vision One™ Container Security enables organizations to define and enforce policies that detect (and optionally block) containers operating with elevated privileges beyond the intended configuration. The exploit scenarios outlined above are based on containers with excessive capabilities, such as CAP_NET_RAW, CAP_NET_ADMIN, or pods with hostNetwork flag set to true.
The policy settings can be accessed via the Trend Vision One portal under Cloud Security -> Container Protection, offering a range of configuration options. To address the excessive privileges mentioned above, check the option to Log or Block “containers that run in the host network namespace” within the Pod properties section and also the option “containers with capabilities that do not conform with a Baseline policy”.
For detailed information on creation and use of Kubernetes policies, please refer to the following Trend Vision One documentation:
- https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-kubernetes-prot-policy
- https://docs.trendmicro.com/en-us/documentation/article/c3124722-5232-484a-a42d-3ed454227a6d-kubernetes-protection-policies
Once policies have been set, the violations are detected, as seen in the example below:
