AWS凭证泄露调查：过度特权容器的安全风险

摘要

Kubernetes环境中配置错误或过度特权的容器可能促进对敏感AWS凭证的未授权访问，使环境面临权限提升和恶意活动的风险。
Trend™ Research识别了涉及过度特权容器的利用场景，包括嗅探未加密HTTP流量以访问明文凭证，以及利用网络设置拦截授权令牌以获取提升权限的API欺骗。
AWS共享责任模型强调了协作的重要性，服务提供商确保基础设施安全，而客户同样负责管理其容器化应用程序中的权限范围以维护安全环境。
Trend Vision One™容器安全使组织能够执行主动安全策略，检测和缓解超出预期权限级别运行的容器，帮助防止数据包嗅探和API欺骗等利用场景，同时减少整体攻击面并最小化安全风险。

背景

基于Kubernetes的容器平台在云中扮演关键角色，用于高效且大规模地编排和管理容器化应用程序。它们自动化部署、扩展和操作，使其成为微服务和各种工作负载的理想选择。其主要优势包括云可移植性、通过更好资源利用实现成本效率、通过自动化和自我修复加速开发周期，以及简化分布式系统的管理，所有这些都支持弹性和可扩展的应用程序。
Amazon Elastic Kubernetes Service（EKS）是一种托管服务，简化了在Amazon Web Services（AWS）和本地运行Kubernetes的过程。它自动化管理Kubernetes控制平面，确保高可用性和可扩展性，同时与AWS的其他服务无缝集成，用于网络、安全和存储。这使用户能够专注于部署和管理其容器化应用程序。
配置错误或过度特权的容器构成重大安全风险，因为它们可以为攻击者提供对环境中敏感数据和系统资源的未授权访问和控制。实施措施，如确保正确配置和将容器权限限制在仅必要的范围内，对于维护安全的容器化基础设施至关重要。

攻击场景分析

Amazon EKS Pod Identity服务的利用

Amazon EKS Pod Identity是AWS引入的一项功能，用于简化向在EKS集群中运行的pod授予AWS凭证的过程。它提供了IAM Roles for Service Accounts（IRSA）的替代和补充方法，使Kubernetes应用程序能够安全访问AWS资源，如S3桶或DynamoDB表。
设置Pod Identity首先在Amazon EKS集群上安装eks-pod-identity-agent附加组件。该代理作为DaemonSet在kube-system命名空间中运行，确保代理实例在每个工作节点上运行。
代理暴露一个简单的API，接受Kubernetes服务账户令牌在Authorization头中，并调用特定的AWS API操作：eks-auth:AssumeRoleForPodIdentity。此API在链路本地地址（IPv4为169.254.170.23，IPv6为[fd00:ec2::23]）的端口80上暴露。
amazon-eks-pod-identity-webhook变异准入控制器自动更新，以将AWS_CONTAINER_CREDENTIALS_FULL_URI和AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE环境变量注入到使用与Pod Identity关联的服务账户的pod中。这些环境变量被AWS SDK识别。
当使用AWS SDK的pod中的应用程序向AWS服务发出请求时，SDK自动识别相关环境变量并从节点上运行的EKS Pod Identity代理检索临时凭证。代理然后与eks-auth:AssumeRoleForPodIdentity API交互以获取关联IAM角色所需的凭证。

基于数据包嗅探的攻击场景

EKS Pod Identity代理在每个节点上运行，并在本地IP地址上暴露一个API，似乎通过未加密的HTTP。
这带来了安全风险，因为任何具有“hostNetwork: true”设置的pod都可能监控节点上的网络流量，从而能够拦截从API端点169.254.170.23:80发送的任何凭证。由于AWS环境不将这些凭证绑定到特定资产，恶意行为者可以使用它们在环境中获得提升的权限。
使用标准tcpdump实用程序的简单概念验证（PoC）表明凭证以明文传输。鉴于AWS凭证不绑定到特定主机，第三方可以使用它们来承担提升的权限。

基于API欺骗的场景

从启用hostNetwork的容器中移除CAP_NET_RAW能力可能无法完全缓解风险，如果其他允许网络接口操作的权限（如CAP_NET_ADMIN）被启用。只要恶意pod可以操纵网络接口卡（NIC）设置，它就可以通过删除进程绑定的本地链接IP地址来禁用eks-pod-identity-agent HTTP守护进程。这允许攻击者控制运行在169.254.170.23:80上的HTTP服务，并部署自己的HTTP服务器。该服务器能够拦截包含授权令牌的传入HTTP请求，攻击者随后可以使用这些令牌获取有效的AWS凭证。
我们开发了一个用Python编写的PoC，利用常见库如pyroute2，来演示上述利用。

结论和建议

本文中提出的发现突出了在使用Amazon EKS Pod Identity简化Kubernetes环境中AWS资源访问时的关键安全考虑。配置错误，特别是涉及过度特权容器的配置错误，可能暴露AWS凭证并创造重大风险，包括权限提升和云环境中的未授权操作。
通过演示数据包嗅探和API欺骗场景，我们展示了过度特权容器如何被利用来拦截或操纵敏感凭证。这些漏洞强调了遵循最小权限原则的重要性，确保容器配置适当范围，并最小化恶意行为者利用的机会。

供应商披露

上述两种技术已通过Trend Zero Day Initiative™（ZDI）计划报告给Amazon，并记录为ZDI-CAN-26891。AWS的声明如下：
“我们的团队已完成调查，并确定您报告中描述的行为不是安全问题，而是预期行为，属于节点本身的信任边界内，并在共享责任模型的客户侧。节点或集群操作员有责任确保具有提升权限的应用程序适当范围。节点承担pod身份角色的能力是预期的，并与信任边界模型一致，如EKS pod安全最佳实践和共享责任文档中所述。”

使用Trend Vision One识别和防止过度容器权限

容器能力的主动管理是保护容器化环境的重要方面。在配置容器时采用最小权限原则对于最小化攻击面和减少潜在安全风险至关重要。

检测容器中的过度权限

Trend Vision One™容器安全使组织能够定义和执行策略，检测（并可选择阻止）以超出预期配置的提升权限运行的容器。上述利用场景基于具有过度能力（如CAP_NET_RAW、CAP_NET_ADMIN）或hostNetwork标志设置为true的pod。
策略设置可以通过Trend Vision One门户在Cloud Security -> Container Protection下访问，提供一系列配置选项。为了解决上述过度权限，请在Pod属性部分检查记录或阻止“在主机网络命名空间中运行的容器”的选项，以及“具有不符合基线策略的能力的容器”的选项。

有关创建和使用Kubernetes策略的详细信息，请参考以下Trend Vision One文档：

一旦设置了策略，就会检测到违规，如下例所示：