Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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 brak uprawnień, AWS może zwrócić:
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:
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.
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:
To jest błąd, który znajdziesz, jeśli używasz 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)
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
W przypadku, gdy rola była źle skonfigurowana i pozwala każdemu na jej przyjęcie:
The attacker could just assume it.
Wyobraź sobie, że udało 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:
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 przyjąć 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:
Zauważ, że znak wieloznaczny (*) przed dwukropkiem (:). Możesz stworzyć organizację taką jak org_name1 i przyjąć rolę z akcji Github.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
