2.2 针对Kubernetes的攻防矩阵
Kubernetes是开源历史上最受欢迎的容器编排系统,也是发展最快的项目之一,已成为许多公司计算堆栈中的重要组成部分。容器的灵活性和可扩展性鼓励许多开发人员将工作负载转移到Kubernetes上来。尽管Kubernetes具有许多优势,但它也带来了新的安全挑战。因此,了解Kubernetes中存在的各种安全风险至关重要。针对Kubernetes的安全攻防,虽然攻击技术与针对Linux或Windows的攻击技术不同,但战术实际上是相似的,青藤基于目前在ATT&CK领域的研究,创建一个类似ATT&CK的矩阵——Kubernetes攻防矩阵(如表2-1所示),将其作为一个框架,介绍针对Kubernetes基础设施和应用的关键攻击战术和技术。
表2-1 Kubernetes攻防矩阵
2.2.1 通过漏洞实现对Kubernetes的初始访问
初始访问战术包括所有用于获得资源访问权限的攻击技术。在容器化环境中,这些技术可以实现对集群的初始访问。这种访问可以直接通过集群管理工具来实现,也可以通过获得对部署在集群上的恶意软件或脆弱资源的访问来实现。
1. 云账户访问凭证泄漏
用户将项目代码上传到Github等第三方代码托管平台,或者个人办公PC被黑等,都可能导致云账号访问凭证发生泄漏,如果泄漏的凭证被恶意利用,可能会导致用户上层的资源(如ECS)被攻击者控制,进而导致Kubernetes集群被接管。
2. 运行恶意镜像
在集群中运行一个不安全的镜像可能会破坏整个集群的安全。进入私有镜像仓库的攻击者可以在镜像仓库中植入不安全的镜像。而这些不安全的镜像极有可能被用户拉取出来运行。此外,用户也可能经常使用公有仓库(如Docker Hub)中不受信任的恶意镜像。基于不受信任的根镜像来构建新镜像也会导致类似的结果。
3. Kubeconfig/token泄漏
Kubeconfig文件中包含了关于Kubernetes集群的详细信息,包括集群的位置和相关凭证。如果集群以云服务的形式托管(如AKS或GKE),该文件会通过云命令下载到客户端。如果攻击者获得该文件的访问权,那么他们就可以通过被攻击的客户端来访问集群。
4. 应用漏洞
在集群中运行一个面向互联网的易受攻击的应用程序,攻击者就可以据此实现对集群的初始访问。例如那些运行有RCE漏洞的应用程序的容器就很有可能被利用。如果服务账户被挂载到容器(Kubernetes 中的默认行为)上,攻击者就能够使用这个服务账户凭证向API服务器发送请求。
2.2.2 恶意代码执行
为了实现攻击目标,攻击者会在集群内运行受其控制的恶意代码。与运行恶意代码相关的技术通常与所有其他战术下的技术相结合,以实现更广泛的目标,例如探索网络或窃取数据。例如,攻击者可能使用远程访问工具来运行PowerShell脚本,以实现远程系统发现。
1. 在容器中执行命令
拥有权限的攻击者可以使用exec命令(kubectl exec)在容器集群中运行恶意命令。在这种方法中,攻击者可以使用合法的镜像,如操作系统镜像(如Ubuntu)作为后门容器,并通过使用kubectl exec远程运行其恶意代码。
2. 创建新的容器或Pod执行命令
攻击者可能试图通过部署一个新的容器在集群中运行他们的代码。如果攻击者有权限在集群中部署Pod或Controller(如DaemonSet/ReplicaSet/Deployment),就可以创建一个新的资源来运行其代码。
3. 容器内应用的漏洞利用
如果在集群中部署的应用程序存在远程代码执行漏洞,攻击者就可以在集群中运行恶意代码。如果服务账户被挂载到容器中(Kubernetes中的默认行为),攻击者将能够使用该服务账户凭证向API服务器发送请求。
4. 在容器内运行的SSH服务
运行在容器内的SSH服务可能被攻击者利用。如果攻击者通过暴力破解或者其他方法(如网络钓鱼攻击)获得了容器的有效凭证,他们就可以通过SSH服务获得对容器的远程访问。
2.2.3 持久化访问权限
持久化战术是指攻击者用来保持对集群持久访问的技术,以防他们最初的立足点丢失,确保在防守方重启、更改凭证或采取其他可能中断攻击者访问的措施后,依然保持对失陷系统的访问权限。
1. 后门容器
攻击者在集群的容器中运行他们的恶意代码。通过使用Kubernetes控制器,如DaemonSets或Deployments,攻击者可以确保在集群中的一个或所有节点上运行确定数量的容器。
2. 挂载宿主机敏感目录的容器
攻击者在运行新的容器时,使用-v参数将宿主机的一些敏感目录或文件(例如/root/.ssh/、/etc、/var/spool/cron/、/var/run/docker.sock、/proc/sys/kernel/core_pattern、/var/log等)挂载到容器内部目录,进而写入ssh key或者crond命令等,来获取宿主机权限,最终达到持久化的目的。
3. Kubernetes CronJob
Kubernetes CronJob基于调度的Job执行,类似Linux的Cron,攻击者可以利用Kubernetes CronJob产生一个Pod,然后在里面运行给定的命令,进而实现持久化。
4. 特权容器
用docker --privileged可以启动Docker的特权模式,这种模式可以让攻击者以其宿主机具有的几乎所有能力来运行容器,包括一些内核功能和设备访问权限。在这种模式下运行容器会让Docker拥有宿主机的访问权限,并带有一些不确定的安全风险。
5. WebShell
如果容器内运行的Web服务存在一些远程命令执行(RCE)漏洞或文件上传漏洞,攻击者可能利用该类漏洞写入WebShell。由于主机环境和容器环境的差异性,一些主机上的安全软件可能无法查杀此类WebShell,所以攻击者也会利用此类方法进行权限维持。
2.2.4 获取更高访问权限
在攻击开始时,攻击者通常进入并探索具有非特权访问权限的网络,但需要更高的权限才能实现其目标。常见的方法是利用系统脆弱性、错误配置和漏洞来提升访问权限。
1. 特权容器
特权容器是一个拥有主机所有能力的容器,它解除了普通容器的所有限制。实际上,这意味着特权容器几乎可以做主机上可操作的所有行为。攻击者如果获得了对特权容器的访问权限,或者拥有创建新的特权容器的权限(例如,通过使用被攻击的Pod的服务账户),就可以获得对主机资源的访问权限。
2. 创建高权限的binding roles
基于角色的访问控制(RBAC)是Kubernetes的一个关键安全功能。RBAC可以限制集群中各种身份的操作权限。Cluster-admin是Kubernetes中一个内置的高权限角色。如果攻击者有权限在集群中创建binding roles,就可以创建一个绑定到集群管理员ClusterRole或其他高权限的角色。
3. 挂载宿主机敏感目录的容器
hostPath mount可以被攻击者用来获取对底层主机的访问权,从而从容器逃逸到主机,获得主机具有的所有能力。
4. 通过泄漏的配置信息访问其他资源
如果Kubernetes集群部署在云中,在某些情况下,攻击者可以利用他们对单个容器的访问获得对集群外其他云资源的访问权限。例如,在AKS中,每个节点都包含服务凭证,存储在/etc/kubernetes/azure.json中。AKS使用这个服务主体来创建和管理集群运行所需的Azure资源。
默认情况下,该服务委托人在集群的资源组中有贡献者的权限。若攻击者获得了该服务委托人的文件访问权(例如,通过hostPath挂载),就可以使用其凭证来访问或修改云资源。
2.2.5 隐藏踪迹绕过检测
在攻击过程中,攻击者通常会利用受信任的进程伪装其恶意软件,隐藏其踪迹,绕过防守方的检测措施。
1. 清除容器日志
攻击者可能会删除被攻击的容器上的应用程序或操作系统日志,防止防守方检测到他们的活动。
2. 删除Kubernetes日志
Kubernetes日志会记录集群中资源的状态变化和故障。记录的事件包括容器的创建、镜像的拉取或一个节点上的Pod调度。Kubernetes日志对于识别集群中发生的变化非常有用。因此,攻击者可能想删除这些事件(例如,通过使用“kubectl delete events-all”),以免检测到他们在集群中的活动。
3. 创建与已有应用相似名称的恶意Pod/容器
由控制器(如Deployment或DaemonSet)创建的Pod,其名称后缀是随机生成的。攻击者可以利用这一事实,将他们的后门Pod命名为由现有控制器创建的Pod名称。例如,攻击者可以创建一个名为“coredns-{随机后缀}”的恶意Pod,看起来与CoreDNS部署有关。另外,攻击者可以在管理容器所在的kube-system命名空间中部署他们的容器。
4. 通过代理隐藏访问IP
Kubernetes API Server会记录请求IP,攻击者可以使用代理服务器来隐藏他们的源IP。具体来说,攻击者经常使用匿名网络(如TOR)进行活动。这可用于与应用程序本身或与API服务器进行通信。
2.2.6 获取各类凭证
攻击者会获取类似于名称、密钥、身份信息等的凭证。攻击者用来窃取凭证的技术主要包括键盘记录或凭证转储。获得有效凭证,会让攻击者能够合法访问系统,更难检测,或者创建更多账号以实现其攻击目标。
1. Kubernetes Secret
Kubernetes Secret也是Kubernetes中的一个资源对象,主要用于保存轻量的敏感信息,比如数据库用户名和密码、令牌、认证密钥等。Secret可以通过Pod配置进行使用。有权限从API服务器中检索Secret的攻击者(例如,通过使用Pod服务账户)就可以访问Secret中的敏感信息,其中可能包括各种服务的凭证。
2. 云服务凭证
当集群部署在云中时,在某些情况下,攻击者可以利用他们对集群中容器的访问权限来获得云凭证。例如,在AKS中,每个节点都包含服务凭证。
3. 访问容器服务账户
Service Account Tokens是Pod内部访问Kubernetes API Server的一种特殊的认证方式。攻击者可以通过获取Service Account Tokens,进而访问Kubernetes API Server。
4. 配置文件中的应用凭证
开发人员会在Kubernetes配置文件中存储敏感信息,例如Pod配置中的环境变量。攻击者如果能够通过查询API服务器或访问开发者终端上的这些文件来访问这些配置,就可以窃取存储的敏感信息并加以利用,例如数据库、消息队列的账号密码等。
2.2.7 发现环境中的有用资源
获得对某个环境的访问权限后,攻击者会通过不断探索,寻找环境中是否有其他有用资源,以便他们实现横向移动并获得对额外资源的访问权限。
1. 访问Kubernetes API
Kubernetes API是进入集群的网关,在集群中的任何行动都是通过向RESTful API发送各种请求来执行的。集群的状态,包括部署在其上的所有组件,可以由API服务器检索。攻击者可以发送API请求来探测集群,并获得关于集群中的容器、秘密和其他资源的信息。
2. 访问Kubelet API
Kubelet是安装在每个节点上的Kubernetes代理,负责正确执行分配给该节点的Pod。如果Kubelet暴露了一个不需要认证的只读API服务(TCP端口10255),攻击者获得了主机的网络访问权(例如,通过在被攻击的容器上运行代码)后就可以向Kubelet API发送API请求。具体来说,攻击者通过查询https://[NODE IP]:10255/pods/就可以检索节点上正在运行的Pod。https://[NODE IP]:10255/spec/可以用于检索节点本身的信息,例如CPU和内存消耗。
3. 集群中的网络和服务
攻击者可以在集群中发起内网扫描来发现不同Pod所承载的服务,并通过Pod的漏洞进行后续渗透。
4. 访问Kubernetes看板
Kubernetes看板是一个基于Web的用户界面,用于监控和管理Kubernetes集群。通过这个看板,用户可以使用其服务账户在集群中执行操作,其权限由该服务账户绑定或集群绑定决定。攻击者如果获得了对集群中容器的访问权,就可以使用其网络访问看板上的Pod。因此,攻击者可以使用看板的身份检索集群中各种资源的信息。
5. 查询元数据API服务
云提供商提供实例元数据服务,用于检索虚拟机的信息,如网络配置、磁盘和SSH公钥。该服务可通过一个不可路由的IP地址被虚拟机访问,该地址只能从虚拟机内部访问。攻击者获得容器访问权后,就可以查询元数据API服务,从而获得底层节点的信息。
2.2.8 在环境中横向移动
横向移动战术包括攻击者用来在受害者的环境中移动的技术。在容器化环境中,这包括从对一个容器的特定访问中获得对集群中各种资源的访问权限,从容器中获得对底层节点的访问权限,或获得对云环境的访问权限。
1. 访问云资源
攻击者可能会从一个被攻击的容器转移到云环境中。
2. 容器服务账户
攻击者获得对集群中容器的访问权限后,可能会使用挂载的服务账户令牌向API服务器发送请求,并获得对集群中其他资源的访问权限。
3. 集群内的网络和服务
默认状态下,通过Kubernetes可以实现集群中Pod之间的网络连接。攻击者获得对单个容器的访问权后,可能会利用它来实现集群中另一个容器的网络访问权限。
4. 访问Tiller endpoint
Helm是一个流行的Kubernetes软件包管理器,由CNCF维护。Tiller在集群中暴露了内部gRPC端口,监听端口为44134。默认情况下,这个端口不需要认证。攻击者能在任何可以访问Tiller服务的容器上运行代码,并使用Tiller的服务账户在集群中执行操作,而该账户通常具有较高的权限。
2.2.9 给容器化环境造成危害
危害战术包括攻击者用来破坏、滥用或扰乱容器环境正常行为的技术。
1. 数据破坏
攻击者可能试图破坏集群中的数据和资源,包括删除部署、配置、存储和计算资源。
2. 资源劫持
攻击者可能会滥用失陷的资源来运行任务。一个常见情况是攻击者使用失陷的资源进行数字货币挖矿。攻击者如果能够访问集群中的容器或有权限创建新的容器,就可能利用失陷的资源进行这种活动。
3. 拒绝服务
攻击者可能试图进行拒绝服务攻击,让合法用户无法使用服务。在容器集群中,这包括损害容器本身、底层节点或API服务器的可用性。
4. 加密勒索
恶意的攻击者可能会加密数据,进而勒索用户,索要匿名的数字货币。
了解容器化环境的攻击面是为这些环境建立安全解决方案的第一步。本节介绍的矩阵可以帮助企业确定其防御系统在应对针对Kubernetes的不同威胁方面存在的差距。