AWS - EKS Post Exploitation
Last updated
Last updated
Вивчайте та практикуйте AWS Хакінг:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Хакінг: HackTricks Training GCP Red Team Expert (GRTE)
Для отримання додаткової інформації перегляньте
Якщо у вас є дозвіл eks:AccessKubernetesApi
, ви можете переглядати об'єкти Kubernetes через консоль AWS EKS (Дізнайтеся більше).
Легкий спосіб:
Не такий простий спосіб:
Якщо ви можете отримати токен за допомогою aws eks get-token --name <cluster_name>
, але у вас немає дозволів на отримання інформації про кластер (describeCluster), ви можете підготувати свій власний ~/.kube/config
. Однак, маючи токен, вам все ще потрібен url-адреса кінцевої точки для підключення (якщо вам вдалося отримати JWT токен з поду, читайте тут) і назва кластера.
У моєму випадку я не знайшов інформацію в журналах CloudWatch, але я знайшов її в LaunchTemplates userData і в EC2 машинах у userData також. Ви можете легко побачити цю інформацію в userData, наприклад, у наступному прикладі (назва кластера була cluster-name):
Творець EKS кластера ЗАВЖДИ зможе отримати доступ до частини кластера kubernetes групи system:masters
(k8s адміністратор). На момент написання цього матеріалу немає прямого способу дізнатися хто створив кластер (ви можете перевірити CloudTrail). І немає способу видалити цей привілей.
Спосіб надати доступ до K8s для більшої кількості користувачів або ролей AWS IAM - це використання configmap aws-auth
.
Отже, будь-хто з доступом на запис до конфігураційної карти aws-auth
зможе компрометувати весь кластер.
Для отримання додаткової інформації про те, як надавати додаткові привілеї ролям та користувачам IAM в одному або різних облікових записах та як зловживати цим, перевірте цю сторінку.
Перевірте також цей чудовий пост, щоб дізнатися, як працює аутентифікація IAM -> Kubernetes.
Можливо дозволити аутентифікацію OpenID для облікового запису служби kubernetes, щоб дозволити їм приймати ролі в AWS. Дізнайтеся, як це працює на цій сторінці.
Не знайшов жодної документації, яка б пояснювала критерії для 'двох символів' та 'числа'. Але, проводячи деякі тести від свого імені, я бачу, що ці символи повторюються:
gr7
yl4
В будь-якому випадку, це всього лише 3 символи, які ми можемо перебрати. Використовуйте наведену нижче скрипт для генерації списку.
Тоді з wfuzz
Пам'ятайте, щоб замінити & .
Якщо зловмисник отримує облікові дані AWS з дозволами на EKS. Якщо зловмисник налаштовує свій власний kubeconfig
(без виклику update-kubeconfig
) як було пояснено раніше, get-token
не генерує журнали в Cloudtrail, оскільки не взаємодіє з AWS API (просто створює токен локально).
Отже, коли зловмисник спілкується з кластером EKS, cloudtrail не зафіксує нічого, що стосується вкраденого користувача та доступу до нього.
Зверніть увагу, що кластер EKS може мати увімкнені журнали, які зафіксують цей доступ (хоча за замовчуванням вони вимкнені).
За замовчуванням користувач або роль, яка створила кластер, ЗАВЖДИ матиме адміністративні привілеї над кластером. І це єдиний "безпечний" доступ, який AWS матиме до кластеру Kubernetes.
Отже, якщо зловмисник компрометує кластер, використовуючи fargate і видаляє всіх інших адміністраторів та видаляє користувача/роль AWS, яка створила кластер, зловмисник міг би вимагати викуп за кластер**.
Зверніть увагу, що якщо кластер використовує EC2 VMs, може бути можливим отримати адміністративні привілеї з Node і відновити кластер.
Насправді, якщо кластер використовує Fargate, ви могли б EC2 вузли або перемістити все до EC2 в кластер і відновити його, отримуючи токени в вузлі.
Декодування JWT токена дає нам ідентифікатор кластера та також регіон. Знаючи, що стандартний формат для URL EKS є
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)