AWS - EKS Post Exploitation

Support HackTricks

EKS

Für weitere Informationen siehe

Enumerieren Sie den Cluster über die AWS-Konsole

Wenn Sie die Berechtigung eks:AccessKubernetesApi haben, können Sie Kubernetes-Objekte über die AWS EKS-Konsole anzeigen (Erfahren Sie mehr).

Verbinden Sie sich mit dem AWS Kubernetes-Cluster

  • Einfache Methode:

# Generate kubeconfig
aws eks update-kubeconfig --name aws-eks-dev
  • Nicht so einfacher Weg:

Wenn Sie ein Token erhalten können mit aws eks get-token --name <cluster_name>, aber keine Berechtigungen haben, um Cluster-Informationen abzurufen (describeCluster), könnten Sie Ihre eigene ~/.kube/config vorbereiten. Mit dem Token benötigen Sie jedoch immer noch den URL-Endpunkt, um sich zu verbinden (wenn Sie es geschafft haben, ein JWT-Token von einem Pod zu erhalten, lesen Sie hier) und den Namen des Clusters.

In meinem Fall habe ich die Informationen nicht in den CloudWatch-Protokollen gefunden, aber ich fand sie in den LaunchTemplates userData und in EC2-Maschinen in userData ebenfalls. Sie können diese Informationen in userData leicht sehen, zum Beispiel im nächsten Beispiel (der Clustername war cluster-name):

API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com

/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
kube config

```yaml describe-cache-parametersapiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com name: arn:aws:eks:us-east-1::cluster/ contexts: - context: cluster: arn:aws:eks:us-east-1::cluster/ user: arn:aws:eks:us-east-1::cluster/ name: arn:aws:eks:us-east-1::cluster/ current-context: arn:aws:eks:us-east-1::cluster/ kind: Config preferences: {} users: - name: arn:aws:eks:us-east-1::cluster/ user: exec: apiVersion: client.authentication.k8s.io/v1beta1 args: - --region - us-west-2 - --profile - - eks - get-token - --cluster-name - command: aws env: null interactiveMode: IfAvailable provideClusterInfo: false ```

Von AWS zu Kubernetes

Der Ersteller des EKS-Clusters wird IMMER in der Lage sein, in den Kubernetes-Cluster-Bereich der Gruppe system:masters (k8s-Admin) zu gelangen. Zum Zeitpunkt dieses Schreibens gibt es keinen direkten Weg, um herauszufinden, wer den Cluster erstellt hat (Sie können CloudTrail überprüfen). Und es gibt keinen Weg, um dieses Privileg zu entfernen.

Der Weg, um Zugriff auf K8s für weitere AWS IAM-Benutzer oder -Rollen zu gewähren, ist die Verwendung des Configmaps aws-auth.

Daher wird jeder mit Schreibzugriff auf die Config-Map aws-auth in der Lage sein, den gesamten Cluster zu kompromittieren.

Für weitere Informationen darüber, wie man zusätzliche Berechtigungen für IAM-Rollen & -Benutzer im gleichen oder unterschiedlichen Konto gewährt und wie man dies ausnutzen kann, privesc überprüfen Sie diese Seite.

Überprüfen Sie auch diesen großartigen Beitrag, um zu lernen, wie die Authentifizierung IAM -> Kubernetes funktioniert.

Von Kubernetes zu AWS

Es ist möglich, eine OpenID-Authentifizierung für Kubernetes-Dienstkonten zuzulassen, um ihnen zu ermöglichen, Rollen in AWS zu übernehmen. Erfahren Sie, wie das auf dieser Seite funktioniert.

GET Api Server-Endpunkt aus einem JWT-Token

https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
Habe keine Dokumentation gefunden, die die Kriterien für die 'zwei Zeichen' und die 'Zahl' erklärt. Aber bei eigenen Tests sehe ich, dass diese häufig vorkommen:

* gr7
* yl4

Jedenfalls sind es nur 3 Zeichen, die wir bruteforcen können. Verwende das folgende Skript, um die Liste zu generieren.
from itertools import product
from string import ascii_lowercase

letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
number_combinations = product('0123456789', repeat = 1)

result = [
f'{''.join(comb[0])}{comb[1][0]}'
for comb in product(letter_combinations, number_combinations)
]

with open('out.txt', 'w') as f:
f.write('\n'.join(result))

Dann mit wfuzz

wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com

Denken Sie daran, & zu ersetzen.

Umgehung von CloudTrail

Wenn ein Angreifer die Anmeldeinformationen eines AWS mit Berechtigungen über ein EKS erhält. Wenn der Angreifer seine eigene kubeconfig konfiguriert (ohne update-kubeconfig aufzurufen), wie zuvor erklärt, generiert get-token keine Protokolle in Cloudtrail, da es nicht mit der AWS API interagiert (es erstellt das Token nur lokal).

Wenn der Angreifer also mit dem EKS-Cluster kommuniziert, wird Cloudtrail nichts protokollieren, was mit dem gestohlenen Benutzer und dem Zugriff darauf zu tun hat.

Beachten Sie, dass der EKS-Cluster möglicherweise Protokolle aktiviert hat, die diesen Zugriff protokollieren (obwohl sie standardmäßig deaktiviert sind).

EKS Lösegeld?

Standardmäßig hat der Benutzer oder die Rolle, die einen Cluster erstellt hat, IMMER Administratorrechte über den Cluster. Und dass der einzige "sichere" Zugriff, den AWS über den Kubernetes-Cluster haben wird.

Wenn also ein Angreifer einen Cluster mit Fargate kompromittiert und alle anderen Administratoren entfernt und den AWS-Benutzer/die Rolle, die den Cluster erstellt hat, löscht, könnte der Angreifer den Cluster erpresst haben.

Beachten Sie, dass, wenn der Cluster EC2-VMs verwendet hat, es möglich sein könnte, Administratorrechte von dem Knoten zu erhalten und den Cluster wiederherzustellen.

Tatsächlich, wenn der Cluster Fargate verwendet, könnten Sie EC2-Knoten oder alles zu EC2 in den Cluster verschieben und ihn wiederherstellen, indem Sie auf die Tokens im Knoten zugreifen.

Unterstützen Sie HackTricks

Last updated