AWS - IAM Post Exploitation

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

IAM

IAMアクセスの詳細について:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

もしあなたが外部アカウント（A）にアクセスを許可して自分のアカウント内のroleにアクセスさせると、その外部アカウントを正確に誰がアクセスできるかについてほとんど可視性がありません。これは問題です。なぜなら別の外部アカウント（B）が外部アカウント（A）にアクセスできる場合、Bもあなたのアカウントにアクセスできる可能性があるからです。

したがって、あなたのアカウント内のroleへのアクセスを外部アカウントに許可する際に、ExternalIdを指定することができます。これは外部アカウント（A）が指定する必要がある「秘密」の文字列で、あなたの組織のroleをassumeするために使われます。外部アカウントBがこの文字列を知らなければ、たとえBがAにアクセスできてもあなたのroleにアクセスすることはできません。

ただし、このExternalIdという「秘密」は秘密ではありません。IAMのassume roleポリシーを読むことができる誰でもそれを確認できます。しかし外部アカウントAがそれを知っていて、外部アカウントBがそれを知らない限り、BがAを悪用してあなたのroleへアクセスすることを防ぎます。

例:

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

Warning

攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles をなりすますことができるかどうかを何らかの方法で特定する必要があります。

予期しない信頼関係

principal としてのワイルドカード

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

このポリシーは すべての AWS がロールを引き受けることを許可します。

プリンシパルとしてのサービス

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

このポリシーは任意のアカウントが自身の apigateway を設定してこの Lambda を呼び出すことを許可します。

S3 をプリンシパルとして

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

If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you バケットを削除しattackerが自身のアカウントでそれを作成した場合、彼らはこれを悪用できる可能性があります。

サポートされていません

{
"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, 一部のサービスはそれをサポートしていない場合があります（情報によれば CloudTrail のように）。

Credential Deletion

次のいずれかの権限 — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — を持っていると、攻撃者はアクセスキー、ログインプロファイル、SSH 公開鍵、サービス固有の認証情報、インスタンスプロファイル、証明書、あるいは CloudFront の公開鍵を削除したり、インスタンスプロファイルからロールを切り離したりできます。これらの操作は正当なユーザやアプリケーションを即座にブロックし、認証情報に依存するシステムのサービス停止（DoS）やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限し、監視する必要があります。

# 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 アクションは厳格に制限され監視される必要があります。

# 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 — を持つアクターは、マネージド／インラインポリシーを削除またはデタッチし、ポリシーのバージョンや permissions boundaries（権限境界）を削除し、ユーザー、グループ、ロールからポリシーのリンクを解除できます。これにより認可が失われ、権限モデルが変更され、当該ポリシーに依存していたプリンシパルは即時にアクセスを失ったりサービス拒否状態になったりする可能性があるため、これらの IAM アクションは厳格に制限および監視されるべきです。

# 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>

フェデレーテッドIDの削除

iam:DeleteOpenIDConnectProvider、iam:DeleteSAMLProvider、およびiam:RemoveClientIDFromOpenIDConnectProviderを使うと、攻撃者はOIDC/SAMLのアイデンティティプロバイダーを削除したりクライアントIDを削除したりできます。これによりフェデレーテッド認証が破壊され、トークンの検証ができなくなり、IdPまたは設定が復旧されるまでSSOに依存するユーザーやサービスへのアクセスが直ちに拒否されます。

# 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デバイスが登録されている場合、サインインにはいずれか1つのみが必要なため、この攻撃はアクセス拒否には影響しません）。

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の検証を無効化し、これらの資格情報に依存するサービスを即座に中断させ、アクセスや可用性の喪失を引き起こす可能性があります。

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 のワイルドカード iam:Delete* は、ユーザー、ロール、グループ、ポリシー、キー、証明書、MFA デバイス、ポリシーのバージョンなど、多くの種類の IAM リソースを削除する権限を付与します。そのため影響範囲は非常に大きく、iam:Delete* を付与されたアクターは ID、認証情報、ポリシーおよび関連アーティファクトを恒久的に破壊したり、監査/証拠を削除したり、サービスや運用の停止を引き起こしたりする可能性があります。いくつかの例は次のとおりです

# 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が登録されていない場合に、アカウント内のアイデンティティにMFAデバイスを登録できます。これはユーザーのアクセスを妨害するために利用できます：攻撃者がMFAデバイスを登録すると、正当なユーザーは攻撃者が登録したMFAを制御していないためサインインできなくなる可能性があります。

このアクセス拒否攻撃は、ユーザーにMFAが何も登録されていない場合にのみ有効です。攻撃者がそのユーザーのためにMFAデバイスを登録すると、正当なユーザーはその新しいMFAを要求するフローからロックアウトされます。ユーザーがすでに1つ以上のMFAデバイスを持っている場合、攻撃者が制御するMFAを追加しても正当なユーザーはブロックされません — 既に持っているMFAを使って引き続き認証できます。

ユーザーのためにMFAデバイスを有効化（登録）するには、攻撃者は次のように実行できます:

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

参考資料

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする