# AWS - IAM Post Exploitation {{#include ../../../banners/hacktricks-training.md}} ## IAM Für weitere Informationen zum IAM-Zugriff: {{#ref}} ../aws-services/aws-iam-enum.md {{#endref}} ## Confused Deputy Problem 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**. 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**.
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 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "Example Corp's AWS Account ID" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "12345" } } } } ``` > [!WARNING] > Damit ein Angreifer einen confused deputy ausnutzen kann, muss er herausfinden, ob principals des aktuellen Kontos Rollen in anderen Konten übernehmen können. ### Unerwartete Vertrauensbeziehungen #### Wildcard als Principal ```json { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "AWS": "*" } } ``` Diese Richtlinie **ermöglicht allen AWS**, die Rolle zu übernehmen. #### Service als Principal ```json { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": "apigateway.amazonaws.com" }, "Resource": "arn:aws:lambda:000000000000:function:foo" } ``` Diese Richtlinie **erlaubt jedem Account**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft. #### S3 als principal ```json "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } ``` 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 { "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" } ``` 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). ### 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 \ --access-key-id AKIAIOSFODNN7EXAMPLE ## Remove ssh key of a user aws iam delete-ssh-public-key \ --user-name \ --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 # Delete a group aws iam delete-group \ --group-name # Delete a role aws iam delete-role \ --role-name ``` ### 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 \ --policy-name # Delete a role policy aws iam delete-role-policy \ --role-name \ --policy-name ``` ### 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 \ --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 \ --ssh-public-key-id APKAEIBAERJR2EXAMPLE \ --status Inactive aws iam update-server-certificate \ --server-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) {{#include ../../../banners/hacktricks-training.md}}