【云攻防系列】从攻击者视角聊聊K8S集群安全（上）

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

前言

作为云原生管理与编排系统的代表Kubernetes简称K8S正受到越来越多的关注有报告[1]显示96% 的组织正在使用或评估
K8S其在生产环境下的市场占有率可见一斑。

K8S 的功能十分强大其系统复杂性也同样较高一般而言程序越复杂则越容易存在安全问题自然而然地K8S 集群也同样面临着严重的安全威胁如 K8S
组件的未授权访问、容器逃逸和横向攻击等。我们说攻和防是相互促进、相伴而生的作为相关安全人员首先应该从整体上把握业务架构可能面临的安全威胁才有可能做好防护。
本文就以攻击者的视角来聊一聊在 K8S 集群架构下可能存在哪些可攻击的点。

根据以往的渗透测试经验我们梳理了 K8S 集群架构下可能存在的安全问题并在如图1的 K8S 集群基础架构图中标注了潜在的攻击点

图1- K8S集群攻击点

本文将从图 1 出发在介绍图中标注的攻击点的同时总结一些在对 K8S 集群进行实际渗透测试的过程中常用的攻击方法。

本文共分为上、下两篇本篇为上篇主要介绍对 K8S 组件、节点对外服务、业务 pod
的攻击以及容器逃逸即对应图1的攻击点1~7。其余内容将在下篇介绍。

K8S集群攻击点1~7

1. 攻击点 1~4攻击K8S组件

K8S 组件的问题主要是指各组件的不安全配置攻击点1~4罗列了4个比较有代表性的组件问题即 API Server 未授权访问、etcd
未授权访问、kubelet 未授权访问、kube-proxy 不安全配置。

除此之外还有很多组件都存在着类似的安全问题比如 dashboard、docker 等组件也存在未授权访问的隐患这些都是 K8S
集群的重要系统组件一旦被攻击成功都是可以直接获得相应集群、节点或容器的权限的。

表1搜集了各个组件存在隐患的默认端口供参考

组件名称

默认端口

—|—

api server

8080/6443

dashboard

8001

kubelet

10250/10255

etcd

2379

kube-proxy

8001

docker

2375

kube-scheduler

10251

kube-controller-manager

10252

表1- K8S 各组件默认端口

2. 攻击点5攻击节点对外服务

除了正常的对外业务可能还会有一些“隐藏”的对外开放服务这些服务本不该暴露在外网这种情况或是管理员疏忽所致亦或是为了方便管理而故意留的一些接口总之也是一个潜在的攻击点。

比如笔者之前遇到过 Mysql 对外服务存在弱口令登录的问题目标系统的其中一个节点通过 NodePort 对外映射了 Mysql
服务端口且经过尝试通过弱口令可登录。这种情况就属于是管理员的安全意识不足。

说到对 Mysql 的攻击我们在之前的渗透测试过程中总结了三条 Mysql 的攻击路径可供参考如图2

图2- Mysql 攻击路径

1. 通过 NodePort 等对外暴露的接口直接访问 Mysql并通过弱口令登录数据库对应图2中步骤1

2. 攻击应用程序获取 pod 的 shell在 pod 内通过环境变量发现 Mysql
服务的内网地址然后尝试通过弱口令登录对应图2中步骤2-1、2-2

3. 攻击应用程序获取 pod 的 shell并成功逃逸到节点利用 docker inspect 查看或直接进入当前节点运行的Mysql
容器可以看到其环境变量保存着数据库名、root密码和数据库的登录地址等信息前提是 Mysql
容器要和应用容器部署在同一节点上另外环境变量中是否会保存数据库密码等敏感信息取决于 Mysql 容器的具体配置。对应图2中步骤3-1、3-2、3-3

3. 攻击点6攻击业务 pod

在云原生环境下上层应用程序对攻击者来说就像是集群的一个个入口攻击应用程序的目标就是突破入口拿到业务环境也就是业务所在 pod 的 shell。

Web安全发展这么多年可利用的漏洞非常之多远的不说就比如 2021 年年底曝出的 Log4j2-RCE
漏洞CVE-2021-44228以及前不久的 Spring-RCE漏洞CVE-2022-22965其危害非常之大且其利用也很简单比如
Log4j2 漏洞虽然在高版本和低版本的JDK环境下利用方法不同但网上都已经分别有非常多的现成EXP可用一旦成功利用即可以完全接管整个业务pod。

尽管进入 pod
后的权限仍然是受限的但总算是进入了集群内部接下来可以通过尝试更多攻击手法比如横向、逃逸等逐步扩大战果直至控制整个集群。在那之前我们对 pod
本地也可以实施一些攻击如信息搜集、提权、拒绝服务。

3.1 信息搜集

进入一个新 pod 中首先要做的应该是搜集当前环境的信息。

一是搜集环境信息 为后续攻击做准备。如下是一些比较有价值的信息可供参考

OS、Kernel、User 基本信息
可用的 Capabilities
可用的 Linux 命令
挂载情况
网络情况
云厂商的 metadata API 信息

二是敏感服务发现和敏感信息扫描。 敏感服务发现可以通过扫描内网指定网段的端口除了 K8S 组件的端口外还有如下的常见服务端口

ssh22
http80/8080
https443/8443
mysql3306
cAdvisor4194
nodeport-service30000-32767

敏感信息则包括业务相关的敏感文件比如代码、数据库、业务涉及的 AK/secret 或者重要的配置文件等、环境变量可能暴露一些敏感服务信息、K8S
的ServiceAccount 信息默认保存在 /run/secrets/kubernetes.io/serviceaccount/
目录下、进程信息有无敏感服务等。

3.2 提权

K8S 中有两种提权一种是 pod 内提权一种是 K8S 提权。

一Pod 内提权

pod 内提权和传统 Linux 提权差不多就是将 pod 内普通用户的 shell 提升为 root 权限的 shell。一般来讲即使拿到了 pod
的 shell 也只能拥有普通用户的权限此时能做的事情依旧十分有限所以需要利用提权漏洞拿到 root 权限。提权的方式有很多比如内核漏洞提权、sudo
提权、suid 提权、cronjob 提权等。

值得一提的是有些内核漏洞也可以用于容器逃逸比如著名的 DirtyCowCVE-2016-5195、DirtyPipeCVE-2022-0847
等这在下文的“容器逃逸”部分还会提到。

二K8S 提权

K8S 提权的方式和场景有很多比如 RBAC 提权[2]还有一些用于 K8S 提权的 Nday比如
CVE-2018-1002105、CVE-2020-8559 等。

3.3 拒绝服务

拒绝服务Denial of ServiceDOS攻击可以从三个层面来看业务、pod、集群。

对业务和 pod 的 DOS 攻击可以通过使用一些压力测试工具或方法进行主要可从 CPU、内存、存储、网络等方面进行资源耗尽型攻击。在集群外部或 pod
内都有相应的工具或方法读者可自行搜索。

在集群层面的 DOS 攻击主要可以利用 K8S 集群的软件漏洞如 CVE-2019-11253、CVE-2019-9512、CVE-2019-9514
等。

4. 攻击点7容器逃逸

在云攻防中拿到容器/ pod 的 shell 往往只是攻击成功的第一步因为容器本质上就是 Linux 中的一个进程但是因为受到了 Namespace
和 Cgroup
等机制的诸多限制导致容器内的进程权限是非常低的容器逃逸就是为了突破这些限制所以其实容器逃逸也可以认为是一种提权。导致容器逃逸的原因总结起来可分为如下三类容器不安全配置相关组件漏洞和内核漏洞。

1容器不安全配置

容器不安全配置分为两种情况第一种情况是赋予了容器危险权限第二种情况是容器挂载了危险目录。具体如表2所示

类别

不安全配置

—|—

危险权限

特权容器

cap_sys_admin

cap_dac_read_search

cap_sys_module

cap_sys_ptrace && --pid=host

危险挂载

挂载docker.sock

挂载procfs

挂载/、/root、/etc等文件目录

以rw方式挂载lxcfs

pod挂载/var/log

表2-容器不安全配置

危险权限指的是 privileged 权限特权容器和危险的Capabilities 权限如
cap_sys_admincap_sys_modulecap_sys_dac_search
等这些都可以在容器启动时通过启动参数设置。如前文所述容器本质上是一个受限的进程除了通过 Namespace 和
Cgroup限制了命名空间和资源外还有 Capabilities、Apparmor、Seccomp
等安全机制限制了容器内进程的权限如果容器被赋予了以上的危险权限相当于限制容器的安全机制被打破这就给攻击者打开了方便之门。

容器挂载危险目录会导致容器文件系统隔离被打破进而获得特权。比如如果挂载了 /var/run/docker.sock那么在容器内就能与 docker
守护进程通信攻击者就可以创建一个特权容器然后逃逸。

这里提到的是容器逃逸攻击手法中最常见的一些不安全配置此外 CIS Docker Benchmark[3] 针对 docker
容器提出的安全配置基准多达上百条如此多的安全配置要求也导致了相比于漏洞防护安全配置的问题往往更容易被忽略。而对攻击者而言容器的不安全配置往往比下文将要提到的相关程序漏洞和内核漏洞更容易检测和利用。

2相关组件漏洞

容器集群环境中包含了非常多的组件程序它们相互协作共同构成了庞大的容器服务生态这些组件包括但不仅限于
runc、containerd、docker、kubelet
等。任何程序都会有漏洞容器相关的组件程序也不例外但是这些漏洞和容器不安全配置相比大多数利用起来都比较困难例如 CVE-2019-5736
就需要宿主机和容器交互才会触发而且该漏洞是 “一次性使用” 的并且容易暴露因为它会破坏 runc。

表3 总结了一些相关组件的常见漏洞

组件

漏洞

—|—

runc

CVE-2019-5736

CVE-2019-16884

CVE-2021-30465

containerd

CVE-2020-15257

CVE-2022-23648

CRI-O