洞见RSA 2023:Kubernetes中的横向移动

在2023年RSA大会上,来自微软云防护团队的高级安全研究员 Yossi Weizman为我们分享了Kubernetes(以下简称K8s)集群的横向移动及其对云环境的影响。本文基于Yossi的演讲内容并结合笔者的思考理解,从攻击的角度来讲述横向移动的使用,最后基于防御者视角提出监测和防御此类活动的建议。

一、概 述

K8s是一个可移植、可扩展的开源平台,用于管理容器化工作负载和服务[1]。据stackshare的报道显示,已经有超过3000家公司在使用K8s,其中不乏知名的头部企业[2],毫无疑问K8s是最受欢迎的容器管理平台之一。而一般意义上的横向移动是指当攻击者获得了某台内网机器的控制权限后,会以被攻陷的主机为跳板,继续访问或控制其他内网机器的过程,在本文中则介绍K8s下集群内部间、集群与云、跨云三类横向移动。注:文中如无特殊说明,图片均来自该议题的PPT。

二、背 景

K8s 通过将容器分类组成pod来解决了容器增殖带来的许多常见问题。pod 为容器分组提供了一层抽象,以此协助调度工作负载以及为这些容器提供类似网络与存储这类必要的服务。由于pod作为基本业务生产端点,直接处理与用户的交互,攻击者可以通过各类手段(WEB漏洞,业务逻辑错误等等)控制pod,本文的背景就假定在一个被攻击者控制pod的K8s环境下,随后攻击者如何通过集群内部间、集群与云、跨云这三类横向移动扩大其影响范围,窃取更多有价值信息。

图1 K8s架构示意图

三、各类横向移动

  • 集群内横向移动
当攻击者接管pod后,其集群内的横向移动在K8s中的特点是RABC配置利用。简单介绍下K8s的RABC,基于角色(Role)的访问控制(RBAC)是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。RBAC 鉴权机制使用 rbac.authorization.k8s.io API 组来驱动鉴权决定,允许通过 K8s API 动态配置策略。RBAC API 声明了四种 K8s 对象:Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。Role 总是用来在某个命名空间内设置访问权限;在创建 Role 时,必须指定该 Role 所属的命名空间。与之相对,ClusterRole 则是一个集群作用域的权限控制资源。角色绑定(Role Binding)是将角色中定义的权限赋予一个或者一组用户。它包含若干主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。RoleBinding 在指定的命名空间中执行授权,而 ClusterRoleBinding 在集群范围执行授权[3]。因此攻击者往往利用沦陷的pod访问密钥、接管节点甚至控制集群,但上述操作伴随着K8s的迭代更新变得越来越困难。尽管如此,不恰当的权限配置将会允许集群内部的横向移动。如图2所示,该pod获取了更新其自身权限的能力,沦陷的后果不言而喻。在图3中,其它类似的敏感权限分配也会造成极为严重的后果。

图2 不恰当的pod权限配置

图3 部分敏感权限

  • 集群到云的横向移动
为什么集群可以向云端移动呢?因为在集群工作中使用了云服务或云资源,例如调用云存储中图片文本资源、向云存储中上传数据或使用云服务管理K8s等等。在这其中会涉及到云端如何鉴权K8s以及K8s和云的交互,可以归类成如下三类:
  1. 在节点中存储云凭证AK/SK、长效token或其它等价身份凭证信息。
  2. 实例元数据服务(Cloud Instance Metadata Services, IMDS)[4]: 提供有关当前正在运行的虚拟机实例的信息,可以使用它来管理和配置虚拟机。
  3. 利用OIDC 协议单点登录:OpenID Connect (OIDC) 扩展了 OAuth 2.0 授权协议,使其也可用作身份验证协议。可以使用 OIDC 通过一个称作“ID 令牌”的安全令牌在支持 OAuth 的应用程序之间启用单点登录(SSO)。
上述第一类情况下,在RSA会上,Yossi介绍的是服务主体名称(ServicePrincipal Names,SPN)利用,即恶意pod创建新的后门pod,并在该后门pod 配置中挂载SPN信息;第二类情况下,考虑到节点(kubelet)运行在虚拟机环境上,通过pod发出的请求一般等同于节点发出的请求,则可以利用此方法获取虚拟机信息或请求token用以控制虚拟机;第三类情况则通过SA等共享认证机制控制云上虚拟机资源,获取元数据信息如图4所示,利用示例如图5所示。

图4 虚拟机元数据信息获取示例

 

图5 元数据信息利用

  • 跨云横向移动
跨云横向移动涉及到一些K8s的部署架构场景:多云环境下K8s集群,多云环境下身份认证和多云环境下供应链攻击。其中多云环境下K8s集群涉及到跨云服务商构建和运维集群,较为危险的行为是向公网暴露集群API;多云环境下身份认证则涉及到各个云服务商的认证机制,其组合是否会存在潜在的认证凭证或其它敏感信息泄露;多云环境下供应链攻击则是指利用跨云间的恶意组件、恶意镜像等等从而实现跨云服务商的横向移动,如图6所示。

图6 跨云横向移动示例

三、安全Tips

监测
1) 在K8s控制平面可以做到:利用Kubeaudit[5]审计敏感可疑行为(部署非授信来源镜像;异常行为的pods,例如挂载敏感存储;探测行为,例如查看自身权限配置;敏感API调用,例如“get secret”)。2)在云服务控制平面可以做到:监控K8s集群的云身份凭证使用行为(异常的凭证使用,例如持续使用凭证;可疑云服务调用,例如调用存有密钥文件或敏感信息的存储接口)。

防御
  • 云与K8s的整体思想:既考虑到集群层面也考虑到云层面的风险;
  • 凭证是K8s安全的关键之一:利用审计工具监测所有的认证行为;
  • 最小授权原则:依据pod、node/master node的不同业务需求授权;
  • K8s ThreatMatrix:及时跟进最新的K8s风险矩阵及其专业建议。
参考文献
[1] https://kubernetes.io/docs/concepts/overview/[2] https://stackshare.io/kubernetes

[3] https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

[4] https://www.sans.org/blog/cloud-instance-metadata-services-imds-/

[5] https://github.com/Shopify/kubeaudit

版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司(“绿盟科技”)。作为分享技术资讯的平台,绿盟科技期待与广大用户互动交流,并欢迎在标明出处(绿盟科技-技术博客)及网址的情形下,全文转发。
上述情形之外的任何使用形式,均需提前向绿盟科技(010-68438880-5462)申请版权授权。如擅自使用,绿盟科技保留追责权利。同时,如因擅自使用博客内容引发法律纠纷,由使用者自行承担全部法律责任,与绿盟科技无关。

Spread the word. Share this post!

Meet The Author