AWS - KMS Enum

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

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.

KMS - Usługa Zarządzania Kluczami

AWS Key Management Service (AWS KMS) jest przedstawiana jako zarządzana usługa, upraszczająca proces dla użytkowników w tworzeniu i zarządzaniu kluczami głównymi klientów (CMK). Te CMK są integralne w szyfrowaniu danych użytkowników. Cechą wyróżniającą AWS KMS jest to, że CMK są głównie zabezpieczone przez moduły bezpieczeństwa sprzętowego (HSM), co zwiększa ochronę kluczy szyfrujących.

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

KMS jest usługą specyficzną dla regionu.

Administratorzy w Amazonie nie mają dostępu do twoich kluczy. Nie mogą odzyskać twoich kluczy i nie pomagają w szyfrowaniu twoich kluczy. AWS po prostu zarządza systemem operacyjnym i podstawową aplikacją, to od nas zależy zarządzanie naszymi kluczami szyfrującymi i tym, jak te klucze są używane.

Klucze Główne Klienta (CMK): Mogą szyfrować dane o rozmiarze do 4KB. Zwykle są używane do tworzenia, szyfrowania i deszyfrowania DEK (Kluczy Szyfrujących Danych). Następnie DEK są używane do szyfrowania danych.

Klucz główny klienta (CMK) jest logiczną reprezentacją 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. Kiedy tworzysz CMK, domyślnie AWS KMS generuje materiał klucza dla tego CMK. Możesz jednak zdecydować się na utworzenie CMK bez materiału klucza, a następnie zaimportować własny materiał klucza do tego CMK.

Istnieją 2 typy kluczy głównych:

• CMK zarządzane przez AWS: Używane przez inne usługi do szyfrowania danych. Są używane przez usługę, która je utworzyła w danym regionie. Są tworzone po raz pierwszy, gdy wdrażasz szyfrowanie w tej usłudze. Rotują co 3 lata i nie ma możliwości ich zmiany.
• CMK zarządzane przez klienta: Elastyczność, rotacja, konfigurowalny dostęp i polityka klucza. Włączanie i wyłączanie kluczy.

Szyfrowanie w Kopercie w kontekście Usługi Zarządzania Kluczami (KMS): System hierarchii dwóch poziomów do szyfrowania danych za pomocą klucza danych, a następnie szyfrowania klucza danych za pomocą klucza głównego.

Polityki Kluczy

Te definiują kto może używać i uzyskiwać dostęp do klucza w KMS.

Domyślnie:

• Daje IAM konta AWS, które posiada klucz KMS dostęp do zarządzania dostępem do klucza KMS za pośrednictwem IAM.

W przeciwieństwie do innych polityk zasobów AWS, polityka klucza KMS AWS nie przyznaje automatycznie uprawnień żadnemu z podmiotów konta. Aby przyznać uprawnienia administratorom konta, polityka klucza musi zawierać wyraźne oświadczenie przyznające te uprawnienia, takie jak to.

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

• Pozwala kontu używać polityk IAM do zezwolenia na dostęp do klucza KMS, oprócz polityki klucza.

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

• Zmniejsza ryzyko, że klucz stanie się niezarządzalny poprzez przyznanie uprawnień do kontroli dostępu administratorom konta, w tym użytkownikowi głównemu konta, którego nie można usunąć.

Przykład domyślnej polityki:

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

Warning

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

Administratorzy kluczy

Administratorzy kluczy domyślnie:

• Mają dostęp do zarządzania KMS, ale nie do szyfrowania ani deszyfrowania danych
• Tylko użytkownicy IAM i role mogą być dodawani do listy administratorów kluczy (nie grupy)
• Jeśli używany jest zewnętrzny CMK, administratorzy kluczy mają uprawnienia do importowania materiału klucza

Rotacja CMK

• Im dłużej ten sam klucz pozostaje na miejscu, tym więcej danych jest szyfrowanych tym kluczem, a jeśli ten klucz zostanie naruszony, tym szerszy obszar danych jest narażony na ryzyko. Dodatkowo, im dłużej klucz jest aktywny, tym większe prawdopodobieństwo jego naruszenia.
• KMS rotuje klucze klientów co 365 dni (lub możesz przeprowadzić ten proces ręcznie, kiedy chcesz) oraz klucze zarządzane przez AWS co 3 lata, a tego czasu nie można zmienić.
• Starsze klucze są zachowywane do deszyfrowania danych, które zostały zaszyfrowane przed rotacją
• W przypadku naruszenia, rotacja klucza nie usunie zagrożenia, ponieważ możliwe będzie deszyfrowanie wszystkich danych zaszyfrowanych skompromitowanym kluczem. Jednak nowe dane będą szyfrowane nowym kluczem.
• Jeśli CMK jest w stanie wyłączonym lub oczekującym usunięcia, KMS nie przeprowadzi rotacji klucza, dopóki CMK nie zostanie ponownie włączony lub usunięcie nie zostanie anulowane.

Ręczna rotacja

• Nowy CMK musi być utworzony, następnie tworzony jest nowy CMK-ID, więc będziesz musiał zaktualizować każdą aplikację, aby odnosiła się do nowego CMK-ID.
• Aby ułatwić ten proces, możesz używać aliasów do odniesienia się do identyfikatora klucza i następnie po prostu zaktualizować klucz, do którego odnosi się alias.
• Musisz zachować stare klucze, aby deszyfrować stare pliki zaszyfrowane tym kluczem.

Możesz importować klucze z własnej infrastruktury kluczy w siedzibie.

Inne istotne informacje KMS

KMS jest wyceniane na podstawie liczby żądań szyfrowania/deszyfrowania otrzymanych od wszystkich usług miesięcznie.

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

Dzięki polityce KMS możesz 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 tylko do szyfrowania, tylko do deszyfrowania lub obu
• Zdefiniować, aby umożliwić systemom dostęp do kluczy w różnych regionach (chociaż nie jest to zalecane, ponieważ awaria w regionie hostującym KMS wpłynie na dostępność systemów w innych regionach).

Nie możesz synchronizować ani przenosić/kopiować kluczy między regionami; możesz tylko zdefiniować zasady, aby umożliwić dostęp między regionami.

Enumeracja

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

# This script enumerates AWS KMS keys across all available regions.
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
echo -e "\n### Region: $region ###"; aws kms list-keys --region $region --query "Keys[].KeyId" --output text | tr '\t' '\n';
done

Privesc

AWS - KMS Privesc

Post Exploitation

AWS - KMS Post Exploitation

Persistence

AWS - KMS Persistence

References

• https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html

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

• Sprawdź subscription plans!
• Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.