gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-06-12 19:11:44 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

Browse Source
This commit is contained in:
Translator
2026-06-05 13:54:19 +00:00
parent 5773dbb677
commit a37f47c727
1 changed files with 48 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
+48 -28
View File
@@ -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 <cluster_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 <cluster_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
```
<details>
<summary>kube yapılandırması</summary>
<summary>kube config</summary>
```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 <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --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 <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --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 <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://<cluster-id>.<two-random-chars><number>.<region>.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://<cluster-id>.FUZZ.<region>.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}}