AWS - EKS Post Exploitation

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію в рекламі на HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks і HackTricks Cloud репозиторіїв на GitHub.

EKS

Для отримання додаткової інформації перегляньте

pageAWS - EKS Enum

Перелік кластера з консолі AWS

Якщо у вас є дозвіл eks:AccessKubernetesApi, ви можете переглядати об'єкти Kubernetes через консоль AWS EKS (Дізнайтеся більше).

Підключення до кластера AWS Kubernetes

• Простий спосіб:

# Generate kubeconfig
aws eks update-kubeconfig --name aws-eks-dev

• Не такий простий спосіб:

Якщо ви можете отримати токен за допомогою aws eks get-token --name <cluster_name>, але у вас немає дозволу на отримання інформації про кластер (describeCluster), ви можете підготувати свій власний ~/.kube/config. Однак, маючи токен, вам все ще потрібно URL-адресу кінцевої точки для підключення та назву кластера.

У моєму випадку, я не знайшов інформацію в журналах CloudWatch, але я знайшов її в userData шаблонів запуску та також в машини EC2 в userData також. Ви можете легко побачити цю інформацію в userData, наприклад, у наступному прикладі (назва кластера була 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

```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 ```

З AWS до Kubernetes

Створювач кластера EKS завжди матиме доступ до частини кластера Kubernetes групи system:masters (k8s admin). На момент написання цього тексту немає прямого способу визначити хто створив кластер (можна перевірити CloudTrail). І немає способу видалити це привілей.

Шляхом надання доступу до K8s для більшої кількості користувачів або ролей AWS IAM є використання configmap aws-auth.

Отже, будь-хто з правами на запис у config map aws-auth зможе компрометувати весь кластер.

Для отримання додаткової інформації про те, як надати додаткові привілеї ролям та користувачам IAM в тому ж або іншому обліковому записі та як це зловживати, перейдіть на цю сторінку.

Також перевірте цей чудовий пост, щоб дізнатися, як працює аутентифікація IAM -> Kubernetes.

З Kubernetes до AWS

Можливо дозволити OpenID аутентифікацію для облікового запису служби Kubernetes, щоб дозволити їм припускати ролі в AWS. Дізнайтеся, як це працює на цій сторінці](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).

Обхід CloudTrail

Якщо зловмисник отримує дані для входу в AWS з дозволом на EKS. Якщо зловмисник налаштує свій власний kubeconfig (без виклику update-kubeconfig), як пояснено раніше, get-token не генерує журналів в Cloudtrail, оскільки він не взаємодіє з API AWS (він просто створює токен локально).

Таким чином, коли зловмисник спілкується з кластером EKS, cloudtrail не буде реєструвати нічого, що стосується вкраденого користувача та доступу до нього.

Зверніть увагу, що кластер EKS може мати включені журнали, які будуть реєструвати цей доступ (хоча за замовчуванням вони вимкнені).

Вимога викупу за EKS?

За замовчуванням користувач або роль, який створив кластер, завжди матиме права адміністратора над кластером. І це єдиний "безпечний" доступ AWS до кластера Kubernetes.

Таким чином, якщо зловмисник компрометує кластер, використовуючи fargate та видаляє всіх інших адміністраторів та видаляє користувача/роль AWS, який створив кластер, зловмисник міг би вимагати викуп за кластерr.

Зверніть увагу, що якщо кластер використовує EC2 VM, можливо отримати права адміністратора з вузла та відновити кластер.

Фактично, якщо кластер використовує Fargate, ви можете використовувати вузли EC2 або перемістити все на EC2 до кластера та відновити доступ до токенів на вузлі.

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити свою компанію в рекламі на HackTricks або завантажити HackTricks у PDF, перевірте ПЛАНИ ПІДПИСКИ!

• Отримайте офіційний PEASS & HackTricks мерч

• Відкрийте Сім'ю PEASS, нашу колекцію ексклюзивних NFT

• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.

• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud github репозиторіїв.