AWS - IAM & STS 未認証列挙

Reading time: 9 minutes

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

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

必要な権限なしにロールを引き受けようとすると、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リソースまたはサービスを定義することを含み、一時的な資格情報を取得します。ポリシー内で指定されたリソースが存在する場合、信頼ポリシーは正常に保存されます。しかし、リソースが存在しない場合、エラーが生成され、無効なプリンシパルが提供されたことを示します。

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

{
"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"
}
]
}

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

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

あなたがAWS内のロールにアクセスしているGithub Actionsワークフローを読むことができたと想像してください。
この信頼は、次の信頼ポリシーを持つロールへのアクセスを与える可能性があります：

{
"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/