Kubernetes Enumeration
Токени Kubernetes
Якщо у вас є компрометований доступ до машини, користувач може мати доступ до деякої платформи Kubernetes. Токен зазвичай знаходиться в файлі, на який вказує змінна середовища KUBECONFIG
або всередині ~/.kube
.
У цій папці ви можете знайти файли конфігурації з токенами та налаштуваннями для підключення до сервера API. Також у цій папці можна знайти папку кешу з інформацією, яка була отримана раніше.
Якщо ви компрометували підпроцес всередині середовища Kubernetes, є інші місця, де ви можете знайти токени та інформацію про поточне середовище K8:
Токени облікових записів служб
Перш ніж продовжувати, якщо ви не знаєте, що таке служба в Kubernetes, я б рекомендував вам перейти за цим посиланням і прочитати принаймні інформацію про архітектуру Kubernetes.
Взято з документації Kubernetes:
«Коли ви створюєте підпроцес, якщо ви не вказуєте обліковий запис служби, він автоматично призначається обліковий запис за замовчуванням в тому ж просторі імен».
Обліковий запис служби - це об'єкт, керований Kubernetes і використовується для надання ідентичності процесам, які працюють у підпроцесі. У кожного облікового запису є секрет, пов'язаний з ним, і цей секрет містить токен носія. Це JSON Web Token (JWT), метод представлення претензій безпечно між двома сторонами.
Зазвичай один з каталогів:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
/secrets/kubernetes.io/serviceaccount
містять файли:
ca.crt: Це сертифікат ca для перевірки зв'язків Kubernetes
namespace: Вказує поточний простір імен
token: Містить службовий токен поточного підпроцесу.
Тепер, коли у вас є токен, ви можете знайти сервер API всередині змінної середовища KUBECONFIG
. Для отримання додаткової інформації виконайте (env | set) | grep -i "kuber|kube
"
Токен облікового запису служби підписується ключем, який знаходиться у файлі sa.key і перевіряється за допомогою sa.pub.
Місце за замовчуванням на Kubernetes:
/etc/kubernetes/pki
Місце за замовчуванням на Minikube:
/var/lib/localkube/certs
Гарячі підпроцеси
Гарячі підпроцеси - це підпроцеси, які містять привілейований токен облікового запису служби. Привілейований токен облікового запису служби - це токен, який має дозвіл на виконання привілейованих завдань, таких як перелік секретів, створення підпроцесів тощо.
RBAC
Якщо ви не знаєте, що таке RBAC, прочитайте цей розділ.
Шпаргалка з переліку
Для переліку середовища K8s вам потрібно кілька речей:
Дійсний аутентифікаційний токен. У попередньому розділі ми побачили, де шукати токен користувача та токен облікового запису служби.
Адреса (https://host:port) сервера API Kubernetes. Зазвичай це можна знайти у змінних середовища та/або у файлі конфігурації kube.
Необов'язково: ca.crt для перевірки сервера API. Це можна знайти в тих же місцях, де можна знайти токен. Це корисно для перевірки сертифіката сервера API, але використовуючи
--insecure-skip-tls-verify
зkubectl
або-k
зcurl
, вам цього не знадобиться.
З цими даними ви можете перелічити Kubernetes. Якщо API з якоїсь причини доступне через Інтернет, ви можете просто завантажити цю інформацію та перелічити платформу з вашого хоста.
Однак зазвичай сервер API знаходиться всередині внутрішньої мережі, тому вам потрібно буде створити тунель через компрометовану машину, щоб отримати до нього доступ з вашої машини, або ви можете завантажити kubectl бінарний файл, або використовувати curl/wget/anything
для виконання сирого HTTP-запитів до сервера API.
Відмінності між дієсловами list
та get
list
та get
З дозволами get
ви можете отримати доступ до інформації про конкретні активи (опція describe
в kubectl
) API:
Якщо у вас є дозвіл list
, ви можете виконувати запити API для переліку типу активу (опція _
get_ у
kubectl`):
Якщо у вас є дозвіл watch
, ви можете виконувати запити API для моніторингу активів:
Вони відкривають потікове з'єднання, яке повертає вам повний маніфест Розгортання кожного разу, коли він змінюється (або коли створюється новий).
Наступні команди kubectl
показують лише, як перелічити об'єкти. Якщо ви хочете отримати доступ до даних, вам потрібно використовувати describe
замість get
Використання curl
Зсередини кінцевої точки ви можете використовувати кілька змінних середовища:
За замовчуванням под може отримати доступ до сервера kube-api за доменною назвою kubernetes.default.svc
, і ви можете побачити мережу kube в /etc/resolv.config
, оскільки тут ви знайдете адресу сервера DNS Kubernetes (".1" того ж діапазону - це кінцева точка kube-api).
Використання kubectl
Маючи токен та адресу сервера API, ви можете використовувати kubectl або curl для доступу до нього, як показано тут:
За замовчуванням, APISERVER спілкується за схемою https://
.
якщо в URL немає
https://
, ви можете отримати помилку, подібну до недопустимого запиту.
Ви можете знайти офіційний шпаргалку kubectl тут. Метою наступних розділів є представлення у впорядкованому вигляді різних параметрів для переліку та розуміння нового K8s, до якого ви маєте доступ.
Щоб знайти HTTP-запит, який відправляє kubectl
, ви можете використовувати параметр -v=8
MitM kubectl - Проксіювання kubectl
Поточна конфігурація
Якщо вам вдалося вкрасти облікові дані деяких користувачів, ви можете налаштувати їх локально, використовуючи щось на зразок:
Отримання підтримуваних ресурсів
З цією інформацією ви будете знати всі служби, які можна перелічити
Отримання Поточних Привілеїв
Ще один спосіб перевірити ваші привілеї - використовуючи інструмент: https://github.com/corneliusweig/rakkess****
Ви можете дізнатися більше про Kubernetes RBAC в:
pageKubernetes Role-Based Access Control(RBAC)Як тільки ви дізнаєтеся, які привілеї у вас є, перевірте наступну сторінку, щоб з'ясувати, чи можете ви їх зловживати для підвищення привілеїв:
pageAbusing Roles/ClusterRoles in KubernetesОтримати інші ролі
## Пошук API-сервера
Перевірте, чи доступний API-сервер Kubernetes за допомогою
kubectl
:Використовуйте
kubectl
для взаємодії з API-сервером:Використовуйте
kubeadm
для взаємодії з API-сервером:Перевірте, чи доступний API-сервер Kubernetes за допомогою
nmap
:Використовуйте
kubelet
для взаємодії з API-сервером:
Пошук API-об'єктів
Використовуйте
kubectl
для переліку доступних API-об'єктів:Використовуйте
kubectl
для отримання детальноє інформації про API-об'єкт:Використовуйте
kubectl
для отримання списку всіх об'єктів певного типу:Використовуйте
kubectl
для отримання детальноє інформації про конкретний об'єкт:Використовуйте
kubectl
для отримання YAML-представлення об'єкта:Використовуйте
kubectl
для виконання команд всередині контейнера:
Отримати простори імен
Kubernetes підтримує кілька віртуальних кластерів, що базуються на одному фізичному кластері. Ці віртуальні кластери називаються просторами імен.
Пошук API-серверів
Використовуйте
kubectl
для взаємодії з кластером Kubernetes.Виконайте наступну команду, щоб отримати список всіх доступних сервісів:
Перевірте кожен сервіс, щоб знайти можливі API-сервери.
Взаємодія з API-серверами
Використовуйте
kubectl proxy
, щоб створити локальний проксі-сервер для взаємодії з API-серверами.Відкрийте веб-браузер і перейдіть за посиланням
http://localhost:8001
.
Використання kubectx
та kubens
kubectx
та kubens
Встановіть утиліту
kubectx
таkubens
для швидкого перемикання між кластерами та просторами імен.Використовуйте їх для зручної навігації та роботи з Kubernetes кластерами.
Пошук відкритих портів
Використовуйте утиліту
nmap
, щоб сканувати кластер на відкриті порти.Запустіть наступну команду для сканування портів усіх вузлів кластера:
Аналізуйте результати, щоб знайти можливі вразливості або служби.
Пошук відкритих сервісів
Використовуйте утиліту
kube-hunter
, щоб знайти вразливості в Kubernetes кластері.Запустіть наступну команду для сканування кластера:
Аналізуйте результати, щоб виявити можливі проблеми безпеки.
Пошук конфігураційних файлів
Перевірте кластер на наявність витоку конфігураційних файлів.
Шукайте файли типу
kubeconfig
, які можуть містити конфіденційну інформацію.
Використання kubesec
kubesec
Встановіть утиліту
kubesec
, щоб аналізувати та оцінювати конфігурації Kubernetes.Запустіть наступну команду для аналізу конфігураційного файлу:
Оцініть результати, щоб виявити можливі проблеми безпеки.
Пошук вразливостей
Використовуйте утиліту
kube-bench
, щоб перевірити кластер на відповідність рекомендаціям безпеки.Запустіть наступну команду для аналізу безпеки кластера:
Аналізуйте результати, щоб виявити можливі вразливості та вдосконалити безпеку.
Отримання секретів
Отримати Поди
Поди - це фактичні контейнери, які будуть запущені.
Отримати сервіси
Сервіси Kubernetes використовуються для викладення сервісу на конкретному порту та IP-адресі (який буде виступати як балансувальник навантаження для капсул, які фактично пропонують сервіс). Це цікаво знати, де можна знайти інші сервіси для спроби атаки.
Отримати вузли
Отримати всі вузли, налаштовані всередині кластера.
Пошук API-сервера
Використовуйте
kubectl
для взаємодії з API-сервером:Перевірте конфігураційні файли
kubelet
:Перевірте сертифікати API-сервера:
Перевірте конфігураційні файли
kube-apiserver
:Перевірте доступність API-сервера:
Використовуйте
kubeadm
для отримання інформації про API-сервер:Перевірте конфігураційні файли
kube-proxy
:Перевірте конфігураційні файли
kube-controller-manager
:Перевірте конфігураційні файли
kube-scheduler
:Перевірте конфігураційні файли
etcd
:Перевірте конфігураційні файли
kubelet
:Перевірте конфігураційні файли
kube-proxy
:Перевірте конфігураційні файли
coredns
:Перевірте конфігураційні файли
kube-flannel
:Перевірте конфігураційні файли
calico
:Перевірте конфігураційні файли
weave-net
:Перевірте конфігураційні файли
kube-apiserver
:Перевірте конфігураційні файли
kube-controller-manager
:Перевірте конфігураційні файли
kube-scheduler
:Перевірте конфігураційні файли
etcd
:Перевірте конфігураційні файли
kubelet
:Перевірте конфігураційні файли
kube-proxy
:Перевірте конфігураційні файли
coredns
:Перевірте конфігураційні файли
kube-flannel
:Перевірте конфігураційні файли
calico
:Перевірте конфігураційні файли
weave-net
:
Отримати DaemonSets
DaeamonSets дозволяє забезпечити те, що конкретний підпроцес працює на всіх вузлах кластера (або на вибраних). Якщо ви видалите DaemonSet, керовані ним підпроцеси також будуть видалені.
Отримати cronjob
Cron-завдання дозволяє планувати запуск капсули, яка виконає певну дію.
Пошук API-сервера
Перевірте, чи доступний API-сервер Kubernetes за допомогою
kubectl
:
Перевірте, чи доступний API-сервер Kubernetes за допомогою
curl
:
Використовуйте
kubetcl
для взаємодії з API-сервером:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі та отримання доступу до ресурсів:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі та виконання запитів:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі та виконання команд у контейнері:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі та виконання команд у контейнері з виведенням результатів:
Використовуйте
kubetcl
для взаємодії з API-сервером через проксі та виконання команд у контейнері з виведенням результатів у реальному часі:
Отримати configMap
configMap завжди містить багато інформації та конфігураційний файл, який надає додаткам, які працюють в Kubernetes. Зазвичай ви можете знайти багато паролів, секретів, токенів, які використовуються для підключення та перевірки до інших внутрішніх/зовнішніх служб.
Отримати "все"
Отримання використання ресурсів Pods
Втеча з контейнера
Якщо ви можете створювати нові контейнери, ви, можливо, зможете втекти з них на вузол. Для цього вам потрібно створити новий контейнер, використовуючи файл yaml, переключитися на створений контейнер, а потім використати chroot для входу в систему вузла. Ви можете використовувати вже існуючі контейнери як посилання для файлу yaml, оскільки вони відображають існуючі зображення та шляхи.
якщо вам потрібно створити pod на конкретному вузлі, ви можете використати наступну команду, щоб отримати мітки на вузлі
k get nodes --show-labels
Зазвичай, kubernetes.io/hostname та node-role.kubernetes.io/master - це всі гарні мітки для вибору.
Потім ви створюєте свій файл attack.yaml
Після цього ви створюєте pod
Тепер ви можете переключитися до створеного поду наступним чином
І, нарешті, ви виконуєте chroot в систему вузла
Інформація отримана з: Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1
Посилання
Last updated