diff --git 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 index 26fc9ac90..d5dd73bcb 100644 --- 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, він **не зможе отримати доступ до вашої ролі**.
-Однак зверніть увагу, що цей `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 \ +--access-key-id AKIAIOSFODNN7EXAMPLE + +## Remove ssh key of a user +aws iam delete-ssh-public-key \ +--user-name \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE +``` +### Видалення ідентичностей +За наявності дозволів, таких як `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` або `iam:RemoveUserFromGroup`, суб'єкт може видаляти користувачів, ролі або групи — або змінювати членство в групах — видаляючи ідентичності та пов'язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи відмову в обслуговуванні або втрату доступу, тому ці дії IAM повинні бути суворо обмежені та моніторені. +```bash +# Delete a user +aws iam delete-user \ +--user-name + +# Delete a group +aws iam delete-group \ +--group-name + +# Delete a role +aws iam delete-role \ +--role-name +``` +### +З будь-яким із наведених дозволів — `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 \ +--policy-name + +# Delete a role policy +aws iam delete-role-policy \ +--role-name \ +--policy-name +``` +### Видалення федеративної ідентичності +За допомогою `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 \ +--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 \ +--ssh-public-key-id APKAEIBAERJR2EXAMPLE \ +--status Inactive + +aws iam update-server-certificate \ +--server-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) diff --git 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 index b46e669c2..0fedb3f26 100644 --- 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 не може бути виконана з крос-акаунту**.
-### Загальний 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 +``` +### Знищення ключів +Знищення ключів може призвести до 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/ + +# Update Alias +aws kms update-alias \ +--alias-name alias/ \ +--target-key-id +``` +### 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 + +## Second enable the key +aws kms enable-key \ +--key-id +``` +### Вимкнення ключа +Маючи дозвіл `kms:DisableKey`, актор може вимкнути AWS KMS customer master key, унеможлививши його використання для шифрування або розшифрування. Це призведе до втрати доступу для будь-яких сервісів, які залежать від цього CMK, і може спричинити негайні збої або denial-of-service до тих пір, поки ключ не буде знову увімкнено. +```bash +aws kms disable-key \ +--key-id +``` +### Виведення спільного секрету +За наявності дозволу `kms:DeriveSharedSecret` актор може використати приватний ключ, що зберігається в KMS, разом із публічним ключем, наданим користувачем, щоб обчислити ECDH-спільний секрет. +```bash +aws kms derive-shared-secret \ +--key-id \ +--public-key fileb:/// \ +--key-agreement-algorithm +``` +### Impersonation via kms:Sign +З дозволом `kms:Sign` актор може використовувати KMS-stored CMK для криптографічного підписування даних без розкриття private key, створюючи дійсні підписи, які можуть дозволити impersonation або авторизувати шкідливі дії. +```bash +aws kms sign \ +--key-id \ +--message fileb:// \ +--signing-algorithm \ +--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 + +aws kms disconnect-custom-key-store --custom-key-store-id + +aws kms update-custom-key-store --custom-key-store-id --new-custom-key-store-name --key-store-password +```
{{#include ../../../banners/hacktricks-training.md}}