diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md index 4bdf2aa64..78c613528 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md @@ -4,28 +4,28 @@ ## EKS -Daha fazla bilgi için bakınız +Daha fazla bilgi için kontrol edin {{#ref}} ../../aws-services/aws-eks-enum.md {{#endref}} -### AWS Console üzerinden kümeyi listeleme +### AWS Console üzerinden cluster'ı enumerate et -Eğer **`eks:AccessKubernetesApi`** iznine sahipseniz, AWS EKS console üzerinden **view Kubernetes objects** gerçekleştirebilirsiniz. ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). +Eğer **`eks:AccessKubernetesApi`** iznine sahipseniz, AWS EKS console üzerinden **Kubernetes objects** görüntüleyebilirsiniz ([Daha fazla bilgi](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). -### AWS Kubernetes Cluster'a Bağlanma +### AWS Kubernetes Cluster'a bağlan -- Kolay yol: +- Easy way: ```bash # Generate kubeconfig aws eks update-kubeconfig --name aws-eks-dev ``` - O kadar kolay olmayan yol: -Eğer **get a token**'ı **`aws eks get-token --name `** ile alabiliyorsanız ama cluster bilgilerini almak için (describeCluster) izniniz yoksa, kendi **`~/.kube/config`** dosyanızı hazırlayabilirsiniz. Ancak tokena sahip olsanız bile bağlanmak için hâlâ **url endpoint to connect to** (eğer bir poddan JWT token almayı başardıysanız [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) okuyun) ve **name of the cluster**'a ihtiyacınız var. +Eğer **`aws eks get-token --name `** ile bir **token** alabiliyorsanız ancak cluster bilgilerini (describeCluster) alma yetkiniz yoksa, **kendi `~/.kube/config`** dosyanızı hazırlayabilirsiniz. Ancak tokena sahip olsanız bile, yine de bağlanmak için **url endpoint** gerekir (eğer bir pod’dan bir JWT token aldıysanız [buraya bakın](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) ve **cluster adı** gerekir. -Benim durumumda bilgiyi CloudWatch loglarında bulamadım, fakat **found it in LaunchTemaplates userData** ve **in EC2 machines in userData also** içinde buldum. Bu bilgiyi **userData** içinde kolayca görebilirsiniz, örneğin aşağıdaki örnekte (cluster adı cluster-name idi): +Benim durumumda, bilgiyi CloudWatch logs içinde bulamadım, ama **LaunchTemaplates userData** içinde ve **EC2 makinelerinde userData** içinde de **buldum**. Bu bilgiyi **userData** içinde kolayca görebilirsiniz, örneğin sonraki örnekte (cluster adı cluster-name idi): ```bash API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com @@ -33,7 +33,7 @@ API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazon ```
-kube yapılandırması +kube config ```yaml describe-cache-parametersapiVersion: v1 clusters: @@ -72,33 +72,53 @@ provideClusterInfo: false ### AWS'den Kubernetes'e -Bir **EKS cluster**'ı **oluşturan** kişi, Kubernetes kümesinin **`system:masters`** (k8s admin) grubuna **HER ZAMAN** erişebilecektir. Bu yazının yazıldığı tarihte kümeyi **kim oluşturduğunu** bulmak için **doğrudan bir yol yoktur** (kontrol için CloudTrail'e bakabilirsiniz). Ve bu **ayrcalığı kaldırmanın** **bir yolu yoktur**. +**EKS cluster**'ının **yaratıcısı**, **HER ZAMAN** grubun **`system:masters`** (k8s admin) içindeki kubernetes cluster bölümüne girebilecektir. Bu yazı hazırlanırken **kimin cluster'ı oluşturduğunu** bulmanın **doğrudan bir yolu yok**tur (CloudTrail'i kontrol edebilirsiniz). Ve bu **ayrıcalığı** **kaldırmanın** **hiçbir yolu yok**tur. -K8s'e daha fazla **AWS IAM users or roles** için erişim vermenin yolu **configmap** **`aws-auth`**'ı kullanmaktır. +#### configmap'i kötüye kullanma + +**AWS IAM** kullanıcılarına veya rollerine **K8s üzerinde daha fazla erişim** vermenin geleneksel yolu **configmap** **`aws-auth`** kullanmaktır. > [!WARNING] -> Bu nedenle, config map **`aws-auth`** üzerinde **yazma erişimine** sahip olan herkes **tüm kümeyi ele geçirebilir**. +> Bu nedenle, **`aws-auth`** config map'i üzerinde **yazma erişimi** olan herkes **tüm cluster'ı ele geçirebilir**. -Daha fazla bilgi için, **aynı veya farklı hesapta IAM roles & users’a ekstra ayrıcalıkların nasıl verileceği** ve bunun nasıl **suistimal edileceği** hakkında [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps). +Aynı veya farklı hesapta **IAM rollerine ve kullanıcılarına ek ayrıcalıklar** nasıl verilir ve bunu [**privesc için nasıl kötüye kullanacağınız**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) hakkında daha fazla bilgi için bu sayfaya bakın. -Ayrıca [ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **gönderisini, IAM -> Kubernetes kimlik doğrulamasının nasıl çalıştığını öğrenmek için inceleyin**. +Ayrıca **authentication IAM -> Kubernetes**'in nasıl çalıştığını öğrenmek için [**bu harika**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **yazıya** da göz atın. -### Kubernetes'ten AWS'e +#### Access Entries'i kötüye kullanma -**OpenID authentication for kubernetes service account**'a izin vererek onların AWS rollerini üstlenmelerini sağlamak mümkündür. Nasıl çalıştığını öğrenmek için [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1). +AWS, IAM kullanıcılarına Kubernetes cluster'a erişim vermek için Access Entries üzerinden ek bir yöntem uygular. `eks:CreateAccessEntry` ve `eks:AssociateAccessPolicy` izinlerine sahipseniz, kullanıcıya ya da belirli bir role bir Kubernetes administrator rolü de atayabilirsiniz. -### JWT Token'dan Api Server Endpoint Alma +İlk olarak, **kullanıcınız veya rolünüz için bir access entry oluşturun**: +``` +aws eks create-access-entry --cluster-name --region --principal-arn --type STANDARD +``` +Bu giriş oluşturulduktan sonra, artık ona doğrudan bir policy atayabilirsiniz. Doğrudan kullanılabilecek *AmazonEKSClusterAdminPolicy* adlı yerleşik bir AWS policy vardır. Ortamınızda EKS içinde yükseltilmiş ayrıcalıklar da veren başka custom policies varsa, `--policy-arn` değerini bunlardan herhangi biriyle değiştirebilirsiniz: +``` +aws eks associate-access-policy --cluster-name --region --principal-arn --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster +``` +AWS resmi dokümantasyonunda bu policy’i [**burada**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy) arayabilirsiniz -JWT token'ı decode ettiğimizde cluster id ve ayrıca bölge bilgisi elde ederiz. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URL'inin standart formatı şu şekildedir +Bu noktadan sonra, artık bir *k8s* token talep edip cluster ile bir administrator olarak etkileşime geçebiliyor olabilirsiniz: +``` +aws eks get-token --cluster-name --output json | jq -r '.status.token' +``` +### Kubernetes'ten AWS'ye + +**OpenID authentication for kubernetes service account**'ların AWS içinde rol assume etmesine izin vermek mümkündür. Bunun nasıl çalıştığını [**bu sayfada**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1) öğrenin. + +### JWT Token'dan GET Api Server Endpoint + +JWT token'ı decode ederek cluster id ve region bilgisini de elde ederiz. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS url için standart formatın şu olduğunu bilerek ```bash https://...eks.amazonaws.com ``` -'Two chars' ve 'number' için kriterleri açıklayan herhangi bir dokümantasyon bulamadım. Ancak kendi yaptığım bazı testlerde şu tekrarları görüyorum: +'two chars' ve 'number' için kriterleri açıklayan herhangi bir dokümantasyon bulamadım. Ama kendi adıma bazı testler yapınca bunların tekrar ettiğini gördüm: - gr7 - yl4 -Her neyse, bunlar sadece 3 karakter; bunları bruteforce edebiliriz. Listeyi oluşturmak için aşağıdaki script'i kullanın +Her halükarda bunlar sadece 3 char, bu yüzden bunları bruteforce edebiliriz. Listeyi oluşturmak için aşağıdaki scripti kullanın ```python from itertools import product from string import ascii_lowercase @@ -119,25 +139,25 @@ Sonra wfuzz ile wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com ``` > [!WARNING] -> Yerine & koymayı unutmayın . +> Remember to replace & . -### CloudTrail'ı Atlatma +### Bypass CloudTrail -Eğer bir attacker, **permission over an EKS** olan bir AWS kimlik bilgilerini elde ederse. Attacker daha önce açıklandığı gibi kendi **`kubeconfig`**'ini (**`update-kubeconfig`** çağırmadan) yapılandırırsa, **`get-token`** Cloudtrail'da log oluşturmaz çünkü AWS API ile etkileşime girmez (sadece token'ı yerel olarak oluşturur). +Eğer bir attacker, bir **EKS üzerinde yetkisi** olan bir AWS hesabının credentials bilgilerini elde ederse. Eğer attacker kendi **`kubeconfig`** dosyasını (**`update-kubeconfig`** çağırmadan) önceki açıklamada anlatıldığı gibi yapılandırırsa, **`get-token`** Cloudtrail’de log oluşturmaz çünkü AWS API ile etkileşime girmez (sadece token’ı yerel olarak oluşturur). -Bu nedenle attacker EKS cluster ile iletişim kurduğunda, **cloudtrail çalınan kullanıcı ve erişimiyle ilgili hiçbir şeyi loglamayacaktır**. +Bu nedenle attacker EKS cluster ile konuştuğunda, **cloudtrail çalınan user’ın erişimiyle ilgili hiçbir şeyi loglamayacaktır**. -Not: EKS cluster'ın bu erişimi loglayacak şekilde logları etkinleştirilmiş olabilir (varsayılan olarak devre dışı olmalarına rağmen). +**EKS cluster’ın logları etkin olabilir** ve bu erişimi loglayabilir (ancak varsayılan olarak devre dışıdırlar). ### EKS Ransom? -Varsayılan olarak bir cluster'ı oluşturan **user or role** her zaman cluster üzerinde **ALWAYS going to have admin privileges** olacaktır. Ve bu, AWS'nin Kubernetes cluster'ı üzerinde sahip olduğu tek "secure" erişimdir. +Varsayılan olarak, bir cluster’ı **oluşturan user veya role** cluster üzerinde **HER ZAMAN admin yetkilerine** sahip olacaktır. Ve AWS’nin Kubernetes cluster üzerinde sahip olacağı tek "güvenli" erişim budur. -Yani, eğer bir **attacker fargate kullanarak bir cluster'ı compromises** eder ve **diğer tüm adminsleri kaldırır** ve **Cluster'ı oluşturan AWS user/role'u silerse**, ~~attacker cluster'ı ransom etmiş olabilir~~. +Bu yüzden, eğer bir **attacker fargate kullanan bir cluster’ı ele geçirir** ve **diğer tüm adminleri kaldırır** ve cluster’ı oluşturan **AWS user/role’unu silerse**, ~~attacker cluster’ı **fidye için rehin almış olabilirdi**~~**r**. > [!TIP] -> Dikkat: Eğer cluster **EC2 VMs** kullanıyorsa, **Node**'dan Admin ayrıcalıkları elde etmek ve cluster'ı kurtarmak mümkün olabilir. +> Eğer cluster **EC2 VMs** kullanıyorsa, **Node** üzerinden Admin yetkileri almak ve cluster’ı kurtarmak mümkün olabilir. > -> Aslında, eğer cluster **Fargate** kullanıyorsa EC2 node'ları oluşturabilir veya her şeyi EC2'ye taşıyarak node içindeki tokens'a erişip kurtarabilirsiniz. +> Aslında, eğer cluster Fargate kullanıyorsa EC2 nodes ekleyebilir veya her şeyi EC2’ye taşıyıp node’daki tokens’lara erişerek cluster’ı kurtarabilirsiniz. {{#include ../../../../banners/hacktricks-training.md}}