AWS - Podstawowe informacje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Hierarchia organizacji

Konta

W AWS istnieje konto główne, które jest rodzicem dla wszystkich kont w Twojej organizacji. Jednak nie musisz używać tego konta do wdrażania zasobów, możesz utworzyć inne konta, aby oddzielić różne infrastruktury AWS między sobą.

Jest to bardzo interesujące z punktu widzenia bezpieczeństwa, ponieważ jedno konto nie będzie mogło uzyskać dostępu do zasobów innego konta (chyba że specjalnie utworzone są mosty), dzięki czemu możesz tworzyć granice między wdrożeniami.

Dlatego w organizacji istnieją dwa typy kont (mówimy o kontach AWS, a nie kontach użytkowników): jedno konto, które jest wyznaczone jako konto zarządzające, oraz jedno lub więcej kont członkowskich.

  • Konto zarządzające (konto główne) to konto, którego używasz do tworzenia organizacji. Z konta zarządzającego organizacją możesz zrobić następujące rzeczy:

  • Tworzyć konta w organizacji

  • Zapraszać inne istniejące konta do organizacji

  • Usuwać konta z organizacji

  • Zarządzać zaproszeniami

  • Stosować polityki do podmiotów (korzeni, OU lub kont) w organizacji

  • Włączyć integrację z obsługiwanymi usługami AWS, aby zapewnić funkcjonalność usług w ramach wszystkich kont w organizacji.

  • Możliwe jest zalogowanie się jako użytkownik główny, używając adresu e-mail i hasła użytego do utworzenia tego konta głównego/organizacji.

Konto zarządzające ma odpowiedzialność konta płatnika i jest odpowiedzialne za opłacanie wszystkich opłat, które są naliczane przez konta członkowskie. Nie możesz zmienić konta zarządzającego organizacją.

  • Konta członkowskie składają się z pozostałych kont w organizacji. Konto może być członkiem tylko jednej organizacji w danym czasie. Możesz przypisać politykę do konta, aby zastosować kontrole tylko do tego jednego konta.
  • Konta członkowskie muszą używać ważnego adresu e-mail i mogą mieć nazwę, generalnie nie będą mogły zarządzać rozliczeniami (ale mogą otrzymać do nich dostęp).
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Jednostki Organizacyjne

Konta mogą być grupowane w Jednostki Organizacyjne (OU). W ten sposób możesz tworzyć polityki dla Jednostki Organizacyjnej, które będą stosowane do wszystkich kont podrzędnych. Zauważ, że OU może mieć inne OU jako dzieci.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Polityka kontroli usług (SCP) to polityka, która określa usługi i działania, które użytkownicy i role mogą wykorzystywać w kontach, na które wpływa SCP. SCP są podobne do polityk uprawnień IAM, z tą różnicą, że nie przyznają żadnych uprawnień. Zamiast tego, SCP określają maksymalne uprawnienia dla organizacji, jednostki organizacyjnej (OU) lub konta. Gdy dołączysz SCP do korzenia swojej organizacji lub OU, SCP ogranicza uprawnienia dla podmiotów w kontach członkowskich.

To jest JEDYNY sposób, aby nawet użytkownik root mógł być powstrzymany przed wykonaniem czegoś. Na przykład, może być użyta do powstrzymania użytkowników przed wyłączaniem CloudTrail lub usuwaniem kopii zapasowych.
Jedynym sposobem na obejście tego jest również skompromitowanie konta głównego, które konfiguruje SCP (konto główne nie może być zablokowane).

Warning

Zauważ, że SCP ograniczają tylko podmioty w koncie, więc inne konta nie są dotknięte. Oznacza to, że posiadanie SCP, które odmawia s3:GetObject, nie powstrzyma ludzi przed uzyskiwaniem dostępu do publicznego koszyka S3 w twoim koncie.

Przykłady SCP:

  • Całkowicie zablokować konto root
  • Zezwolić tylko na określone regiony
  • Zezwolić tylko na usługi z białej listy
  • Zablokować GuardDuty, CloudTrail i S3 Public Block Access przed

byciem wyłączonym

  • Zablokować role odpowiedzialności za bezpieczeństwo/incydenty przed usunięciem lub

zmianą.

  • Zablokować usuwanie kopii zapasowych.
  • Zablokować tworzenie użytkowników IAM i kluczy dostępu

Znajdź przykłady JSON w https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

Resource Control Policy (RCP)

Polityka kontroli zasobów (RCP) to polityka, która definiuje maksymalne uprawnienia dla zasobów w twojej organizacji AWS. RCP są podobne do polityk IAM pod względem składni, ale nie przyznają uprawnień—tylko ograniczają uprawnienia, które mogą być stosowane do zasobów przez inne polityki. Gdy dołączysz RCP do korzenia swojej organizacji, jednostki organizacyjnej (OU) lub konta, RCP ogranicza uprawnienia zasobów we wszystkich zasobach w dotkniętym zakresie.

To jest JEDYNY sposób, aby zapewnić, że zasoby nie mogą przekroczyć zdefiniowanych poziomów dostępu—nawet jeśli polityka oparta na tożsamości lub zasobach jest zbyt liberalna. Jedynym sposobem na obejście tych ograniczeń jest również modyfikacja RCP skonfigurowanej przez konto zarządzające twojej organizacji.

Warning

RCP ograniczają tylko uprawnienia, które zasoby mogą mieć. Nie kontrolują bezpośrednio, co podmioty mogą robić. Na przykład, jeśli RCP odmawia dostępu zewnętrznego do koszyka S3, zapewnia, że uprawnienia koszyka nigdy nie pozwalają na działania wykraczające poza ustalony limit—nawet jeśli polityka oparta na zasobach jest źle skonfigurowana.

Przykłady RCP:

  • Ograniczyć koszyki S3, aby mogły być dostępne tylko przez podmioty w twojej organizacji
  • Ograniczyć użycie kluczy KMS, aby zezwolić tylko na operacje z zaufanych kont organizacyjnych
  • Ograniczyć uprawnienia na kolejkach SQS, aby zapobiec nieautoryzowanym modyfikacjom
  • Wymusić granice dostępu na sekretach Menedżera Sekretów, aby chronić wrażliwe dane

Znajdź przykłady w dokumentacji Polityk Kontroli Zasobów AWS Organizations

ARN

Amazon Resource Name to unikalna nazwa, jaką ma każdy zasób w AWS, składa się z tego:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Zauważ, że w AWS są 4 partycje, ale tylko 3 sposoby ich nazywania:

  • AWS Standard: aws
  • AWS China: aws-cn
  • AWS US public Internet (GovCloud): aws-us-gov
  • AWS Secret (US Classified): aws

IAM - Zarządzanie Tożsamością i Dostępem

IAM to usługa, która pozwala zarządzać uwierzytelnianiem, autoryzacją i kontrolą dostępu w Twoim koncie AWS.

  • Uwierzytelnianie - Proces definiowania tożsamości i weryfikacji tej tożsamości. Proces ten można podzielić na: Identyfikację i weryfikację.
  • Autoryzacja - Określa, do czego tożsamość ma dostęp w systemie po jej uwierzytelnieniu.
  • Kontrola dostępu - Metoda i proces, w jaki sposób przyznawany jest dostęp do zabezpieczonego zasobu.

IAM można zdefiniować przez jego zdolność do zarządzania, kontrolowania i regulowania mechanizmów uwierzytelniania, autoryzacji i kontroli dostępu tożsamości do Twoich zasobów w Twoim koncie AWS.

Użytkownik główny konta AWS

Kiedy po raz pierwszy tworzysz konto Amazon Web Services (AWS), zaczynasz od pojedynczej tożsamości logowania, która ma pełny dostęp do wszystkich usług i zasobów AWS w koncie. To jest główny użytkownik konta AWS i uzyskuje się do niego dostęp, logując się za pomocą adresu e-mail i hasła, które użyłeś do utworzenia konta.

Zauważ, że nowy użytkownik admina będzie miał mniej uprawnień niż użytkownik główny.

Z punktu widzenia bezpieczeństwa zaleca się tworzenie innych użytkowników i unikanie korzystania z tego.

Użytkownicy IAM

Użytkownik IAM to podmiot, który tworzysz w AWS, aby reprezentować osobę lub aplikację, która używa go do interakcji z AWS. Użytkownik w AWS składa się z nazwy i poświadczeń (hasło i do dwóch kluczy dostępu).

Kiedy tworzysz użytkownika IAM, przyznajesz mu uprawnienia, czyniąc go członkiem grupy użytkowników, która ma odpowiednie polityki uprawnień (zalecane), lub bezpośrednio przypisując polityki do użytkownika.

Użytkownicy mogą mieć włączone MFA do logowania przez konsolę. Tokeny API użytkowników z włączonym MFA nie są chronione przez MFA. Jeśli chcesz ograniczyć dostęp kluczy API użytkowników za pomocą MFA, musisz wskazać w polityce, że aby wykonać określone działania, MFA musi być obecne (przykład tutaj).

CLI

  • ID klucza dostępu: 20 losowych wielkich liter i cyfr, np. AKHDNAPO86BSHKDIRYT
  • ID tajnego klucza dostępu: 40 losowych wielkich i małych liter: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Nie ma możliwości odzyskania utraconych ID tajnego klucza dostępu).

Kiedy musisz zmienić klucz dostępu, powinieneś postępować według tego procesu:
Utwórz nowy klucz dostępu -> Zastosuj nowy klucz do systemu/aplikacji -> oznacz oryginalny jako nieaktywny -> Przetestuj i zweryfikuj, że nowy klucz dostępu działa -> Usuń stary klucz dostępu

MFA - Uwierzytelnianie wieloskładnikowe

Jest używane do tworzenia dodatkowego czynnika uwierzytelniania oprócz istniejących metod, takich jak hasło, tworząc w ten sposób wieloskładnikowy poziom uwierzytelniania.
Możesz użyć darmowej aplikacji wirtualnej lub fizycznego urządzenia. Możesz użyć aplikacji takich jak Google Authenticator za darmo, aby aktywować MFA w AWS.

Polityki z warunkami MFA mogą być przypisane do następujących:

  • Użytkownika lub grupy IAM
  • Zasobu, takiego jak koszyk Amazon S3, kolejka Amazon SQS lub temat Amazon SNS
  • Polityki zaufania roli IAM, która może być przyjęta przez użytkownika

Jeśli chcesz uzyskać dostęp przez CLI do zasobu, który sprawdza MFA, musisz wywołać GetSessionToken. To da ci token z informacjami o MFA.
Zauważ, że poświadczenia AssumeRole nie zawierają tych informacji.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

As stated here, istnieje wiele różnych przypadków, w których MFA nie może być używane.

Grupy użytkowników IAM

Grupa użytkowników IAM to sposób na przypisanie polityk do wielu użytkowników jednocześnie, co może ułatwić zarządzanie uprawnieniami tych użytkowników. Role i grupy nie mogą być częścią grupy.

Możesz przypisać politykę opartą na tożsamości do grupy użytkowników, aby wszyscy użytkownicy w grupie użytkowników otrzymali uprawnienia polityki. Nie możesz zidentyfikować grupy użytkowników jako Principal w polityce (takiej jak polityka oparta na zasobach), ponieważ grupy odnoszą się do uprawnień, a nie do uwierzytelniania, a podmioty są uwierzytelnionymi jednostkami IAM.

Oto kilka ważnych cech grup użytkowników:

  • Grupa użytkowników może zawierać wielu użytkowników, a użytkownik może należeć do wielu grup.
  • Grupy użytkowników nie mogą być zagnieżdżone; mogą zawierać tylko użytkowników, a nie inne grupy użytkowników.
  • Nie ma domyślnej grupy użytkowników, która automatycznie obejmuje wszystkich użytkowników w koncie AWS. Jeśli chcesz mieć taką grupę użytkowników, musisz ją utworzyć i przypisać do niej każdego nowego użytkownika.
  • Liczba i rozmiar zasobów IAM w koncie AWS, takich jak liczba grup oraz liczba grup, do których użytkownik może należeć, są ograniczone. Aby uzyskać więcej informacji, zobacz kwoty IAM i AWS STS.

Role IAM

Rola IAM jest bardzo podobna do użytkownika, ponieważ jest to tożsamość z politykami uprawnień, które określają, co może i czego nie może robić w AWS. Jednak rola nie ma żadnych poświadczeń (hasła ani kluczy dostępu) związanych z nią. Zamiast być unikalnie przypisana do jednej osoby, rola ma być przyjmowana przez każdego, kto jej potrzebuje (i ma wystarczające uprawnienia). Użytkownik IAM może przyjąć rolę, aby tymczasowo uzyskać różne uprawnienia do konkretnego zadania. Rola może być przypisana do użytkownika federacyjnego, który loguje się za pomocą zewnętrznego dostawcy tożsamości zamiast IAM.

Rola IAM składa się z dwóch typów polityk: polityki zaufania, która nie może być pusta, definiującej kto może przyjąć rolę, oraz polityki uprawnień, która nie może być pusta, definiującej do czego ma dostęp.

Usługa AWS Security Token Service (STS)

AWS Security Token Service (STS) to usługa internetowa, która ułatwia wydawanie tymczasowych, ograniczonych uprawnień. Jest specjalnie dostosowana do:

Tymczasowe poświadczenia w IAM

Tymczasowe poświadczenia są głównie używane z rolami IAM, ale mają również inne zastosowania. Możesz zażądać tymczasowych poświadczeń, które mają bardziej ograniczony zestaw uprawnień niż standardowy użytkownik IAM. To zapobiega przypadkowemu wykonywaniu zadań, które nie są dozwolone przez bardziej ograniczone poświadczenia. Korzyścią tymczasowych poświadczeń jest to, że wygasają automatycznie po określonym czasie. Masz kontrolę nad czasem, przez jaki poświadczenia są ważne.

Polityki

Uprawnienia polityki

Służą do przypisywania uprawnień. Istnieją 2 typy:

  • Polityki zarządzane przez AWS (wstępnie skonfigurowane przez AWS)
  • Polityki zarządzane przez klienta: skonfigurowane przez Ciebie. Możesz tworzyć polityki na podstawie polityk zarządzanych przez AWS (modyfikując jedną z nich i tworząc własną), korzystając z generatora polityk (widok GUI, który pomaga w przyznawaniu i odmawianiu uprawnień) lub pisząc własne.

Zgodnie z domyślnym dostępem jest odmowa, dostęp zostanie przyznany, jeśli określono wyraźną rolę.
Jeśli istnieje pojedyncza “Odmowa”, nadpisze “Zezwól”, z wyjątkiem żądań, które używają poświadczeń bezpieczeństwa głównego konta AWS (które są dozwolone domyślnie).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

global fields that can be used for conditions in any service are documented here.
specific fields that can be used for conditions per service are documented here.

Inline Policies

Ten rodzaj polityk jest bezpośrednio przypisany do użytkownika, grupy lub roli. W związku z tym nie pojawiają się one na liście Polityk, ponieważ nikt inny nie może ich używać.
Polityki inline są przydatne, jeśli chcesz utrzymać ścisłą relację jeden do jednego między polityką a tożsamością, do której są stosowane. Na przykład, chcesz mieć pewność, że uprawnienia w polityce nie są przypadkowo przypisane do tożsamości innej niż ta, dla której są przeznaczone. Kiedy używasz polityki inline, uprawnienia w polityce nie mogą być przypadkowo przypisane do niewłaściwej tożsamości. Dodatkowo, gdy używasz konsoli zarządzania AWS do usunięcia tej tożsamości, polityki osadzone w tożsamości są również usuwane. Dzieje się tak, ponieważ są częścią głównego podmiotu.

Resource Bucket Policies

To są polityki, które mogą być definiowane w zasobach. Nie wszystkie zasoby AWS je wspierają.

Jeśli główny podmiot nie ma wyraźnego odmowy dostępu do nich, a polityka zasobów przyznaje im dostęp, to są one dozwolone.

IAM Boundaries

Granice IAM mogą być używane do ograniczenia uprawnień, do których użytkownik lub rola powinny mieć dostęp. W ten sposób, nawet jeśli inny zestaw uprawnień jest przyznawany użytkownikowi przez inną politykę, operacja nie powiedzie się, jeśli spróbuje ich użyć.

Granica to po prostu polityka przypisana do użytkownika, która wskazuje maksymalny poziom uprawnień, jakie użytkownik lub rola mogą mieć. Tak więc, nawet jeśli użytkownik ma dostęp administratora, jeśli granica wskazuje, że może tylko czytać kosze S·, to jest to maksymalne, co może zrobić.

To, SCPs i przestrzeganie zasady najmniejszych uprawnień to sposoby kontrolowania, aby użytkownicy nie mieli więcej uprawnień niż te, których potrzebują.

Session Policies

Polityka sesji to polityka ustawiana, gdy rola jest przyjmowana w jakiś sposób. Będzie to jak granica IAM dla tej sesji: Oznacza to, że polityka sesji nie przyznaje uprawnień, ale ogranicza je do tych wskazanych w polityce (maksymalne uprawnienia to te, które ma rola).

To jest przydatne dla środków bezpieczeństwa: Kiedy administrator ma przyjąć bardzo uprzywilejowaną rolę, może ograniczyć uprawnienia tylko do tych wskazanych w polityce sesji, w przypadku gdy sesja zostanie skompromitowana.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Zauważ, że domyślnie AWS może dodać polityki sesji do sesji, które będą generowane z powodu innych przyczyn. Na przykład, w przypadku nieautoryzowanych ról przyjętych przez Cognito domyślnie (korzystając z ulepszonej autoryzacji), AWS wygeneruje poświadczenia sesji z polityką sesji, która ogranicza usługi, do których sesja ma dostęp do następującej listy.

Dlatego, jeśli w pewnym momencie napotkasz błąd “… ponieważ żadna polityka sesji nie zezwala na …”, a rola ma dostęp do wykonania akcji, to dlatego, że istnieje polityka sesji, która to uniemożliwia.

Federacja Tożsamości

Federacja tożsamości pozwala użytkownikom z dostawców tożsamości, którzy są zewnętrzni dla AWS, na bezpieczny dostęp do zasobów AWS bez konieczności podawania poświadczeń użytkownika AWS z ważnego konta IAM.
Przykładem dostawcy tożsamości może być twoje własne korporacyjne Microsoft Active Directory (poprzez SAML) lub usługi OpenID (jak Google). Dostęp federacyjny pozwoli użytkownikom w nim na dostęp do AWS.

Aby skonfigurować to zaufanie, generowany jest dostawca tożsamości IAM (SAML lub OAuth), który ufa innej platformie. Następnie przynajmniej jedna rola IAM jest przypisywana (ufająca) do dostawcy tożsamości. Jeśli użytkownik z zaufanej platformy uzyskuje dostęp do AWS, uzyskuje dostęp jako wspomniana rola.

Jednak zazwyczaj będziesz chciał nadać inną rolę w zależności od grupy użytkownika na zewnętrznej platformie. Wtedy kilka ról IAM może ufać zewnętrznemu dostawcy tożsamości, a zewnętrzna platforma będzie tą, która pozwoli użytkownikom na przyjęcie jednej lub drugiej roli.

IAM Identity Center

AWS IAM Identity Center (następca AWS Single Sign-On) rozszerza możliwości AWS Identity and Access Management (IAM), aby zapewnić centralne miejsce, które łączy administrację użytkownikami i ich dostępem do kont AWS oraz aplikacji w chmurze.

Domena logowania będzie wyglądać jak <user_input>.awsapps.com.

Aby zalogować użytkowników, można użyć 3 źródeł tożsamości:

  • Katalog Identity Center: Zwykli użytkownicy AWS
  • Active Directory: Obsługuje różne konektory
  • Zewnętrzny dostawca tożsamości: Wszyscy użytkownicy i grupy pochodzą z zewnętrznego dostawcy tożsamości (IdP)

W najprostszym przypadku katalogu Identity Center, Identity Center będzie miał listę użytkowników i grup i będzie mógł przypisywać polityki do nich do dowolnych kont organizacji.

Aby nadać dostęp użytkownikowi/grupie Identity Center do konta, zostanie utworzony zaufany dostawca tożsamości SAML, a rola ufająca dostawcy tożsamości z wskazanymi politykami zostanie utworzona w docelowym koncie.

AwsSSOInlinePolicy

Możliwe jest nadawanie uprawnień za pomocą polityk inline do ról utworzonych za pomocą IAM Identity Center. Role utworzone w kontach, którym nadawane są polityki inline w AWS Identity Center, będą miały te uprawnienia w polityce inline o nazwie AwsSSOInlinePolicy.

Dlatego, nawet jeśli zobaczysz 2 role z polityką inline o nazwie AwsSSOInlinePolicy, to nie oznacza, że mają te same uprawnienia.

Zaufania i Role Między Kontami

Użytkownik (ufający) może utworzyć rolę międzykontową z pewnymi politykami, a następnie zezwolić innemu użytkownikowi (zaufanemu) na dostęp do swojego konta, ale tylko mając dostęp wskazany w nowych politykach roli. Aby to utworzyć, wystarczy utworzyć nową rolę i wybrać rolę międzykontową. Role do dostępu międzykontowego oferują dwie opcje. Zapewnienie dostępu między kontami AWS, które posiadasz, oraz zapewnienie dostępu między kontem, które posiadasz, a zewnętrznym kontem AWS.
Zaleca się określenie użytkownika, który jest zaufany, a nie umieszczanie czegoś ogólnego, ponieważ w przeciwnym razie inni uwierzytelnieni użytkownicy, tacy jak użytkownicy federacyjni, będą mogli również nadużywać tego zaufania.

AWS Simple AD

Nieobsługiwane:

  • Relacje zaufania
  • Centrum administracyjne AD
  • Pełne wsparcie dla PS API
  • Kosz na śmieci AD
  • Zarządzane konta usług grupowych
  • Rozszerzenia schematu
  • Brak bezpośredniego dostępu do OS lub instancji

Federacja Webowa lub Uwierzytelnianie OpenID

Aplikacja używa AssumeRoleWithWebIdentity do tworzenia tymczasowych poświadczeń. Jednak to nie przyznaje dostępu do konsoli AWS, tylko dostęp do zasobów w AWS.

Inne opcje IAM

  • Możesz ustawić politykę haseł, opcje takie jak minimalna długość i wymagania dotyczące haseł.
  • Możesz pobrać “Raport Poświadczeń” z informacjami o aktualnych poświadczeniach (takimi jak czas utworzenia użytkownika, czy hasło jest włączone…). Możesz generować raport poświadczeń tak często, jak co cztery godziny.

AWS Identity and Access Management (IAM) zapewnia szczegółową kontrolę dostępu w całym AWS. Dzięki IAM możesz określić, kto może uzyskać dostęp do jakich usług i zasobów, oraz na jakich warunkach. Dzięki politykom IAM zarządzasz uprawnieniami dla swojej siły roboczej i systemów, aby zapewnić minimalne uprawnienia.

Prefiksy ID IAM

Na tej stronie możesz znaleźć prefiksy ID IAM kluczy w zależności od ich natury:

Kod identyfikatoraOpis
ABIAToken nosiciela usługi AWS STS

| ACCA | Poświadczenie specyficzne dla kontekstu | | AGPA | Grupa użytkowników | | AIDA | Użytkownik IAM | | AIPA | Profil instancji Amazon EC2 | | AKIA | Klucz dostępu | | ANPA | Polityka zarządzana | | ANVA | Wersja w polityce zarządzanej | | APKA | Klucz publiczny | | AROA | Rola | | ASCA | Certyfikat | | ASIA | Tymczasowe identyfikatory kluczy dostępu (AWS STS) używają tego prefiksu, ale są unikalne tylko w połączeniu z tajnym kluczem dostępu i tokenem sesji. |

Zalecane uprawnienia do audytu kont

Następujące uprawnienia przyznają różny dostęp do metadanych:

  • arn:aws:iam::aws:policy/SecurityAudit
  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
  • codebuild:ListProjects
  • config:Describe*
  • cloudformation:ListStacks
  • logs:DescribeMetricFilters
  • directconnect:DescribeConnections
  • dynamodb:ListTables

Różne

Uwierzytelnianie CLI

Aby zwykły użytkownik mógł uwierzytelnić się w AWS za pomocą CLI, musisz mieć lokalne poświadczenia. Domyślnie możesz je skonfigurować ręcznie w ~/.aws/credentials lub uruchamiając aws configure.
W tym pliku możesz mieć więcej niż jeden profil, jeśli żaden profil nie jest określony przy użyciu aws cli, używany będzie ten o nazwie [default] w tym pliku.
Przykład pliku poświadczeń z więcej niż 1 profilem:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Jeśli musisz uzyskać dostęp do różnych kont AWS i Twój profil ma dostęp do przyjęcia roli w tych kontach, nie musisz ręcznie wywoływać STS za każdym razem (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) i konfigurować poświadczeń.

Możesz użyć pliku ~/.aws/config, aby wskazać, które role przyjąć, a następnie użyć parametru --profile jak zwykle (operacja assume-role zostanie wykonana w sposób przezroczysty dla użytkownika).
Przykład pliku konfiguracyjnego:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Z tym plikiem konfiguracyjnym możesz następnie używać aws cli w następujący sposób:

aws --profile acc2 ...

Jeśli szukasz czegoś podobnego do tego, ale dla przeglądarki, możesz sprawdzić rozszerzenie AWS Extend Switch Roles.

Automatyzacja tymczasowych poświadczeń

Jeśli wykorzystujesz aplikację, która generuje tymczasowe poświadczenia, może być uciążliwe aktualizowanie ich w terminalu co kilka minut, gdy wygasają. Można to naprawić, używając dyrektywy credential_process w pliku konfiguracyjnym. Na przykład, jeśli masz jakąś podatną aplikację webową, możesz zrobić:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Zauważ, że poświadczenia muszą być zwrócone do STDOUT w następującym formacie:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Odniesienia

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks