Korean - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - IAM & STS Unauthenticated Enum

HackTricks 지원하기

계정에서 역할 및 사용자 이름 열거하기

역할 가정 브루트포스

이 기술은 더 이상 작동하지 않습니다. 역할이 존재하든 아니든 항상 다음과 같은 오류가 발생합니다:

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

The attacker could just assume it.

제3자 OIDC 연합

Imagine that you manage to read a Github Actions workflow that is accessing a role inside AWS. This trust might give access to a role with the following 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에서 역할을 가정할 수 있습니다.

참고문헌

HackTricks 지원하기
PreviousAWS - Elasticsearch Unauthenticated EnumNextAWS - Identity Center & SSO Unauthenticated Enum

Last updated