AWS - IAM Post Exploitation

Reading time: 8 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

IAM

For more information about IAM access:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

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

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

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

Example:

json
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "Example Corp's AWS Account ID"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "12345"
}
}
}
}

warning

Для attacker, щоб експлуатувати confused deputy, йому потрібно якось з'ясувати, чи principals поточного account можуть impersonate roles в інших account.

Неочікувані довірчі відносини

Wildcard як principal

json
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}

Ця політика дозволяє всім AWS приймати роль.

Сервіс як принципал

json
{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Ця політика дозволяє будь-якому обліковому запису налаштувати свій apigateway для виклику цього Lambda.

S3 як principal

json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}

Якщо як principal вказано S3 bucket, оскільки S3 buckets не мають Account ID, і якщо ви видалили свій bucket, а зловмисник створив його у своєму обліковому записі, то вони можуть цим зловживати.

Не підтримується

json
{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

A common way to avoid Confused Deputy problems is the use of a condition with AWS:SourceArn to check the origin ARN. However, some services might not support that (like CloudTrail according to some sources).

Видалення облікових даних

Маючи будь-який із наведених дозволів — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — актор може видалити access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates або CloudFront public keys, або disassociate roles from instance profiles. Такі дії можуть негайно заблокувати легітимних користувачів та застосунки і спричинити denial-of-service або втрату доступу для систем, що залежать від цих credentials, тому ці IAM permissions мають бути суворо обмежені та підлягати моніторингу.

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, актор може видалити користувачів, ролі або групи — або змінити членство в групі — видаляючи ідентичності та пов’язані сліди. Це може негайно порушити доступ для людей і сервісів, які залежать від цих ідентичностей, спричиняючи denial-of-service або втрату доступу, тому ці дії 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 та 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/

iam:Delete*

IAM wildcard iam:Delete* дає можливість видаляти багато типів IAM-ресурсів — користувачів, ролі, групи, політики, ключі, сертифікати, пристрої MFA, версії політик тощо — і тому має дуже великий blast radius: суб'єкт, якому надано iam:Delete*, може назавжди знищити ідентичності, облікові дані, політики та пов'язані артефакти, видалити журнали аудиту/докази та спричинити відмови сервісів або операційні збої. Деякі приклади:

bash
# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>

iam:EnableMFADevice

Актор, якому надано дію iam:EnableMFADevice, може зареєструвати MFA device на identity в account, за умови, що user раніше не мав увімкненого MFA.

Цим можна завадити доступу user: як тільки attacker зареєструє MFA device, легітимному user може бути заборонено sign in, оскільки він не контролює attacker-зареєстрований MFA.

Ця атака на відмову в доступі працює лише якщо user не мав зареєстрованого MFA; якщо attacker зареєструє MFA device для цього user, легітимний user буде заблокований у будь-яких flows, які вимагають цього нового MFA. Якщо user вже має один або кілька MFA devices під своїм контролем, додавання attacker-controlled MFA не блокує легітимного user — він може продовжувати authenticate, використовуючи будь-який MFA, який уже має.

Щоб enable (register) MFA device для user, attacker може виконати:

bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Посилання

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks