AWS - IAM Post Exploitation

Reading time: 7 minutes

IAM

Für weitere Informationen zum IAM-Zugriff:

AWS - IAM, Identity Center & SSO Enum

Confused Deputy Problem

Wenn Sie einem externen Account (A) erlauben, auf eine Rolle in Ihrem Account zuzugreifen, werden Sie wahrscheinlich keine Sichtbarkeit darüber haben, wer genau auf diesen externen Account zugreifen kann. Das ist ein Problem, denn wenn ein anderer externer Account (B) auf den externen Account (A) zugreifen kann, ist es möglich, dass B ebenfalls auf Ihr Konto zugreifen kann.

Daher ist es möglich, beim Zulassen eines externen Accounts für den Zugriff auf eine Rolle in Ihrem Account eine ExternalId anzugeben. Dies ist eine "geheime" Zeichenfolge, die der externe Account (A) angeben muss, um die Rolle in Ihrer Organisation anzunehmen. Da der externe Account B diese Zeichenfolge nicht kennt, kann er selbst wenn er Zugriff auf A hat nicht auf Ihre Rolle zugreifen.

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 der externe Account A es kennt, der externe Account B es nicht kennt, verhindert es, dass B A missbraucht, um auf Ihre Rolle 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"
}
}
}
}

Unerwartete Vertrauensstellungen

Wildcard als Principal

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

Diese Richtlinie ermöglicht es allen AWS, die Rolle zu übernehmen.

Dienst als Principal

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

Diese Richtlinie ermöglicht jedem Konto, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.

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, und du deinen Bucket gelöscht hast und der Angreifer ihn in seinem eigenen Account erstellt hat, dann könnte er das ausnutzen.

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 Herkunfts-ARN zu prüfen. Allerdings unterstützen einige Dienste das möglicherweise nicht (z. B. CloudTrail laut einigen Quellen).

Löschen von Zugangsdaten

Mit einer der folgenden Berechtigungen — iam:DeleteAccessKey, iam:DeleteLoginProfile, iam:DeleteSSHPublicKey, iam:DeleteServiceSpecificCredential, iam:DeleteInstanceProfile, iam:DeleteServerCertificate, iam:DeleteCloudFrontPublicKey, iam:RemoveRoleFromInstanceProfile — kann ein Akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates oder CloudFront public keys entfernen bzw. Rollen von instance profiles trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Credentials 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

Identitätslöschung

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 damit Identitäten und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die von diesen Identitäten abhängen, was zu denial-of-service oder zu Zugriffsverlust führen kann, daher müssen diese IAM actions 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-Versionen oder permissions boundaries entfernen und Policies von Benutzern, Gruppen oder Rollen abkoppeln. Das zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene principals sofort den Zugriff verlieren oder ein Denial-of-Service eintreten kann; diese IAM-Aktionen müssen daher 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-Identitätsanbieter löschen oder Client‑IDs entfernen. Das unterbricht die föderierte Authentifizierung, verhindert die Token‑Validierung und verweigert sofort den Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, 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

Unberechtigte MFA-Aktivierung

Mit iam:EnableMFADevice kann ein Angreifer ein MFA-Gerät auf der Identität eines Nutzers registrieren und dadurch den legitimen Nutzer am Anmelden hindern. Sobald ein nicht autorisiertes MFA aktiviert ist, kann der Nutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Sind mehrere MFA-Geräte registriert, ist für die Anmeldung nur eines erforderlich, sodass dieser Angriff keine Wirkung hat, den Zugang zu verweigern).

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. Durch das Markieren 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 Dienste, die auf diesen Anmeldeinformationen basieren, sofort stören, was zu Verlust von Zugriff oder Verfügbarkeit 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/

Quellen

• https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html