AWS - IAM Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
IAM
For more information about IAM access:
{{#ref}} ../../aws-services/aws-iam-enum.md {{#endref}}
Confused Deputy Problem
もしあなたが自分のアカウントのroleへ外部アカウント (A) を許可すると、その外部アカウントに誰が正確にアクセスできるかについておそらく0の可視性になります。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、B があなたのアカウントにもアクセスできてしまう可能性があるからです。
したがって、あなたのアカウントのroleへ外部アカウントをアクセスさせる際に、ExternalId を指定することができます。これは外部アカウント (A) がassume the role in your organizationするために指定する必要がある「秘密」文字列です。外部アカウント B はこの文字列を知らないため、たとえ B が A にアクセスできても、あなたのroleにアクセスできません。
ただし、この ExternalId の「秘密」は秘密ではない点に注意してください。IAM assume role policy を読むことができる人なら誰でもそれを見ることができます。しかし、外部アカウント 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"
}
}
S3 bucketがプリンシパルとして指定されている場合、S3 bucketはアカウントIDを持たないため、もしあなたがbucketを削除し攻撃者がそれを作成した（攻撃者のアカウントで）場合、攻撃者はこれを悪用できる可能性があります。
サポートされていません
{
"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 のように）。
認証情報の削除
次のいずれかの権限 — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — を持つアクターは、アクセスキー、ログインプロファイル、SSH キー、サービス固有の資格情報、インスタンスプロファイル、証明書、CloudFront public keys を削除したり、インスタンスプロファイルからロールを切り離したりできます。こうした操作は正当なユーザーやアプリケーションを即座にブロックし、これらの資格情報に依存するシステムに対してサービス拒否（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>
フェデレーテッドアイデンティティの削除
iam:DeleteOpenIDConnectProvider、iam:DeleteSAMLProvider、および iam:RemoveClientIDFromOpenIDConnectProvider を使用すると、攻撃者は OIDC/SAML identity providers を削除したりクライアント ID を削除したりできます。これによりフェデレーテッド認証が破壊され、token validation が行えなくなり、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* を付与された主体は識別情報、認証情報、ポリシーおよび関連アーティファクトを恒久的に破壊したり、監査証拠を削除したり、サービスや運用の停止を引き起こしたりする可能性があります。いくつかの例は次のとおりです
# 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
参考資料
{{#include ../../../../banners/hacktricks-training.md}}