mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 05:33:10 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -4,21 +4,21 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Für weitere Informationen über IAM-Zugriff:
|
||||
Für weitere Informationen zum IAM-Zugriff:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Verwirrtes Stellvertreterproblem
|
||||
## Confused Deputy Problem
|
||||
|
||||
Wenn Sie **einem externen Konto (A)** den Zugriff auf eine **Rolle** in Ihrem Konto erlauben, haben Sie wahrscheinlich **0 Sichtbarkeit** darüber, **wer genau auf dieses externe Konto zugreifen kann**. Das ist ein Problem, denn wenn ein anderes externes Konto (B) auf das externe Konto (A) zugreifen kann, ist es möglich, dass **B auch auf Ihr Konto zugreifen kann**.
|
||||
If you **allow an external account (A)** to access a **role** in your account, you will probably have **0 visibility** on **who can exactly access that external account**. This is a problem, because if another external account (B) can access the external account (A) it's possible that **B will also be able to access your account**.
|
||||
|
||||
Daher ist es möglich, beim Erlauben eines externen Kontos den Zugriff auf eine Rolle in Ihrem Konto eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenfolge, die das externe Konto (A) **angeben muss**, um **die Rolle in Ihrer Organisation zu übernehmen**. Da das **externe Konto B diese Zeichenfolge nicht kennt**, wird es, selbst wenn es Zugriff auf A hat, **nicht in der Lage sein, auf Ihre Rolle zuzugreifen**.
|
||||
Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Beachten Sie jedoch, dass diese `ExternalId` "Geheimnis" **kein Geheimnis** ist; jeder, der die IAM-Rollenübernahme-Richtlinie **lesen kann, wird sie sehen können**. Solange das externe Konto A es kennt, das externe Konto **B es jedoch nicht kennt**, **verhindert es, dass B A missbraucht, um auf Ihre Rolle zuzugreifen**.
|
||||
However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**.
|
||||
|
||||
Beispiel:
|
||||
```json
|
||||
@@ -39,11 +39,11 @@ Beispiel:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Damit ein Angreifer einen verwirrten Stellvertreter ausnutzen kann, muss er irgendwie herausfinden, ob die Prinzipale des aktuellen Kontos Rollen in anderen Konten impersonieren können.
|
||||
> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er herausfinden, ob principals des aktuellen Kontos Rollen in anderen Konten übernehmen können.
|
||||
|
||||
### Unerwartete Vertrauensstellungen
|
||||
### Unerwartete Vertrauensbeziehungen
|
||||
|
||||
#### Wildcard als Prinzipal
|
||||
#### Wildcard als Principal
|
||||
```json
|
||||
{
|
||||
"Action": "sts:AssumeRole",
|
||||
@@ -51,9 +51,9 @@ Beispiel:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Diese Richtlinie **erlaubt allen AWS**, die Rolle zu übernehmen.
|
||||
Diese Richtlinie **ermöglicht allen AWS**, die Rolle zu übernehmen.
|
||||
|
||||
#### Dienst als Hauptakteur
|
||||
#### Service als Principal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -62,9 +62,9 @@ Diese Richtlinie **erlaubt allen AWS**, die Rolle zu übernehmen.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Diese Richtlinie **erlaubt jedem Konto**, ihr apigateway so zu konfigurieren, dass es diese Lambda aufruft.
|
||||
Diese Richtlinie **erlaubt jedem Account**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
|
||||
|
||||
#### S3 als Hauptakteur
|
||||
#### S3 als principal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Diese Richtlinie **erlaubt jedem Konto**, ihr apigateway so zu konfigurieren, da
|
||||
}
|
||||
}
|
||||
```
|
||||
Wenn ein S3-Bucket als Principal angegeben wird, da S3-Buckets keine Account-ID haben, wenn Sie **Ihren Bucket gelöscht haben und der Angreifer** ihn in seinem eigenen Konto erstellt hat, könnte er dies ausnutzen.
|
||||
Wenn ein S3 bucket als principal angegeben ist — da S3 buckets keine Account ID haben — und du **deinen Bucket gelöscht hast und der Angreifer ihn** in seinem eigenen Account erstellt hat, könnte er dies missbrauchen.
|
||||
|
||||
#### Nicht unterstützt
|
||||
```json
|
||||
@@ -84,9 +84,82 @@ Wenn ein S3-Bucket als Principal angegeben wird, da S3-Buckets keine Account-ID
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Ein gängiger Weg, um Probleme mit verwirrten Stellvertretern zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Ursprungs-ARN zu überprüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).
|
||||
Eine übliche Methode, um Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Condition mit `AWS:SourceArn`, um die originierende ARN zu prüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).
|
||||
|
||||
## Referenzen
|
||||
### Löschen von Anmeldeinformationen
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur Zugangsschlüssel, Login-Profile, SSH-Schlüssel, dienstspezifische Zugangsdaten, Instance-Profile, Zertifikate oder CloudFront-Public-Keys entfernen bzw. Rollen von Instance-Profilen trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu Denial-of-Service oder zum Verlust des Zugangs für Systeme führen, die von diesen Anmeldeinformationen abhängen. Daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
|
||||
```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
|
||||
```
|
||||
### Löschung von Identitäten
|
||||
Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und so Identitäten sowie zugehörige Spuren entfernen. Das kann sofort den Zugriff für Personen und Dienste, die von diesen Identitäten abhängen, unterbrechen und zu denial-of-service oder zum Verlust des Zugriffs führen. Daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
|
||||
```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>
|
||||
```
|
||||
###
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur verwaltete oder Inline-Richtlinien löschen oder trennen, Policy-Versionen oder Berechtigungsgrenzen entfernen und Richtlinien von Benutzern, Gruppen oder Rollen entkoppeln. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene Identitäten sofort den Zugriff verlieren oder ein Denial-of-Service erleiden; daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
|
||||
```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>
|
||||
```
|
||||
### Löschen föderierter Identitäten
|
||||
Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client-IDs entfernen. Dadurch wird die föderierte Authentifizierung unterbrochen, die Token-Validierung verhindert und Benutzern und Diensten, die auf SSO angewiesen sind, sofort der Zugriff verweigert, bis der IdP oder die Konfigurationen wiederhergestellt sind.
|
||||
```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
|
||||
```
|
||||
### Unbefugte MFA-Aktivierung
|
||||
Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und dadurch den legitimen Benutzer am Anmelden hindern. Sobald ein unautorisiertes MFA aktiviert ist, kann der Benutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Wenn mehrere MFA-Geräte registriert sind, reicht für die Anmeldung nur eines, sodass dieser Angriff keinen Effekt auf das Verweigern des Zugriffs hat).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Manipulation von Zertifikat-/Schlüsselmetadaten
|
||||
Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Kennzeichnen von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Anmeldeinformationen abhängen, was zu Verlust des Zugriffs oder der Verfügbarkeit führt.
|
||||
```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/
|
||||
```
|
||||
## Quellen
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
|
||||
@@ -10,15 +10,15 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-kms-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Informationen verschlüsseln/entschlüsseln
|
||||
### Verschlüsseln/Entschlüsseln von Informationen
|
||||
|
||||
`fileb://` und `file://` sind URI-Schemata, die in AWS CLI-Befehlen verwendet werden, um den Pfad zu lokalen Dateien anzugeben:
|
||||
`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
|
||||
|
||||
- `fileb://:` Liest die Datei im Binärmodus, häufig verwendet für Nicht-Textdateien.
|
||||
- `file://:` Liest die Datei im Textmodus, typischerweise verwendet für einfache Textdateien, Skripte oder JSON, das keine speziellen Kodierungsanforderungen hat.
|
||||
- `fileb://:` Liest die Datei im Binärmodus, wird häufig für Nicht-Text-Dateien verwendet.
|
||||
- `file://:` Liest die Datei im Textmodus, typischerweise verwendet für Textdateien, Skripte oder JSON, die keine spezielle Kodierung erfordern.
|
||||
|
||||
> [!TIP]
|
||||
> Beachten Sie, dass die Datei, wenn Sie einige Daten in einer Datei entschlüsseln möchten, die binären Daten enthalten muss, nicht base64-kodierte Daten. (fileb://)
|
||||
> Beachte, dass, wenn du Daten in einer Datei entschlüsseln möchtest, die Datei die binären Daten enthalten muss, nicht base64-kodierte Daten. (fileb://)
|
||||
|
||||
- Verwendung eines **symmetrischen** Schlüssels
|
||||
```bash
|
||||
@@ -60,14 +60,14 @@ aws kms decrypt \
|
||||
```
|
||||
### KMS Ransomware
|
||||
|
||||
Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS-Richtlinie der Schlüssel ändern und **seinem Konto Zugriff darauf gewähren**, während der Zugriff des legitimen Kontos entfernt wird.
|
||||
Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS-Policy von Schlüsseln ändern und **seinem Account Zugriff darauf gewähren**, wodurch der Zugriff für den legitimen Account entfernt wird.
|
||||
|
||||
Dann können die Benutzer des legitimen Kontos auf keine Informationen von Diensten zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, was eine einfache, aber effektive Ransomware über das Konto schafft.
|
||||
Dann können die Nutzer des legitimen Accounts auf keine Informationen von Diensten zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, wodurch ein einfaches, aber effektives Ransomware-Szenario für den Account entsteht.
|
||||
|
||||
> [!WARNING]
|
||||
> Beachten Sie, dass **AWS verwaltete Schlüssel nicht von diesem Angriff betroffen sind**, nur **vom Kunden verwaltete Schlüssel**.
|
||||
|
||||
> Beachten Sie auch die Notwendigkeit, den Parameter **`--bypass-policy-lockout-safety-check`** zu verwenden (das Fehlen dieser Option in der Webkonsole macht diesen Angriff nur über die CLI möglich).
|
||||
> Beachte, dass **AWS managed keys aren't affected**; betroffen sind nur **Customer managed keys**.
|
||||
>
|
||||
> Beachte außerdem die Notwendigkeit, den Parameter **`--bypass-policy-lockout-safety-check`** zu verwenden (das Fehlen dieser Option in der Web-Konsole macht diesen Angriff nur über die CLI möglich).
|
||||
```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]
|
||||
> Beachten Sie, dass Sie, wenn Sie diese Richtlinie ändern und nur einem externen Konto Zugriff gewähren, und dann von diesem externen Konto aus versuchen, eine neue Richtlinie festzulegen, um **den Zugriff auf das ursprüngliche Konto zurückzugeben, dies nicht möglich sein wird, da die Put Policy-Aktion nicht von einem anderen Konto aus durchgeführt werden kann**.
|
||||
> Beachten Sie, dass wenn Sie diese Richtlinie ändern und nur einem externen Konto Zugriff gewähren, und dann von diesem externen Konto aus versuchen, eine neue Richtlinie zu setzen, um den Zugriff an das ursprüngliche Konto zurückzugeben, Sie dazu nicht in der Lage sein werden, da die Put Polocy-Aktion nicht von einem Cross-Account ausgeführt werden kann.
|
||||
|
||||
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Generische KMS-Ransomware
|
||||
### Generic KMS Ransomware
|
||||
|
||||
#### Globale KMS-Ransomware
|
||||
Es gibt eine andere Möglichkeit, ein globales KMS Ransomware umzusetzen, die die folgenden Schritte umfasst:
|
||||
|
||||
Es gibt einen weiteren Weg, um eine globale KMS-Ransomware durchzuführen, der die folgenden Schritte umfasst:
|
||||
- Erstellen Sie einen neuen **Schlüssel mit Schlüsselmaterial**, das vom Angreifer importiert wurde
|
||||
- **Ältere Daten erneut verschlüsseln**, die beim Opfer mit der vorherigen Version verschlüsselt wurden, mit der neuen
|
||||
- **Den KMS-Schlüssel löschen**
|
||||
- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln
|
||||
|
||||
- Erstellen Sie einen neuen **Schlüssel mit einem vom Angreifer importierten Schlüsselmaterial**
|
||||
- **Re-verschlüsseln Sie ältere Daten**, die mit der vorherigen Version verschlüsselt wurden, mit der neuen.
|
||||
- **Löschen Sie den KMS-Schlüssel**
|
||||
- Jetzt könnte nur der Angreifer, der das ursprüngliche Schlüsselmaterial hat, die verschlüsselten Daten entschlüsseln
|
||||
### Delete Keys via kms:DeleteImportedKeyMaterial
|
||||
|
||||
### Schlüssel zerstören
|
||||
Mit der Berechtigung `kms:DeleteImportedKeyMaterial` kann ein Akteur das importierte Schlüsselmaterial aus CMKs mit `Origin=EXTERNAL` löschen (CMKs, die ihr Schlüsselmaterial importiert haben) und sie dadurch unfähig machen, Daten zu entschlüsseln. Diese Aktion ist destruktiv und irreversibel, sofern nicht kompatibles Material erneut importiert wird, und ermöglicht es einem Angreifer, effektiv einen ransomware-ähnlichen Datenverlust zu verursachen, indem verschlüsselte Informationen dauerhaft unzugänglich gemacht werden.
|
||||
```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>
|
||||
```
|
||||
### Keys zerstören
|
||||
|
||||
Durch das Zerstören von keys kann ein DoS verursacht werden.
|
||||
```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]
|
||||
> Beachten Sie, dass AWS jetzt **verhindert, dass die vorherigen Aktionen von einem anderen Konto aus durchgeführt werden:**
|
||||
> Beachte, dass AWS jetzt **verhindert, dass die vorherigen Aktionen von einem Cross-Account ausgeführt werden:**
|
||||
|
||||
### Alias ändern oder löschen
|
||||
Dieser Angriff löscht oder leitet AWS KMS-Aliase um, bricht die Schlüsselauflösung und verursacht sofortige Ausfälle in allen Diensten, die auf diese Aliase angewiesen sind, was zu einem denial-of-service führt. Mit Berechtigungen wie `kms:DeleteAlias` oder `kms:UpdateAlias` kann ein Angreifer Aliase entfernen oder umleiten und kryptografische Operationen (z. B. encrypt, describe) stören. Jeder Dienst, der das Alias statt der Key ID referenziert, kann ausfallen, bis das Alias wiederhergestellt oder korrekt neu zugewiesen wurde.
|
||||
```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>
|
||||
```
|
||||
### Löschung des Schlüssels abbrechen
|
||||
Mit Berechtigungen wie `kms:CancelKeyDeletion` und `kms:EnableKey` kann ein Akteur die geplante Löschung eines AWS KMS customer master key abbrechen und diesen später wieder aktivieren. Dadurch wird der Schlüssel wiederhergestellt (anfangs im Disabled-Zustand) und seine Fähigkeit zur Entschlüsselung zuvor geschützter Daten wiederhergestellt, was exfiltration ermöglicht.
|
||||
```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>
|
||||
```
|
||||
### Disable Key
|
||||
Mit der Berechtigung `kms:DisableKey` kann ein Akteur einen AWS KMS customer master key deaktivieren und dessen Verwendung für Verschlüsselung oder Entschlüsselung verhindern. Das unterbricht den Zugriff für alle Dienste, die von diesem CMK abhängen, und kann sofortige Störungen verursachen oder zu einem denial-of-service führen, bis der Schlüssel wieder aktiviert wird.
|
||||
```bash
|
||||
aws kms disable-key \
|
||||
--key-id <key_id>
|
||||
```
|
||||
### Derive Shared Secret
|
||||
Mit der Berechtigung `kms:DeriveSharedSecret` kann ein Akteur einen in KMS gehaltenen privaten Schlüssel zusammen mit einem vom Benutzer bereitgestellten öffentlichen Schlüssel verwenden, um ein gemeinsames Geheimnis per ECDH zu berechnen.
|
||||
```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
|
||||
Mit der Berechtigung `kms:Sign` kann ein Akteur einen in KMS gespeicherten CMK verwenden, um Daten kryptografisch zu signieren, ohne den privaten Schlüssel offenzulegen. Dabei entstehen gültige Signaturen, die impersonation ermöglichen oder bösartige Aktionen autorisieren können.
|
||||
```bash
|
||||
aws kms sign \
|
||||
--key-id <key-id> \
|
||||
--message fileb://<ruta-al-archivo> \
|
||||
--signing-algorithm <algoritmo> \
|
||||
--message-type RAW
|
||||
```
|
||||
### DoS with Custom Key Stores
|
||||
Mit Berechtigungen wie `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` oder `kms:UpdateCustomKeyStore` kann ein Akteur einen AWS KMS Custom Key Store (CKS) ändern, trennen oder löschen und dadurch dessen Master-Schlüssel unbrauchbar machen. Das bricht Verschlüsselungs-, Entschlüsselungs- und Signiervorgänge für alle Dienste, die auf diesen Schlüsseln basieren, und kann eine sofortige denial-of-service verursachen. Daher ist es entscheidend, diese Berechtigungen einzuschränken und zu überwachen.
|
||||
```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