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 :