Sensitive Information Leak and Privilege Escalation Vulnerability on Amazon EKS

Nam Anh Mai D.Nam Anh Mai D.
3 min read

Amazon Elastic Kubernetes Service (EKS) - a service that allows users to deploy, manage, and operate Kubernetes clusters on the AWS platform, has recently caught the attention of the security community due to the emergence of a new critical vulnerability. This vulnerability causes sensitive information leaks and allows attackers to escalate privileges within the system.

Detailed Information

Recently, on TrendMicro's forum, security researcher Jiri Gogela posted an article announcing the existence of a vulnerability in Amazon Elastic Kubernetes Service (EKS). This vulnerability allows hackers to exploit it to escalate privileges and access credential information in AWS.

The target of this vulnerability is Amazon EKS Pod Identity, a feature used to simplify the process of granting AWS credentials to pods running in an EKS cluster. The service operates through the eks-pod-identity-agent extension, functioning as a DaemonSet in kube-system and exposing an API on the local link address 169.254.170.23 for IPv4 and fd00:ec2::23 for IPv6 on port 80.

When applications make requests to AWS services, the SDK automatically retrieves temporary credentials from the EKS Pod Identity agent, then interacts with the AWS API to obtain the necessary credentials for the associated IAM. From here, security researchers have identified two main attack vectors exploiting this vulnerability, including Packet Sniffing techniques and API Spoofing techniques.

For the exploitation technique based on Packet Sniffing, since the EKS Pod Identity agent operates on each node and exposes the API on the local IP address via unencrypted HTTP, it poses a high security risk. Any pod configured with hostNetwork: true can monitor network traffic on the node, resulting in the pod being able to intercept any credentials sent from the API endpoint at 169.254.170.23:80. In this case, a simple action like using the tcpdump tool can successfully capture the plaintext credentials being transmitted.

Figure 1. Gaining elevated privileges via the tcpdump utility

Figure 1: Gaining elevated privileges through tcpdump - Source: TrendMicro

In the case of exploitation based on API Spoofing techniques, if CAP_NET_RAW is disabled from a container with hostNetwork enabled, it does not completely eliminate the risk of exploitation if other permissions like CAP_NET_ADMIN are still enabled. In their experiments, security researchers found that a single malicious pod could disable the HTTP daemon of the eks-pod-identity-agent by deleting the local link IP address that the process is using. This means an attacker could take control of the HTTP service running on the address 169.254.170.23:80 and deploy their own HTTP server capable of intercepting incoming HTTP requests containing authorization tokens, then use this information to obtain valid credentials on AWS.

Figure 2. Python-based POC demonstrating an API spoofing-based attack

Figure 2: Using the pyroute2 library in Python to exploit vulnerabilities based on API Spoofing techniques - Source: TrendMicro

Mitigation & Recommendations

Improper configuration, especially when granting too many permissions to containers, has led to risks like those mentioned. For users utilizing Amazon EKS Pod Identity to access AWS resources in a Kubernetes environment, the following actions should be taken to minimize the risk of facing similar issues:

  1. Grant minimal permissions to containers: Only provide necessary permissions, avoiding dangerous permissions like CAP_NET_ADMIN, hostNetwork: true configuration, or unnecessary root access.

  2. Protect the EKS Pod Identity service: Control access to the address 169.254.170.23 by using NetworkPolicy and only allow trusted pods to access it.

  3. Use IAM Roles instead of static credentials: Always use AWS IAM roles for service accounts (IRSA) to grant permissions instead of hard-coding AWS credentials in applications.

  4. Regularly check configurations and security: Use tools like trivy and kube-bench to detect risky configurations and periodically review deployment files.

References

  1. An Investigation of AWS Credential Exposure via Overprivileged Containers | Trend Micro (US)
0
Subscribe to my newsletter

Read articles from Nam Anh Mai D. directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Nam Anh Mai D.
Nam Anh Mai D.