AWS - IAM & STS Unauthenticated Enum

Wsparcie HackTricks

Enumeracja ról i nazw użytkowników w koncie

Brute-Force za pomocą Assume Role

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 przetestować to, uruchamiając:

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

Próba przyjęcia roli bez niezbędnych uprawnień wywołuje komunikat o błędzie AWS. Na przykład, jeśli nieautoryzowany, 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 polityka przyjmowania ról nie pozwala na twoje przyjęcie. W przeciwieństwie do tego, próba przyjęcia nieistniejącej roli prowadzi do innego błędu:

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

Interesująco, ta metoda rozróżniania między istniejącymi a nieistniejącymi rolami ma zastosowanie nawet w różnych kontach AWS. Posiadając ważny identyfikator konta AWS i docelową listę słów, można enumerować role obecne w koncie bez napotkania jakichkolwiek wrodzonych ograniczeń.

Możesz użyć tego skryptu do enumeracji potencjalnych głównych wykorzystując ten problem.

Polityki zaufania: Brute-Force ról i użytkowników między kontami

Konfigurowanie lub aktualizowanie polityki zaufania roli IAM polega na określeniu, które zasoby lub usługi AWS mają prawo przyjąć tę rolę i uzyskać tymczasowe poświadczenia. Jeśli określony 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 głównego.

Zauważ, że w tym zasobie możesz określić rolę lub użytkownika między kontami:

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

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

To jest 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 znajdziesz, 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 działa 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óra ma być udawana przez pacu, aby stworzyć polityki, które są potrzebne do enumeracji

Privesc

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

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

The attacker could just assume it.

Federacja OIDC stron trzecich

Wyobraź sobie, że uda ci się odczytać Github Actions workflow, który uzyskuje dostęp do roli wewnątrz AWS. To zaufanie może dać 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 budzić twoje wątpliwości. Dzieje się tak, ponieważ poprzednią rolę może przejąć KTOKOLWIEK z Github Actions! Powinieneś również określić w warunkach inne rzeczy, takie jak nazwa organizacji, nazwa repozytorium, środowisko, gałąź...

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

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

Zauważ, że znak wieloznaczny (*) przed dwukropkiem (:). Możesz stworzyć organizację, taką jak org_name1 i przyjąć rolę z akcji Github.

Odniesienia

Wsparcie HackTricks

Last updated