Оскільки все більше організацій покладаються на хмарні сервіси, стає критично важливо розуміти складність хмарних середовищ та помилки конфігурації, які можуть призвести до компрометації ресурсів та акаунтів. Цей посібник розгляне одну з найсерйозніших загроз безпеці в середовищах AWS — ескалацію привілеїв через прийняття ролі (role assumption). Це сценарій, за якого користувач із обмеженими дозволами IAM може отримати підвищений доступ до ресурсів, використовуючи неправильно налаштовану роль IAM.

Зміст

• Вступ до AWS IAM
• Ключові терміни IAM
• Про AssumeRole
• Налаштування лабораторії та попередні вимоги
• Частина 1: Налаштування вразливої лабораторії IAM
• Створення користувача IAM з низькими привілеями
• Створення ролі IAM з високими привілеями
• Налаштування S3 (S3 Bucket)
• Частина 2: Перерахунок та експлуатація IAM
• Як користувач може отримати доступ до ролі IAM з високими привілеями
• Перерахунок ролі IAM за допомогою Python-скрипту enumerate-iam
• Перерахунок ролі IAM за допомогою AWS CLI
• Ескалація привілеїв через IAM AssumeRole
• Аналіз
• Рекомендації
• Висновок

Вступ до AWS IAM

AWS Identity and Access Management (IAM) — це вебсервіс, який допомагає безпечно контролювати доступ до ресурсів AWS. Зокрема, за допомогою IAM ви можете керувати дозволами, які визначають, до яких ресурсів AWS користувачі мають доступ. Іншими словами, ви використовуєте IAM, щоб контролювати, хто автентифікований (увійшов у систему) і авторизований (має дозволи) на використання ресурсів. Крім того, IAM забезпечує інфраструктуру, необхідну для контролю автентифікації та авторизації у ваших облікових записах AWS.

Ключові терміни IAM

• Principal (Суб’єкт): Загальний термін для ідентифікаторів IAM.
• IAM User (Користувач): Суб’єкт із довгостроковими обліковими даними.
• Програмний доступ через Access Key ID та Secret Access Key.
• Доступ до вебконсолі через ім’я користувача та пароль.
• IAM Role (Роль): Суб’єкт, права якого можуть бути прийняті іншими.
• IAM Policy (Політика): Дозволи, які можуть бути призначені суб’єкту або групі.

Про AssumeRole

Role assumption це дія, що полягає в тимчасовому отриманні дозволів певної ролі IAM. Коли користувач (або інша роль/сервіс) приймає роль, AWS надає йому тимчасові облікові дані безпеки, які складаються з ідентифікатора ключа доступу (Access Key ID), секретного ключа доступу (Secret Access Key) та токена сесії (Session Token). Ці дані дозволяють виконувати дії, визначені прийнятою роллю.

Це зазвичай використовується в межах одного облікового запису або між різними акаунтами (кросакаунтний доступ). Дія AssumeRole — це операція API в AWS IAM, яка робить це можливим.

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

Ключові компоненти прийняття ролі:

• Trust Policy (Політика довіри) – Визначає, кому дозволено приймати роль.
• Permissions Policy (Політика дозволів) – Визначає, які дії може виконувати роль.
• Temporary Credentials (Тимчасові дані) – Видаються сервісом AWS STS під час прийняття ролі.

AWS Security Token Service (STS) — це сервіс, який видає тимчасові облікові дані безпеки користувачам або ролям, яким необхідно отримати доступ до ресурсів AWS на обмежений час.

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

• Акаунт AWS
• VM Kali Linux

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

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

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

По-перше, у полі пошуку сервісів AWS введіть «IAM» і виберіть сервіс IAM, що з’явиться в результатах.

Потім у лівому навігаційному меню натисніть посилання Users (Користувачі) у розділі Access Management.

Після цього на сторінці користувачів натисніть Create user (Створити користувача), щоб додати нового користувача.

Вкажіть User name (Ім’я користувача) (наприклад, lgt_lowpriv) і натисніть Next (Далі).

Налаштуйте дозволи для користувача lgt_lowpriv. На сторінці Set permissions виберіть Attach policies directly (Приєднати політики безпосередньо) серед запропонованих варіантів.

У розділі Permission Policies (Політики дозволів) знайдіть та виберіть політику з назвою AmazonEC2FullAccess. Назва політики повинна точно збігатися з цією.

• AmazonEC2FullAccess — ця політика надасть користувачеві повний доступ до сервісу EC2 та можливість керувати ним (наприклад, операції читання та запису для інстансів EC2).

• Потім приєднайте ще одну політику — AmazonS3ReadOnlyAccess. Вона дозволяє нашому користувачу переглядати S3-кошики та їхній вміст, але явно забороняє вносити будь-які зміни або видаляти щось.

“Це обмеження стане ключовою частиною нашої демонстрації ескалації привілеїв”.

• IAMReadOnlyAccess — цей дозвіл дозволить нашому користувачу переглядати конфігурації IAM, що часто є критичним кроком для виявлення потенційних вразливостей.

Нарешті, натисніть Next (Далі), а потім Create user (Створити користувача).

Після завершення натисніть на щойно створеного користувача та перегляньте його деталі.

Виберіть «Create access key» (Створити ключ доступу). Ці ключі (Access Key ID та Secret Access Key) є необхідними для програмної взаємодії з AWS за допомогою таких інструментів, як інтерфейс командного рядка AWS (CLI).

Потім виберіть «Command Line Interface (CLI)» як сценарій використання (use case).

Натисніть «Create access key»

Тепер завантажте .csv файл, що містить Access Key ID та Secret Access Key. Зберігайте ці облікові дані в безпеці.

Створення ролі IAM з високими привілеями

Тепер ми створимо потужну роль IAM. Ця роль втілює ті розширені привілеї, які наш користувач lgt_lowpriv тимчасово отримає під час нашої демонстрації.

Крок 1: Перейдіть до ролей IAM

Поверніться до дашборду IAM, натисніть «Roles» (Ролі) у розділі «Access management», а потім натисніть «Create role» (Створити роль).

Крок 2: Налаштування деталей ролі

Для параметра «Trusted entity type» (Тип довіреної сутності) виберіть «AWS account». Це означає, що ми налаштовуємо цю роль так, щоб її могла прийняти сутність у межах акаунта AWS.

Виберіть «This account» (Цей акаунт). Натисніть «Next». Це вказує на те, що сутність у межах вашого поточного акаунта AWS матиме дозвіл на прийняття цієї ролі.

Політики дозволів (Permissions policies): Знайдіть і виберіть «AdministratorAccess». Ця політика надає повний контроль практично над усіма сервісами та ресурсами AWS, що робить її нашою «високопривілейованою» ціллю для лабораторної роботи.

Натисніть «Next».

Ім’я ролі (Role name): Введіть admin_role. Натисніть «Create role».

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Переконайтеся, що роль admin_role успішно створена.

Крок 3: Модифікація політики довіри ролі

Виберіть admin_role зі списку ролей.

Перейдіть на вкладку «Trust relationships»

Натисніть «Edit trust policy»

Змініть політику JSON, щоб дозволити користувачу lgt_lowpriv приймати цю роль. Замініть ARN у полі «Principal» на ARN вашого користувача lgt_lowpriv:

Це серце нашого лабораторного стенду. Додаючи lgt_lowpriv до поля Principal і дозволяючи дію sts:AssumeRole, ми явно надаємо нашому низькопривілейованому користувачу можливість «увійти» в цю потужну роль.

Натисніть «Update policy»

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:<Change for Trusted Username> "
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Налаштування S3

Щоб зробити нашу демонстрацію наочною, ми створимо S3-кошик із «конфіденційним» файлом. Спочатку наш користувач lgt_lowpriv не зможе повністю контролювати цей кошик, але отримає таку можливість після прийняття ролі admin_role.

Крок 1: Створення S3

Знайдіть «S3» у консолі AWS і виберіть «S3 – Scalable Storage in the Cloud». S3 — це сервіс об’єктного зберігання AWS, що ідеально підходить для нашого демонстраційного файлу.

Натисніть «Create bucket»

Bucket name (Ім’я кошика): Введіть унікальне ім’я, наприклад, igt-bucket. Пам’ятайте, що імена S3-кошиків мають бути глобально унікальними серед усіх акаунтів AWS.

У розділі «Object Ownership» (Власність об’єктів) переконайтеся, що вибрано «ACLs disabled» (ACL вимкнено). Це сучасний, рекомендований спосіб керування дозволами S3 переважно через політики IAM.

Налаштування Block Public Access для цього кошика: Зніміть прапорець «Block all public access» (Блокувати весь публічний доступ). Підтвердьте попередження. Для цієї конкретної лабораторної роботи ми хочемо точно контролювати доступ через політики IAM, і це дає нам таку можливість. У реальному середовищі ви зазвичай тримаєте публічний доступ заблокованим, якщо він не є абсолютно необхідним.

Натисніть «Create bucket».

Переконайтеся, що igt-bucket успішно створено.

Крок 2: Завантаження файлу в S3

Виберіть свій кошик igt-bucket. Натисніть «Upload» (Завантажити).

Натисніть «Add files» (Додати файли) і завантажте файл із назвою secrets.txt (або схожою). Цей файл буде нашою ціллю для демонстрації зміни прав доступу.

Натисніть «Upload».

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

Як користувач може отримати доступ до високої ролі IAM?

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

Перерахунок ролі IAM за допомогою Python-скрипту enumerate-iam — Метод 1

По-перше, на вашій машині Kali Linux відкрийте термінал і клонуйте інструмент enumerate-iam. Цей інструмент чудово підходить для виявлення дозволів, пов’язаних із IAM, і потенційних шляхів ескалації.

git clone https://github.com/andresriancho/enumerate-iam.git
cd enumerate-iam

Потім створіть та активуйте віртуальне середовище Python: це ізолює залежності проекту, зберігаючи вашу систему чистою. Встановіть необхідні компоненти (requirements).

python3 -m venv iam 
source iam/bin/activate
pip install -r requirements.txt

Після цього запустіть скрипт enumerate-iam.py, використовуючи Access Key ID та Secret Access Key нашого користувача з низькими привілеями lgt_lowpriv.

enumerate-iam.py

Результат (output) повинен показати наявність політик AmazonEC2FullAccess, IAMReadOnlyAccess та AmazonS3ReadOnlyAccess.

Вивід скрипту також розкриє деталі ролі IAM, призначеної для користувача IAM (lgt_lowpriv).

Як ми бачимо з результатів роботи скрипту, нашому скомпрометованому користувачу (lgt_lowpriv) доступна роль IAM з назвою admin_role, до якої прикріплена політика AdministratorAccess.

Перерахунок ролі IAM за допомогою AWS CLI — Метод 2

Встановіть AWS CLI: Інтерфейс командного рядка AWS (AWS CLI) — це інструмент із відкритим вихідним кодом, який дозволяє взаємодіяти з сервісами AWS за допомогою команд у вашому терміналі.

Усі функції адміністрування, керування та доступу до IaaS (інфраструктура як сервіс), доступні в консолі керування AWS, також доступні через AWS API та AWS CLI. 

apt install awscli

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

• По-перше, введіть Access Key ID та Secret Access Key.
• Потім встановіть Default region name (наприклад, us-east-1 або ваш робочий регіон).
• Крім того, залиште Default output format за замовчуванням. Цей крок зберігає облікові дані lgt_lowpriv, дозволяючи вам легко виконувати команди від імені цього конкретного користувача.

aws  --version
aws configure --profile lgt_lowpriv

Переконайтеся, що облікові дані збережені у файлі ~/.aws/credentials.

cat credentials

Виведіть список ролей IAM: aws iam list-roles —profile lgt_lowpriv. Ви повинні побачити admin_role та її політику довіри. Це підтверджує, що роль є потенційною ціллю.

aws iam list-roles

Виведіть список політик, приєднаних до admin_role: Це має показати наявність AdministratorAccess.

aws iam list-attached-role-policies --role-name admin_role

Отримайте документ політики прийняття ролі (Assume Role Policy Document) для admin_role: Це остаточно підтверджує, що lgt_lowpriv має право прийняти на себе права admin_role.

aws iam get-role --role-name admin_role --query 'Role.AssumeRolePolicyDocument' --output text

Виведіть список S3-кошиків: Ви повинні побачити igt-bucket.

Перегляньте вміст igt-bucket: Ви повинні побачити файл secrets.txt.

Скопіюйте secrets.txt з S3 та перегляньте його вміст:

Спробуйте видалити файл (має виникнути помилка через S3ReadOnlyAccess): Ви отримаєте повідомлення про помилку «AccessDenied». Це критичний момент нашої демонстрації: попри можливість читати файл, lgt_lowpriv не може його видалити, що демонструє обмеження «лише для читання».

aws s3 ls
aws s3 ls s3://igt-bucket/
aws s3 cp s3://igt-bucket/secrets.txt out_secrets.txt
cat out_secrets.txt
aws s3 rm s3://igt-bucket/secrets.txt

Це готує підґрунтя для нашої ескалації привілеїв.

Ескалація привілеїв через IAM AssumeRole

Тепер головна дія: приймаємо роль admin_role! Виконайте наступну команду — це і є наш «експлуайт». Вона запитує тимчасові облікові дані у сервісу AWS Security Token Service (STS) для ролі admin_role.

Параметр role-session-name — це просто мітка для цієї конкретної сесії. Після успішного виконання AWS надасть новий набір Access Key ID, Secret Access Key та Session Token.

aws sts assume-role --role-arn arn:aws:iam::<YOUR_ACCOUNT_ID>:role/admin_role --role-session-name "ExploitSession”

Експортуйте тимчасові облікові дані як змінні середовища:

export AWS_ACCESS_KEY_ID="<AccessKeyId from previous output>"
export AWS_SECRET_ACCESS_KEY="<SecretAccessKey from previous output>"
export AWS_SESSION_TOKEN="<SessionToken from previous output>"

Це вкаже вашому AWS CLI використовувати ці потужні тимчасові дані для всіх наступних команд.

Перевірте прийняту ідентичність: ARN тепер має відображати прийняту роль (assumed-role/admin_role/ExploitSession).

aws sts get-caller-identity

Тепер видаліть файл з S3 (тепер це буде успішно завдяки AdministratorAccess):

aws s3 rm s3: // igt-bucket/secrets.txt

Нарешті, перевірте видалення за допомогою наступної команди — кошик тепер має бути порожнім.

aws s3 ls s3: // igt-bucket/

Аналіз

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

lgt_lowpriv → приймає admin_role (через sts:AssumeRole) → політика довіри дозволяє це → STS видає тимчасові облікові дані → admin_role має політику AdministratorAccess → користувач отримує повні права адміністратора.

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

• Надмірно поблажливі політики довіри: Дозвіл на прийняття ролі надається занадто широкому колу суб’єктів.
• Відсутність перевірок умов (Conditions): Невикористання таких параметрів, як aws:MultiFactorAuthPresent (наявність MFA) або aws:SourceIp (обмеження за IP).
• Неналежне розділення ролей: Коли технічні ролі змішуються з адміністративними без чітких меж.

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

• Обмеження доступу: Уникайте надання дозволу на AssumeRole для ролей із політикою AdministratorAccess, якщо це не є абсолютно необхідним.
• Використання умов (Conditions): Завжди додавайте умови в політики довіри, щоб посилити безпеку:

"Condition": {
"Bool": {
     "aws:MultiFactorAuthPresent": "true"
    }
}

• Організаційний контроль: Використовуйте політики на основі ресурсів (Resource-based policies) та сервісні контрольні політики (SCPs) у межах AWS Organizations для обмеження небезпечних дій на рівні всього акаунта.
• Аудит та моніторинг: Регулярно перевіряйте використання AssumeRole через AWS CloudTrail та налаштовуйте правила AWS Config для виявлення занадто відкритих ролей.

Висновок

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