AWS - IAM Post Exploitation

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

IAM

Für mehr Informationen über IAM-Zugriff:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

Wenn Sie einem externen Konto (A) erlauben, auf eine role in Ihrem Account zuzugreifen, haben Sie vermutlich 0 Sichtbarkeit darüber, wer genau auf dieses externe Konto zugreifen kann. Das ist ein Problem, denn wenn ein anderes externes Konto (B) Zugriff auf das externe Konto (A) hat, ist es möglich, dass B auch auf Ihr Konto zugreifen kann.

Deshalb ist es beim Zulassen eines externen Kontos zum Zugriff auf eine role in Ihrem Account möglich, eine ExternalId anzugeben. Dies ist ein “geheimer” String, den das externe Konto (A) angeben muss, um die role in Ihrer Organisation zu übernehmen. Da das externe Konto B diesen String nicht kennt, wird es selbst bei Zugriff auf A nicht in der Lage sein, auf Ihre role zuzugreifen.

Beachten Sie jedoch, dass dieses ExternalId-“Geheimnis” kein Geheimnis ist — jeder, der die IAM assume role policy lesen kann, wird es sehen können. Aber solange das externe Konto A es kennt, das externe Konto B es jedoch nicht kennt, verhindert es, dass B A missbraucht, um auf Ihre role zuzugreifen.

Beispiel:

{
"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 auf irgendeine Weise herausfinden, ob Principals des aktuellen Accounts Rollen in anderen Accounts übernehmen bzw. sich als diese Rollen ausgeben können.

Unerwartete Vertrauensstellungen

Wildcard als Principal

{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}

Diese Richtlinie erlaubt allen AWS, die Rolle zu übernehmen.

Service als Principal

{
"Action": "lambda:InvokeFunction",
"Effect": "Allow",
"Principal": { "Service": "apigateway.amazonaws.com" },
"Resource": "arn:aws:lambda:000000000000:function:foo"
}

Diese Richtlinie erlaubt jedem Konto, apigateway so zu konfigurieren, dass dieses Lambda aufgerufen wird.

S3 als Principal

"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 — könnten Angreifer dies ausnutzen, wenn du deinen bucket gelöscht hast und der attacker ihn in seinem eigenen Account erstellt hat.

Nicht unterstützt

{
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}

Eine gängige Methode, Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit AWS:SourceArn, um die Ursprungs-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 Zugriffsschlüssel, Login-Profile, SSH-Schlüssel, dienstspezifische Anmeldeinformationen, Instance-Profile, Zertifikate oder CloudFront public keys entfernen bzw. Rollen von Instance-Profilen trennen. Solche Aktionen können sofort legitime Benutzer und Anwendungen blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Anmeldeinformationen abhängen, daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.

# 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öschen 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 und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die auf diese Identitäten angewiesen sind, wodurch ein Denial-of-Service oder ein Zugriffsverlust entstehen kann. Daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.

# 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 managed/inline policies löschen oder abtrennen, policy versions oder permissions boundaries entfernen und policies von Benutzern, Gruppen oder Rollen entkoppeln. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, was zu einem sofortigen Verlust des Zugriffs oder zu einem Denial-of-Service für principals führen kann, die von diesen policies abhängig waren. Daher müssen diese IAM actions streng eingeschränkt und überwacht werden.

# 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-Identity-Provider löschen oder Client-IDs entfernen. Dadurch wird die föderierte Authentifizierung unterbrochen, die Token-Validierung verhindert und der Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, sofort verweigert, bis der IdP oder die Konfigurationen wiederhergestellt sind.

# 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

Illegitime MFA-Aktivierung

Mit iam:EnableMFADevice kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und so verhindern, dass sich der berechtigte Benutzer anmeldet. Sobald ein nicht autorisiertes MFA-Gerät 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 zur Anmeldung eines davon; hat dieser Angriff daher keine Wirkung bei der Verhinderung des Zugriffs).

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Manipulation von Zertifikats-/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. Indem er Schlüssel/Zertifikate als inaktiv markiert oder Verweise verändert, kann er die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Zugangsdaten abhängen, was zu Zugriffsverlust oder Verfügbarkeitsausfällen führt.

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/

iam:Delete*

Die IAM-Wildcard iam:Delete* ermöglicht das Entfernen vieler Arten von IAM-Ressourcen — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. — und hat daher ein sehr großes Schadenspotenzial: ein Akteur mit iam:Delete* kann Identitäten, Anmeldeinformationen, Richtlinien und zugehörige Artefakte dauerhaft zerstören, Audit-/Beweismaterial entfernen und Dienstausfälle oder Betriebsunterbrechungen verursachen. Einige Beispiele sind

# Delete a user
aws iam delete-user --user-name <Username>

# Delete a role
aws iam delete-role --role-name <RoleName>

# Delete a managed policy
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>

iam:EnableMFADevice

Ein Akteur, dem die iam:EnableMFADevice-Aktion gewährt wurde, kann ein MFA-Gerät für eine Identität im Account registrieren, vorausgesetzt, der Benutzer hatte noch keines aktiviert. Dies kann genutzt werden, um den Zugriff eines Benutzers zu stören: Sobald ein attacker ein MFA-Gerät registriert hat, kann der berechtigte Benutzer daran gehindert werden, sich anzumelden, da er das vom attacker registrierte MFA nicht kontrolliert.

Dieser Denial-of-access-Angriff funktioniert nur, wenn der Benutzer kein MFA registriert hatte; registriert der attacker ein MFA-Gerät für diesen Benutzer, wird der berechtigte Benutzer bei allen Flows ausgeschlossen, die dieses neue MFA voraussetzen. Hat der Benutzer bereits ein oder mehrere MFA-Geräte unter seiner Kontrolle, blockiert das Hinzufügen eines vom attacker kontrollierten MFA den berechtigten Benutzer nicht — er kann sich weiterhin mit jedem bereits vorhandenen MFA authentifizieren.

Um ein MFA-Gerät für einen Benutzer zu aktivieren (registrieren), könnte ein attacker ausführen:

aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks