gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-07 02:03:45 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2025-10-07 09:13:03 +00:00
parent f227c0a531
commit c1fb92c9e1
2 changed files with 167 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
View File

@@ -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)