Abusing Roles/ClusterRoles in Kubernetes
Вивчайте та вправляйтеся в хакінгу AWS: Школа хакінгу HackTricks AWS Red Team Expert (ARTE)
Вивчайте та вправляйтеся в хакінгу GCP:
Школа хакінгу HackTricks GCP Red Team Expert (GRTE)
Тут ви можете знайти деякі потенційно небезпечні конфігурації Ролей та Кластерних Ролей.
Пам'ятайте, що ви можете отримати всі підтримувані ресурси за допомогою kubectl api-resources
Підвищення привілеїв
Називаючи це мистецтвом отримання доступу до іншого принципала в межах кластера з іншими привілеями (в межах кластера Kubernetes або до зовнішніх хмар), в Kubernetes існує в основному 4 основні техніки підвищення привілеїв:
Мати можливість імперсонувати інших користувачів/групи/СА з кращими привілеями в межах кластера Kubernetes або до зовнішніх хмар
Мати можливість створювати/змінювати/виконувати контейнери де ви можете знайти або приєднати СА з кращими привілеями в межах кластера Kubernetes або до зовнішніх хмар
Мати можливість читати секрети, оскільки токени СА зберігаються як секрети
Мати можливість вибратися на вузол з контейнера, де ви можете вкрасти всі секрети контейнерів, що працюють на вузлі, облікові дані вузла та дозволи вузла в межах хмари, в якій він працює (якщо такі є)
П'ята техніка, яка заслуговує на згадку, - це можливість запустити перенаправлення портів в контейнері, оскільки ви можете мати доступ до цікавих ресурсів в цьому контейнері.
Доступ до будь-якого ресурсу або дії (Зірочка)
Зірочка (*) надає дозвіл на будь-який ресурс з будь-якою дією. Використовується адміністраторами. У межах Кластерної Ролі це означає, що зловмисник може зловживати будь-яким простором імен в кластері.
Отримання доступу до будь-якого ресурсу з конкретним дієсловом
У RBAC деякі дозволи становлять значний ризик:
create
: Надає можливість створювати будь-який кластерний ресурс, загрожуючи ескалацією привілеїв.list
: Дозволяє перелік усіх ресурсів, що потенційно може витікати конфіденційні дані.get
: Дозволяє отримання доступу до секретів від облікових записів служб, що становить загрозу безпеці.
Створення Pod - Крадіжка токену
Зловмисник з дозволом на створення pod може додати привілейований обліковий запис служби в pod і вкрасти токен для імітації облікового запису служби. Ефективно підвищуючи привілеї до нього
Приклад pod, який вкраде токен облікового запису служби bootstrap-signer
і надішле його зловмиснику:
Створення та втеча з Pod
Наступне вказує на всі привілеї, які може мати контейнер:
Привілейований доступ (вимкнення захисту та встановлення можливостей)
Вимкнення просторів імен hostIPC та hostPid, що може допомогти у підвищенні привілеїв
Вимкнення простору імен hostNetwork, що дає доступ до викрадення привілеїв хмарних вузлів та кращий доступ до мереж
Підключення /etc/ хостів всередині контейнера
Створіть pod з:
Однорядковий коментар з цього твіту з деякими додатками:
Тепер, коли ви можете втекти до вузла, перевірте техніки пост-експлуатації в:
Прихованість
Ймовірно, вам захочеться бути прихованішим, на наступних сторінках ви можете побачити, до чого ви зможете отримати доступ, якщо створите капсулу, увімкнувши лише деякі з вказаних привілеїв у попередньому шаблоні:
Привілейований + hostPID
Лише привілейований
hostPath
hostPID
hostNetwork
hostIPC
Ви можете знайти приклад того, як створити/зловживати попередніми конфігураціями привілейованих капсул у https://github.com/BishopFox/badPods
Створення капсули - Перехід до хмари
Якщо ви можете створити капсулу (і, за бажанням, обліковий запис служби), ви, можливо, зможете отримати привілеї в хмарному середовищі, призначивши хмарні ролі капсулі або обліковому запису служби, а потім отримати до них доступ. Більше технічної інформації дивіться:
Pod Escape PrivilegesСтворення/Зміна розгортання, Демонічні набори, Набори зі станом, Контролери реплікації, Набори реплік, Завдання та Регулярні завдання
Можливо використовувати ці дозволи для створення нової капсули та встановлення привілеїв, як у попередньому прикладі.
Наступний yaml створює демонічний набір та виводить токен облікового запису служби всередині капсули:
Виконання Pods
pods/exec
- це ресурс в Kubernetes, який використовується для виконання команд в оболонці всередині пода. Це дозволяє виконувати команди всередині контейнерів або отримувати оболонку всередині.
Отже, можливо потрапити всередину пода та вкрасти токен SA, або потрапити в привілейований под, втекти на вузол та вкрасти всі токени подів на вузлі та (зловживати) вузол:
port-forward
Ця дозвіл дозволяє перенаправити один локальний порт на один порт у вказаному котейнері. Це призначено для можливості легко відлагоджувати додатки, що працюють всередині котейнера, але зловмисник може зловживати цим, щоб отримати доступ до цікавих (наприклад, БД) або вразливих додатків (веб?) всередині котейнера:
Запис на хостах /var/log/ Escape
Як вказано в цьому дослідженні, якщо ви можете отримати доступ або створити pod з монтуванням каталогу хостів /var/log/
, ви можете вийти з контейнера.
Це в основному тому, що коли Kube-API намагається отримати журнали контейнера (використовуючи kubectl logs <pod>
), він запитує файл 0.log
pod за допомогою кінцевої точки /logs/
сервісу Kubelet.
Сервіс Kubelet викриває кінцеву точку /logs/
, яка в основному просто викриває файлову систему /var/log
контейнера.
Отже, зловмисник з доступом до запису в каталозі /var/log/ контейнера може зловживати цими поведінками двома способами:
Зміна файлу
0.log
свого контейнера (зазвичай розташованого в/var/logs/pods/namespace_pod_uid/container/0.log
) на символічне посилання, що вказує на/etc/shadow
, наприклад. Потім ви зможете витягти файл тіні господарів, виконавши:
Якщо зловмисник контролює будь-якого принципала з дозволами на читання
nodes/log
, він може просто створити символічне посилання в/host-mounted/var/log/sym
на/
і коли звертається доhttps://<gateway>:10250/logs/sym/
, він перегляне кореневу файлову систему хостів (зміна символічного посилання може надати доступ до файлів).
Лабораторія та автоматизований експлойт можуть бути знайдені за посиланням https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts
Обхід захисту від запису
Якщо ви маєте достатньо щастя та високопривілейовану можливість CAP_SYS_ADMIN
, ви можете просто повторно монтувати папку як rw:
Обхід захисту hostPath readOnly
Як зазначено в цьому дослідженні, можливо обійти захист:
Що мало запобігти втечам, подібним попереднім, шляхом використання PersistentVolume та PersistentVolumeClaim для монтування папки хоста в контейнері з можливістю запису замість використання монтування hostPath.
Імітація привілейованих облікових записів
За допомогою привілею імітації користувача, зловмисник може імітувати привілейований обліковий запис.
Просто використовуйте параметр --as=<username>
у команді kubectl
для імітації користувача або --as-group=<group>
для імітації групи:
Або скористайтеся REST API:
Перелік секретів
Дозвіл на перегляд секретів може дозволити зловмиснику фактично прочитати секрети, отримуючи доступ до кінцевої точки REST API:
Читання секрету - перебір ідентифікаторів токенів
Хоча для атакуючого, який має токен з дозволами на читання, потрібне точне ім'я секрету для його використання, на відміну від ширшого привілею переліку секретів, все ще існують вразливості. Стандартні облікові записи служб у системі можуть бути перелічені, кожен з них пов'язаний з секретом. Ці секрети мають структуру імені: статичний префікс, за яким слідує випадковий п'ятизначний алфавітно-цифровий токен (за винятком певних символів) згідно з вихідним кодом.
Токен генерується з обмеженого набору з 27 символів (bcdfghjklmnpqrstvwxz2456789
), а не з повного алфавітно-цифрового діапазону. Це обмеження зменшує загальну кількість можливих комбінацій до 14,348,907 (27^5). Відповідно, атакуючий може виконати атаку методом перебору для визначення токену за кілька годин, що потенційно може призвести до підвищення привілеїв шляхом доступу до чутливих облікових записів служб.
Запити на підпис сертифікатів
Якщо у вас є дієслова create
у ресурсі certificatesigningrequests
(або принаймні у certificatesigningrequests/nodeClient
). Ви можете створити новий CeSR для нового вузла.
Згідно з документацією, ці запити можна автоматично схвалити, тому в цьому випадку вам не потрібні додаткові дозволи. Якщо ні, вам потрібно мати можливість схвалити запит, що означає оновлення в certificatesigningrequests/approval
та approve
в signers
з resourceName <signerNameDomain>/<signerNamePath>
або <signerNameDomain>/*
Приклад ролі з усіма необхідними дозволами:
Отже, з новим затвердженим запитом CSR вузла ви можете зловживати спеціальними дозволами вузлів, щоб вкрасти секрети та підвищити привілеї.
У цьому пості та цьому конфігурація GKE K8s TLS Bootstrap налаштована з автоматичним підписанням та використовується для генерації облікових даних нового вузла K8s, а потім використовується для підвищення привілеїв шляхом крадіжки секретів. Якщо у вас є згадані привілеї, ви можете зробити те саме. Зверніть увагу, що перший приклад обходить помилку, яка перешкоджає новому вузлу отримати доступ до секретів всередині контейнерів, оскільки вузол може отримати доступ лише до секретів контейнерів, змонтованих на ньому.
Шляхом обходу цього просто створіть облікові дані вузла для імені вузла, на якому змонтований контейнер з цікавими секретами (але просто перевірте, як це зробити у першому пості):
AWS EKS aws-auth конфігураційні карти
Суб'єкти, які можуть змінювати configmaps
в просторі імен kube-system на кластерах EKS (повинні бути в AWS), можуть отримати привілеї адміністратора кластера, перезаписавши конфігураційну карту aws-auth.
Дієслова, які потрібні: update
та patch
, або create
, якщо конфігураційна карта не була створена:
Ви можете використовувати aws-auth
для постійності, щоб надати доступ користувачам з інших облікових записів.
Однак aws --profile other_account eks update-kubeconfig --name <cluster-name>
не працює з іншого облікового запису. Але фактично aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing
працює, якщо ви вказуєте ARN кластера замість просто назви.
Щоб зробити kubectl
працюючим, просто переконайтеся, що налаштовано kubeconfig жертви і в аргументах виконання aws додайте --profile other_account_role
, щоб kubectl використовував профіль іншого облікового запису для отримання токена та зв'язку з AWS.
Ескалація в GKE
Є 2 способи призначення дозволів K8s для принципалів GCP. У будь-якому випадку принципалу також потрібно мати дозвіл container.clusters.get
, щоб мати можливість збирати облікові дані для доступу до кластера, або вам потрібно створити власний файл конфігурації kubectl (див. наступне посилання).
Під час спілкування з кінцевою точкою API K8s буде відправлено токен автентифікації GCP. Потім GCP, через кінцеву точку API K8s, спочатку перевірить, чи має принципал (за електронною поштою) який-небудь доступ всередині кластера, після чого він перевірить, чи має він який-небудь доступ через GCP IAM. Якщо будь-яке з цього правдиве, він буде відповідати. Якщо ні, буде надана помилка, яка вказує на необхідність надання дозволів через GCP IAM.
Отже, перший метод полягає в використанні GCP IAM, дозволи K8s мають свої еквівалентні дозволи GCP IAM, і якщо у принципала є ці дозволи, він зможе їх використовувати.
GCP - Container PrivescДругий метод полягає в призначенні дозволів K8s всередині кластера для ідентифікації користувача за його електронною поштою (включаючи облікові записи служб GCP).
Створення токенів службових облікових записів
Принципали, які можуть створювати запити на токени (serviceaccounts/token
) Під час спілкування з кінцевою точкою API K8s SAs (інформація з тут).
ephemeralcontainers
Принципали, які можуть оновлювати
або змінювати
pods/ephemeralcontainers
, можуть отримати виконання коду на інших підках, і, можливо, вийти за межі до їх вузла, додавши ефемерний контейнер з привілейованим securityContext
ValidatingWebhookConfigurations або MutatingWebhookConfigurations
Принципали з будь-якими дієсловами create
, update
або patch
над validatingwebhookconfigurations
або mutatingwebhookconfigurations
можуть створити одну з таких webhookconfigurations, щоб мати можливість ескалювати привілеї.
Для прикладу mutatingwebhookconfigurations
перевірте цей розділ цього поста.
Ескалація
Як ви можете прочитати в наступному розділі: Запобігання вбудованій привілейованій ескалації, принципал не може оновлювати або створювати ролі або clusterroles без наявності у нього цих нових дозволів. Крім того, якщо він має дієслово escalate
над roles
або clusterroles
.
Тоді він може оновлювати/створювати нові ролі, clusterroles з кращими дозволами, ніж ті, які в нього є.
Проксі вузлів
Принципали з доступом до підресурсу nodes/proxy
можуть виконати код на підках через API Kubelet (згідно з цим). Додаткова інформація про аутентифікацію Kubelet на цій сторінці:
У вас є приклад того, як отримати RCE, спілкуючись з авторизованим до API Kubelet тут.
Видалення підок + вузли, що не підлягають плануванню
Принципали, які можуть видаляти підки (дієслово delete
над ресурсом pods
), або виводити підки (дієслово create
над ресурсом pods/eviction
), або змінювати статус підка (доступ до pods/status
) і можуть робити інші вузли неплановими (доступ до nodes/status
) або видаляти вузли (дієслово delete
над ресурсом nodes
) і мають контроль над підком, можуть викрасти підки з інших вузлів, щоб вони виконувалися в компрометованому вузлі, і зловмисник може вкрасти токени з цих підок.
Статус сервісів (CVE-2020-8554)
Принципали, які можуть змінювати services/status
, можуть встановити поле status.loadBalancer.ingress.ip
для зловживання невиправленою CVE-2020-8554 та запуску атак типу MiTM проти кластера. Більшість заходів для запобігання CVE-2020-8554 лише унеможливлюють зовнішні служби ExternalIP (згідно з цим).
Статус вузлів та капсул
Принципали з дозволами update
або patch
над nodes/status
або pods/status
, можуть змінювати мітки для впливу на обмеження планування.
Вбудоване запобігання підвищенню привілеїв
У Kubernetes є вбудований механізм для запобігання підвищенню привілеїв.
Ця система забезпечує, що користувачі не можуть підвищувати свої привілеї, змінюючи ролі або зв'язки ролей. Застосування цього правила відбувається на рівні API, забезпечуючи захист навіть у випадку неактивного авторизатора RBAC.
Правило передбачає, що користувач може створювати або оновлювати роль лише у випадку, якщо він має всі дозволи, які включає ця роль. Більше того, обсяг існуючих дозволів користувача повинен відповідати обсягу ролі, яку він намагається створити або змінити: або на рівні кластера для ClusterRoles, або обмежений тією ж просторовою областю (або на рівні кластера) для Roles.
Є виняток з попереднього правила. Якщо принципал має дієслово escalate
над roles
або clusterroles
, він може підвищити привілеї ролей та кластерних ролей навіть без наявних у нього дозволів.
Отримання та оновлення RoleBindings/ClusterRoleBindings
Здається, що ця техніка працювала раніше, але за моїми тестами вона більше не працює з тієї ж причини, що пояснено в попередньому розділі. Ви не можете створити/змінити rolebinding, щоб надати собі або іншому SA деякі привілеї, якщо у вас їх вже немає.
Привілегія створення Rolebindings дозволяє користувачеві прив'язувати ролі до облікового запису служби. Ця привілегія потенційно може призвести до підвищення привілеїв, оскільки вона дозволяє користувачеві прив'язувати адміністративні привілеї до компрометованого облікового запису служби.
Інші атаки
Додаток бічного проксі
За замовчуванням в комунікації між капсулами немає жодного шифрування. Взаємна аутентифікація, двостороння, від капсули до капсули.
Створення додатку бічного проксі
Створіть свій .yaml
Відредагуйте свій .yaml файл та додайте розкоментовані рядки:
Перегляньте логи проксі:
Додаткова інформація за посиланням: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Зловмисний контролер прийому
Контролер прийому перехоплює запити до сервера API Kubernetes перед збереженням об'єкта, але після того, як запит був аутентифікований та авторизований.
Якщо зловмисник якимось чином вдасться впровадити контролер прийому мутацій, він зможе змінювати вже аутентифіковані запити. Це може дозволити йому піднятися в привілеях та, як правило, залишитися в кластері.
Приклад з https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Перевірте статус, щоб переконатися, що він готовий:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1628433436353%2FyHUvUWugR.png%3Fauto%3Dcompress%2Cformat%26format%3Dwebp&width=768&dpr=4&quality=100&sign=fe4bc7c0&sv=1)
Потім розгорнути новий котик:
Коли ви бачите помилку ErrImagePull
, перевірте назву зображення за допомогою будь-якого з наступних запитів:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1628433512073%2FleFXtgSzm.png%3Fauto%3Dcompress%2Cformat%26format%3Dwebp&width=768&dpr=4&quality=100&sign=45a94e54&sv=1)
Як ви можете побачити на зазначеному зображенні, ми спробували запустити образ nginx
, але фінальним виконаним образом є rewanthtammana/malicious-image
. Що тільки що сталося !!?
Технічні деталі
Сценарій ./deploy.sh
встановлює контролер прийому мутаційних веб-запитів, який змінює запити до API Kubernetes, як вказано в рядках його конфігурації, впливаючи на спостережувані результати:
Зловживання ролями та кластерними ролями в Kubernetes
Вищезазначений уривок замінює зображення першого контейнера в кожному котейнері на rewanthtammana/malicious-image
.
Обхід OPA Gatekeeper
https://github.com/HackTricks-wiki/hacktricks-cloud/blob/ua/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.mdНайкращі практики
Вимкнення автоматичного монтування токенів облікового запису служби
Котейнери та облікові записи служб: За замовчуванням котейнери монтуватимуть токен облікового запису служби. Для підвищення безпеки Kubernetes дозволяє вимкнення цієї функції автоматичного монтування.
Як застосувати: Встановіть
automountServiceAccountToken: false
в конфігурації облікових записів служби або котейнерів, починаючи з версії Kubernetes 1.6.
Обмеження призначення користувачів у RoleBindings/ClusterRoleBindings
Селективне включення: Переконайтеся, що в RoleBindings або ClusterRoleBindings включені лише необхідні користувачі. Регулярно аудитуйте та видаляйте непотрібних користувачів для збереження жорсткої безпеки.
Ролі, специфічні для простору імен, над кластерними ролями
Ролі проти Кластерних ролей: Віддавайте перевагу використанню Ролей та RoleBindings для дозволів, специфічних для простору імен, а не Кластерних ролей та ClusterRoleBindings, які застосовуються на рівні кластера. Цей підхід пропонує більш дрібний контроль та обмежує обсяг дозволів.
Використання автоматизованих інструментів
Посилання
Вивчайте та практикуйте взлом AWS:Навчання HackTricks AWS Red Team Expert (ARTE)
Вивчайте та практикуйте взлом GCP:
Навчання HackTricks GCP Red Team Expert (GRTE)
Last updated