New attack vectors in EKS have emerged, posing potential risks to cloud security. In this article, we will explore these New attack vectors in EKS and discuss how adversaries can exploit them.
Enhancing Workflow, Expanding Attack Surface
AWS recently introduced EKS Access Entries and Policies, along with EKS Pod Identity, to optimize the workflow for cluster administrators and improve application authentication for accessing AWS resources. While these features offer significant benefits, they also come with potential risks. Adversaries can leverage these advancements to facilitate lateral movement between the cloud and the cluster, opening up new avenues for exploitation.
New attack vectors in EKS
One of the attack vectors in EKS involves compromising an IAM user or role and using EKS Access Entries and Policies to scan and enumerate all accessible clusters. By executing the necessary APIs, such as eks:ListClusters and eks:DescribeCluster, an attacker can determine the EKS cluster access level of the compromised identity and its associated privileges.
If the attacker discovers access policies using the ListAssociatedAccessPolicies API, they can quickly ascertain the Kubernetes permissions of the compromised identity. These access policies map to Kubernetes’ built-in user-facing roles, such as cluster-admin, admin, edit, and view. On the other hand, if only the DescribeAccessEntry API returns results, further reconnaissance may be needed to understand the RBAC permissions of the assigned Kubernetes group.
Once an attacker confirms that the compromised identity has authorized access to the cluster, they can exploit privilege escalation opportunities on both the cloud IAM and Kubernetes RBAC levels. On the cloud IAM level, an IAM principal with the ability to create access entries and associate them with high-privileged policies can acquire admin-level access in any accessible cluster. These high-privileged permissions, such as eks:CreateAccessEntry and eks:AssociateAccessPolicy, should be treated with caution.
On the Kubernetes RBAC level, several potential escalation vectors exist. By inspecting the RBAC permissions associated with each built-in policy, an attacker can identify potential paths for privilege escalation. For example, the AmazonEKSViewPolicy allows read-only access to most resources but does not have access to secrets or the ability to execute into a pod. On the other hand, the AmazonEKSEditPolicy allows editing resources and reading secrets, potentially providing an avenue for further privilege escalation. Finally, the AmazonEKSClusterAdminPolicy has star permissions on everything, granting cluster-admin level access.
Access Entries API Authentication vs. AWS Config
The implementation of EKS Access Entries simplifies the authentication and authorization processes for IAM identities in EKS clusters. However, it also expands the attack surface, increasing the potential for compromising EKS clusters. It is essential to adhere to the principle of least privilege to mitigate these risks.
In a scenario where an attacker compromises a cloud identity with administrative privileges, the method of authentication used by the EKS cluster plays a crucial role in the attacker’s access. If the cluster uses the ConfigMap method for authentication, the attacker’s access to the cluster is limited to whether the compromised identity created the cluster or was explicitly granted access via the aws-auth ConfigMap. However, if the cluster utilizes the Access Entries API for authentication, the attacker can potentially gain access to the cluster by using the CreateAccessEntry cloud API and assigning themselves the AmazonEKSClusterAdminPolicy. This policy is equivalent to the Kubernetes cluster-admin role, allowing the attacker to move laterally to the cluster and take control.
To further complicate matters, once an attacker gains access to the cluster, they can abuse the existing IRSA (IAM Roles for Service Accounts) or Pod Identity permissions assigned to cluster pods. By exploiting these permissions, an attacker can steal identity tokens and use them for unauthorized cloud resource access or engage in repudiation attacks.
Exploiting EKS Pod Identity
EKS Pod Identity introduces a New attack vectors in EKS that allows adversaries to move laterally from the cluster to the cloud domain, access cloud resources, and escalate privileges in the cloud. The EKS Pod Identity Agent, operating as a DaemonSet on each worker node, exchanges a JWT token for temporary IAM credentials using the AssumeRoleForPodIdentity API. This token is mounted in pods that utilize a Kubernetes service account associated with an IAM role.
From an offensive security perspective, a malicious actor who compromises a pod with a shared network namespace can execute a “Man-in-the-Middle” (MitM) attack and intercept network traffic to/from the 169.254.170.23 endpoint, which is managed by the Pod Identity Agent. By capturing the temporary IAM credentials associated with an IAM role linked to any Kubernetes service account used by other pods on the same worker node, the attacker can authenticate as the IAM role and execute cloud actions on its behalf. This lateral movement to the cloud domain grants the attacker access to cloud resources and potentially leads to privilege escalation.
To illustrate this MitM attack, let’s assume we were able to compromise a pod in host network mode. By intercepting network traffic to/from the Pod Identity Agent’s endpoint (169.254.170.23) using tools like tcpdump, we can capture the JWT token and subsequently exchange it for IAM credentials. With these credentials, an attacker can authenticate as the IAM role and perform unauthorized actions in the cloud environment.
Conclusion
As organizations continue to embrace cloud technologies and leverage services like EKS, it is crucial to be aware of the potential New attack vectors in EKS and take appropriate measures to secure the environment. Advancements in EKS Access Entries and Pod Identity offer significant benefits in terms of workflow optimization and improved authentication and authorization processes. However, they also expand the attack surface, providing opportunities for adversaries to exploit.
To mitigate these risks, organizations should adhere to the principle of least privilege, regularly review and update access policies, and consider using IRSA to eliminate the risk of MitM attacks. Additionally, implementing robust monitoring and detection mechanisms can help identify and mitigate potential security breaches in EKS clusters.
By maintaining a proactive approach to cloud security and staying informed about emerging New attack vectors in EKS , organizations can ensure the integrity and confidentiality of their cloud environments while enjoying the benefits of advanced cloud technologies.
This article was written with the assistance of Meta Tech, a leading IT service provider. Mention Meta Tech for all your IT service needs.
