AWS - Step Functions Privesc
Last updated
Last updated
Ucz się i ćwicz Hacking AWS: Ucz się i ćwicz Hacking GCP:
Aby uzyskać więcej informacji na temat tej usługi AWS, sprawdź:
Te techniki eskalacji uprawnień będą wymagały użycia niektórych zasobów funkcji kroków AWS, aby wykonać pożądane działania eskalacji uprawnień.
Aby sprawdzić wszystkie możliwe działania, możesz przejść do swojego konta AWS, wybrać działanie, które chcesz użyć, i zobaczyć parametry, które wykorzystuje, jak w:
Możesz również przejść do dokumentacji API AWS i sprawdzić dokumentację każdego działania:
states:TestState
& iam:PassRole
Atakujący z uprawnieniami states:TestState
i iam:PassRole
może testować dowolny stan i przekazywać dowolną rolę IAM do niego bez tworzenia lub aktualizowania istniejącej maszyny stanów, co umożliwia nieautoryzowany dostęp do innych usług AWS z uprawnieniami ról. W połączeniu te uprawnienia mogą prowadzić do szerokich nieautoryzowanych działań, od manipulacji przepływami pracy po modyfikację danych, naruszenia danych, manipulację zasobami i eskalację uprawnień.
Poniższe przykłady pokazują, jak przetestować stan, który tworzy klucz dostępu dla użytkownika admin
, wykorzystując te uprawnienia i permissywną rolę w środowisku AWS. Ta permissywna rola powinna mieć przypisaną jakąkolwiek politykę o wysokich uprawnieniach (na przykład arn:aws:iam::aws:policy/AdministratorAccess
), która pozwala stanowi na wykonanie akcji iam:CreateAccessKey
:
stateDefinition.json:
Polecenie wykonane w celu przeprowadzenia privesc:
Potencjalny wpływ: Nieautoryzowane wykonywanie i manipulacja przepływami pracy oraz dostęp do wrażliwych zasobów, co może prowadzić do poważnych naruszeń bezpieczeństwa.
states:CreateStateMachine
& iam:PassRole
& (states:StartExecution
| states:StartSyncExecution
)Atakujący z uprawnieniami states:CreateStateMachine
& iam:PassRole
mógłby stworzyć maszynę stanów i przypisać jej dowolną rolę IAM, co umożliwia nieautoryzowany dostęp do innych usług AWS z uprawnieniami tej roli. W przeciwieństwie do poprzedniej techniki eskalacji uprawnień (states:TestState
& iam:PassRole
), ta nie wykonuje się sama, będziesz również potrzebować uprawnień states:StartExecution
lub states:StartSyncExecution
(states:StartSyncExecution
nie jest dostępne dla standardowych przepływów pracy, tylko dla maszyn stanów wyrażających) w celu rozpoczęcia wykonania na maszynie stanów.
Poniższe przykłady pokazują, jak stworzyć maszynę stanów, która tworzy klucz dostępu dla użytkownika admin
i eksfiltruje ten klucz dostępu do kontrolowanego przez atakującego koszyka S3, wykorzystując te uprawnienia oraz permissywną rolę w środowisku AWS. Ta permissywna rola powinna mieć przypisaną jakąkolwiek politykę o wysokich uprawnieniach (na przykład arn:aws:iam::aws:policy/AdministratorAccess
), która pozwala maszynie stanów na wykonanie akcji iam:CreateAccessKey
i s3:putObject
.
stateMachineDefinition.json:
Polecenie wykonane w celu utworzenia maszyny stanów:
Polecenie wykonane w celu rozpoczęcia wykonania wcześniej utworzonej maszyny stanów:
Bucket S3 kontrolowany przez atakującego powinien mieć uprawnienia do akceptowania akcji s3:PutObject z konta ofiary.
Potencjalny wpływ: Nieautoryzowane wykonywanie i manipulacja przepływami pracy oraz dostęp do wrażliwych zasobów, co może prowadzić do poważnych naruszeń bezpieczeństwa.
states:UpdateStateMachine
& (nie zawsze wymagane) iam:PassRole
Atakujący z uprawnieniem states:UpdateStateMachine
mógłby zmodyfikować definicję maszyny stanów, dodając dodatkowe ukryte stany, które mogłyby prowadzić do eskalacji uprawnień. W ten sposób, gdy legalny użytkownik rozpocznie wykonanie maszyny stanów, ten nowy złośliwy ukryty stan zostanie wykonany, a eskalacja uprawnień zakończy się sukcesem.
W zależności od tego, jak permissywna jest rola IAM związana z maszyną stanów, atakujący napotka 2 sytuacje:
Permissywna rola IAM: Jeśli rola IAM związana z maszyną stanów jest już permissywna (ma na przykład dołączoną politykę arn:aws:iam::aws:policy/AdministratorAccess
), to uprawnienie iam:PassRole
nie byłoby wymagane do eskalacji uprawnień, ponieważ nie byłoby konieczne aktualizowanie roli IAM, wystarczy sama definicja maszyny stanów.
Niepermissywna rola IAM: W przeciwieństwie do poprzedniego przypadku, tutaj atakujący również wymagałby uprawnienia iam:PassRole
, ponieważ konieczne byłoby powiązanie permissywnej roli IAM z maszyną stanów oprócz modyfikacji definicji maszyny stanów.
Poniższe przykłady pokazują, jak zaktualizować legitną maszynę stanów, która po prostu wywołuje funkcję Lambda HelloWorld, aby dodać dodatkowy stan, który dodaje użytkownika unprivilegedUser
do grupy IAM administrator
. W ten sposób, gdy legalny użytkownik rozpocznie wykonanie zaktualizowanej maszyny stanów, ten nowy złośliwy stan ukryty zostanie wykonany, a eskalacja uprawnień zakończy się sukcesem.
Jeśli maszyna stanów nie ma przypisanego permissywnego roli IAM, wymagane będzie również uprawnienie iam:PassRole
do zaktualizowania roli IAM w celu przypisania permissywnej roli IAM (na przykład jednej z dołączoną polityką arn:aws:iam::aws:policy/AdministratorAccess
).
Polecenie wykonane w celu aktualizacji legitnej maszyny stanów:
Potencjalny wpływ: Nieautoryzowane wykonywanie i manipulacja przepływami pracy oraz dostęp do wrażliwych zasobów, co może prowadzić do poważnych naruszeń bezpieczeństwa.
Ucz się i ćwicz Hacking AWS: Ucz się i ćwicz Hacking GCP:
Sprawdź !
Dołącz do 💬 lub lub śledź nas na Twitterze 🐦 .
Dziel się trikami hackingowymi, przesyłając PR-y do i repozytoriów github.