AWS - IAM & STS Unauthenticated Enum
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ć:
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:
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:
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
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:
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:
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:
Zauważ znak wieloznaczny (*) przed dwukropkiem (:). Możesz utworzyć org o nazwie org_name1 i przyjąć rolę z akcji Github.
Referencje
Last updated