Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - KMS Enum

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

KMS - Usługa zarządzania kluczami

AWS Key Management Service (AWS KMS) jest prezentowany jako usługa zarządzana, upraszczająca proces tworzenia i zarządzania kluczami głównymi klienta (CMK). Te CMK są integralne w szyfrowaniu danych użytkownika. Istotną cechą AWS KMS jest to, że CMK są głównie zabezpieczone przez moduły bezpieczeństwa sprzętowego (HSM), zwiększając ochronę kluczy szyfrowania.

KMS używa kryptografii symetrycznej. Jest to używane do szyfrowania informacji w spoczynku (na przykład wewnątrz S3). Jeśli potrzebujesz szyfrować informacje w transporcie, musisz użyć czegoś takiego jak TLS.

KMS to usługa specyficzna dla regionu.

Administratorzy w Amazonie nie mają dostępu do Twoich kluczy. Nie mogą odzyskać Twoich kluczy i nie pomagają Ci w szyfrowaniu Twoich kluczy. AWS po prostu administruje systemem operacyjnym i aplikacją bazową, to od nas zależy administrowanie naszymi kluczami szyfrowania i administrowanie tym, jak te klucze są używane.

Klucze główne klienta (CMK): Mogą szyfrować dane o wielkości do 4 KB. Zazwyczaj są używane do tworzenia, szyfrowania i deszyfrowania DEKów (Kluczy Szyfrowania Danych). Następnie DEK są używane do szyfrowania danych.

Klucz główny klienta (CMK) to logiczna reprezentacja klucza głównego w AWS KMS. Oprócz identyfikatorów klucza głównego i innych metadanych, w tym daty utworzenia, opisu i stanu klucza, CMK zawiera materiał klucza, który jest używany do szyfrowania i deszyfrowania danych. Podczas tworzenia CMK, domyślnie AWS KMS generuje materiał klucza dla tego CMK. Możesz jednak wybrać utworzenie CMK bez materiału klucza, a następnie zaimportować swój własny materiał klucza do tego CMK.

Istnieją 2 rodzaje kluczy głównych:

  • Zarządzane przez AWS CMK: Używane przez inne usługi do szyfrowania danych. Jest używany przez usługę, która go utworzyła w regionie. Są tworzone za pierwszym razem, gdy implementujesz szyfrowanie w tej usłudze. Rotują co 3 lata i nie można ich zmienić.

  • Klucze główne klienta: Elastyczność, rotacja, konfigurowalny dostęp i polityka klucza. Włączanie i wyłączanie kluczy.

Szyfrowanie kopertowe w kontekście Usługi Zarządzania Kluczami (KMS): Dwupoziomowy system hierarchii do szyfrowania danych kluczem danych, a następnie szyfrowania klucza danych kluczem głównym.

Polityki kluczy

Określają one kto może używać i uzyskiwać dostęp do klucza w KMS.

Domyślnie:

  • Daje kontowi AWS, które jest właścicielem klucza KMS, pełny dostęp do klucza KMS.

W przeciwieństwie do innych polityk zasobów AWS, polityka klucza AWS KMS nie daje automatycznie uprawnień do konta ani jego użytkowników. Aby nadać uprawnienia administratorom konta, polityka klucza musi zawierać wyraźne oświadczenie, które zapewnia te uprawnienia, takie jak to.

  • Bez zezwolenia na konto ("AWS": "arn:aws:iam::111122223333:root") uprawnienia IAM nie będą działać.

  • Zezwala kontu na korzystanie z polityk IAM do umożliwienia dostępu do klucza KMS, oprócz polityki klucza.

Bez tego uprawnienia, polityki IAM, które pozwalają na dostęp do klucza, są nieskuteczne, chociaż polityki IAM, które odmawiają dostępu do klucza, nadal są skuteczne.

  • Zmniejsza ryzyko, że klucz stanie się niezarządzalny, nadając uprawnienia kontroli dostępu administratorom konta, w tym użytkownikowi głównemu konta, który nie może zostać usunięty.

Przykład domyślnej polityki:

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}

Jeśli konto jest dozwolone ("arn:aws:iam::111122223333:root") podmiot z konta wciąż będzie potrzebował uprawnień IAM do użycia klucza KMS. Jednakże, jeśli ARN roli na przykład jest specjalnie dozwolony w Polityce Klucza, ta rola nie będzie potrzebować uprawnień IAM.

Szczegóły Polityki

Właściwości polityki:

  • Dokument oparty na JSON

  • Zasób --> Dotknięte zasoby (może być "*")

  • Akcja --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (uprawnienia)

  • Efekt --> Allow/Deny

  • Podmiot --> dotknięty arn

  • Warunki (opcjonalne) --> Warunek do udzielenia uprawnień

Uprawnienia:

  • Pozwala na delegowanie uprawnień do innego podmiotu AWS w ramach konta AWS. Musisz je tworzyć za pomocą interfejsów API AWS KMS. Można wskazać identyfikator CMK, podmiot beneficjenta i wymagany poziom operacji (Decrypt, Encrypt, GenerateDataKey...)

  • Po utworzeniu upoważnienia wydawane są GrantToken i GratID

Dostęp:

  • Poprzez politykę klucza -- Jeśli istnieje, to ma najwyższy priorytet nad polityką IAM

  • Poprzez politykę IAM

  • Poprzez uprawnienia

Administratorzy Klucza

Domyślnie administratorzy klucza:

  • Mają dostęp do zarządzania KMS, ale nie do szyfrowania ani deszyfrowania danych

  • Tylko użytkownicy IAM i role mogą być dodane do listy Administratorów Klucza (nie grupy)

  • Jeśli używany jest zewnętrzny CMK, Administratorzy Klucza mają uprawnienie do importowania materiału klucza

Rotacja CMKs

  • Im dłużej ten sam klucz pozostaje na swoim miejscu, tym więcej danych jest szyfrowanych tym kluczem, a jeśli ten klucz zostanie naruszony, to obszar ryzyka danych jest szerszy. Ponadto, im dłużej klucz jest aktywny, tym większe jest prawdopodobieństwo jego naruszenia.

  • KMS obraca klucze klienta co 365 dni (lub można wykonać proces ręcznie w dowolnym momencie) i klucze zarządzane przez AWS co 3 lata i tego czasu nie można zmienić.

  • Starsze klucze są zachowywane do deszyfrowania danych, które zostały zaszyfrowane przed rotacją

  • W przypadku naruszenia, obrót klucza nie usunie zagrożenia, ponieważ będzie możliwe deszyfrowanie wszystkich danych zaszyfrowanych skompromitowanym kluczem. Jednakże, nowe dane będą szyfrowane nowym kluczem.

  • Jeśli CMK jest w stanie wyłączonym lub oczekującym na usunięcie, KMS nie będzie wykonywać rotacji klucza dopóki CMK nie zostanie ponownie włączony lub usunięcie nie zostanie anulowane.

Ręczna rotacja

  • Musi zostać utworzony nowy CMK, następnie, tworzy się nowe ID CMK, więc trzeba zaktualizować każdą aplikację, aby odnosiła się do nowego ID CMK.

  • Aby ułatwić ten proces, można użyć aliasów do odwoływania się do identyfikatora klucza i następnie zaktualizować klucz, do którego odwołuje się alias.

  • Należy zachować stare klucze do deszyfrowania starych plików zaszyfrowanych nimi.

Można importować klucze z infrastruktury kluczy na miejscu.

Inne istotne informacje o KMS

KMS jest wyceniany za liczbę żądań szyfrowania/deszyfrowania otrzymanych od wszystkich usług miesięcznie.

KMS ma pełną integrację z audytem i zgodnością z CloudTrail; tutaj można audytować wszystkie zmiany dokonane w KMS.

Z polityką KMS można zrobić następujące rzeczy:

  • Ograniczyć, kto może tworzyć klucze danych i które usługi mają dostęp do używania tych kluczy

  • Ograniczyć dostęp systemów do szyfrowania tylko, deszyfrowania tylko lub obu

  • Zdefiniować, aby umożliwić systemom dostęp do kluczy między regionami (choć nie jest to zalecane, ponieważ awaria w regionie hostującym KMS wpłynie na dostępność systemów w innych regionach).

Nie można synchronizować ani przenosić/kopiować kluczy między regionami; można jedynie zdefiniować zasady umożliwiające dostęp między regionami.

Wyliczenie

aws kms list-keys
aws kms list-key-policies --key-id <id>
aws kms list-grants --key-id <id>
aws kms describe-key --key-id <id>
aws kms get-key-policy --key-id <id> --policy-name <name> # Default policy name is "default"
aws kms describe-custom-key-stores

Eskalacja uprawnień

pageAWS - KMS Privesc

Po eksploatacji

pageAWS - KMS Post Exploitation

Trwałość

pageAWS - KMS Persistence

Odnośniki

Zdobądź wiedzę na temat hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousAWS - IAM, Identity Center & SSO EnumNextAWS - Lambda Enum

Last updated