8.2 KiB
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:
{
"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
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": { "AWS": "*" }
}
Diese Richtlinie ermöglicht 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 Account, 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, könnte er dies missbrauchen.
Nicht unterstützt
{
"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.
# 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.
# 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.
# 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.
# 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).
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.
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
{{#include ../../../banners/hacktricks-training.md}}