
Escanea configuraciones de IAM de AWS en busca de shadow admins detectando políticas de denegación mal configuradas que no restringen las acciones de los usuarios sobre grupos, permitiendo la detección y remediación de escalada de privilegios.
Escanea tu configuración de AWS IAM en busca de administradores sombra en AWS IAM basados en políticas de denegación mal configuradas que no afectan a los usuarios en grupos, descubiertas por el equipo de investigación de seguridad de Lightspin.
La herramienta detecta las configuraciones incorrectas en los siguientes objetos de IAM:
Políticas administradas
Políticas en línea de usuarios
Políticas en línea de grupos
Políticas en línea de roles
La lógica de evaluación de AWS IAM para políticas de denegación aplicadas a grupos no funciona de la misma manera que la mayoría de los ingenieros de seguridad podrían estar acostumbrados con otros mecanismos de autorización.
Supongamos que una política con un recurso de grupo tiene una denegación explícita. En ese caso, esto solo afectará las acciones del grupo y no las acciones del usuario, exponiendo a las organizaciones a configuraciones incorrectas y vulnerabilidades si asumen que el proceso es el mismo que con Active Directory, por ejemplo.
Ejemplo de política json vulnerable:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectManagersByDeny",
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::123456789999:group/managers"
}
]
}
En este ejemplo, la política debería denegar cualquier acción de iam realizada por usuarios, grupos o roles con esa política adjunta, hacia el grupo llamado managers.
El hecho es que una simple acción de IAM como iam:ChangePassword funcionaría ya que la política de denegación es ineficaz.
Enlace al blog completo de investigación de seguridad
AWS IAM tiene una clara separación entre las acciones de objetos de usuario y las acciones de objetos de grupo.
La siguiente lista incluye las acciones de objetos de usuario que la herramienta escanea sobre políticas de denegación que afectan a grupos (además de comodín):
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"]
Muchas de las acciones de objetos de usuario mencionadas anteriormente pueden conducir fácilmente a una escalada de privilegios o comprometer la cuenta, como restablecer la contraseña del administrador, desactivar el MFA de la cuenta raíz, y más.
Red-Shadow está construido con Python 3 y Boto3.
La herramienta requiere:
sudo git clone https://github.com/lightspin-tech/red-shadow.git
cd red-shadow
pip3 install -r requirements.txt
python3 red-shadow.py
Los resultados descubren cualquier objeto de IAM que sea vulnerable a dicha omisión de autorización en AWS.
Ejemplo de salida de resultados:
++ 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
En esta salida de consola, podemos ver que nuestra política de denegación ProtectManagers es ineficaz y vulnerable a ataques como la escalada de privilegios mencionada anteriormente.
Para validar la vulnerabilidad de IAM y ejecutar la explotación, puedes seguir el siguiente flujo:
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 BobAttackerExplotemos la vulnerabilidad usando:
aws iam create-access-key --user-name JohnAdmin --profile BobAttacker
¡Escalada de privilegios completa!
Una vez que hayas encontrado las políticas vulnerables a la omisión de autorización, hay dos formas posibles de mitigar la vulnerabilidad y corregir la política:
OPCIÓN 1: Define todos los usuarios relevantes en el campo de recurso en lugar de grupos para evitar acciones de iam ineficaces, y deniega todas las acciones de grupo, como en el siguiente ejemplo:
{
"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"
}
]
}
OPCIÓN 2: Usa una condición en la política con iam:ResourceTag en su lugar, como en el siguiente ejemplo:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"iam:CreateLoginProfile",
"iam:ChangePassword",
"iam:CreateAccessKey"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:ResourceTag/group": "managers"
}
}
}
]
}
Esta investigación fue realizada por el equipo de investigación de seguridad de Lightspin. Para más información, contáctanos en [email protected].
Este repositorio está disponible bajo la Licencia Apache 2.0.