AWS - IAM & STS Unauthenticated Enum

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Wylicz role i nazwy użytkowników w koncie

Próbuj siłowo przejąć rolę

Ta technika już nie działa, ponieważ niezależnie od tego, czy rola istnieje, czy nie, zawsze otrzymasz 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 przejęcia roli bez wymaganych 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

To potwierdza istnienie roli, ale wskazuje, że jej polityka przyjęcia roli nie zezwala na twoje założenie. Natomiast próba założenia 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 jest stosowalna nawet w różnych kontach AWS. Dzięki poprawnemu identyfikatorowi konta AWS i docelowemu słownikowi, można wyliczyć role obecne w koncie bez żadnych ograniczeń.

Możesz użyć tego skryptu do wyliczenia potencjalnych podmiotów nadużywając tego problemu.

Polityki zaufania: Brutalne narzędzie do przeglądania ról i użytkowników międzykontowych

Konfigurowanie lub aktualizowanie polityki zaufania roli IAM polega na zdefiniowaniu, które zasoby lub usługi AWS mają prawo przejąć 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 podmiotu.

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

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

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

To 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 zostanie wyświetlony, 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

Korzystając z 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ą ma zimpersonować pacu, aby utworzyć wymagane przez niego zasady dla wyliczenia

Privesc

W przypadku źle skonfigurowanej roli, która pozwala każdemu na jej przejęcie:

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

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

Federacja OIDC strony trzeciej

Wyobraź sobie, że udało ci się odczytać przepływ pracy Github Actions, który uzyskuje dostęp do roli w 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"
}
}
}
]
}

To zaufanie polityki może być poprawne, ale brak dodatkowych warunków powinien skłonić do nieufności. Jest to dlatego, że poprzednią rolę może przejąć KTOKOLWIEK z Github Actions! Należy określić w warunkach także inne rzeczy, takie jak nazwa org., nazwa repozytorium, środowisko, gałąź...

Innym potencjalnym błędem konfiguracji jest dodanie warunku takiego jak poniżej:

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

Zauważ znak wieloznaczny (*) przed dwukropkiem (:). Możesz utworzyć org o nazwie org_name1 i przyjąć rolę z akcji Github.

Referencje

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Last updated