Hello Hackers!
En el presente articulo, estaremos exponiendo diferentes conceptos necesarios para llevar a cabo una auditoria de seguridad sobre el entorno de AWS.

IAM

IAM es una forma de administrar el acceso a los servicios y recursos de AWS de forma segura. Todo se reduce a los permisos.
IAM es una forma de administrar permisos para acceder a sus recursos en la nube. Estos permisos se asignan a entidades. Las entidades son cosas a las que puede asignar permisos.

Hay 3 entidades posibles en IAM:

• Usuarios
• Grupos
• Roles

Un usuario es una representación de la persona o el servicio que interactúa con AWS.
Un grupo es una colección de usuarios de IAM.

Ambos conceptos son bastante intuitivos y similares a los que se encuentran en otros entornos como Active Directory.

Un rol similar al de un usuario, ya que es una identidad con políticas de permisos que determinan lo que la identidad puede y no puede hacer en AWS. Sin embargo, un rol no tiene credenciales asociadas (contraseña o claves de acceso). En lugar de estar asociado de manera única con una persona, un rol debe ser asumido por cualquiera que lo necesite.
Para mas informacion leer el siguiente articulo!

La mayoría de estas definiciones provienen de la documentación oficial de AWS. Pero aquí es donde se complica un poco más. Si Usted desea asignar permisos a entidades a través de políticas. Debe tener en cuenta, que las políticas se podrian clasificar en:

• Políticas administradas
• Políticas en línea (En otras palabras, Políticas no administradas)

La diferencia entre ellas es que las políticas administradas son políticas independientes, definidas por sí mismas. No están asociados con ninguna entidad específica y se pueden adjuntar a múltiples entidades.

Las políticas en línea (o políticas no administradas) son políticas que están integradas en una identidad de IAM (un usuario, grupo o rol). La política es una parte inherente de la identidad. No se puede asignar a ninguna otra entidad. Piense en ellos como un atributo específico de una entidad. Las políticas administradas se recomiendan sobre las políticas en línea porque son más fáciles de administrar y auditar. Puede tener mil usuarios con la misma política administrada y un cambio en la política los afectaría a todos. Solo tendría que auditar esa política. Si tuviera políticas en línea para cada usuario, tendría que auditar 1000 políticas diferentes y no tendría forma de modificarlas todas a la vez. Hay una distinción más que debe tener en cuenta. Las políticas administradas también se pueden dividir en dos categorías:

• Políticas administradas (llamémoslas políticas administradas por AWS para eliminar la ambigüedad)
• Políticas administradas por el cliente

La diferencia es simple. AWS administra las políticas administradas. Definen roles comunes que puede necesitar y no puede modificarlos.

Las políticas administradas por el cliente son políticas que crea y administra el cliente. Puede definir políticas personalizadas, adaptadas a sus necesidades específicas.

Políticas administradas por Amazon AWS

Otra distinción que puede hacer es entre:

• Políticas basadas en identidad
• Políticas basadas en recursos

Las identidades son cosas a las que puede asignar políticas basadas en identidades. Estos se asignan a usuarios, grupos y roles.

Existe otro tipo de políticas llamadas políticas basadas en recursos, que solo se pueden asignar a los recursos. Piense en cosas como los servicios de AWS (buckets S3, queues SQS, etc.). Además, instancias EC2. Siempre que tenga un recurso que necesite permisos específicos para realizar una tarea, puede utilizar políticas basadas en recursos.

Hay una cosa que debes saber y es muy importante. Se pueden otorgar permisos a los recursos a través de políticas basadas en recursos (directamente adjuntas), así como a través de roles. Al principio dije que los roles pueden ser asumidos por cualquiera que lo necesite. Esto también incluye instancias y servicios de AWS. Para mas informacion leer el siguiente articulo!

Conceptos necesarios para realizar un pivoting en entornos cloud bajo AWS

Siempre que desee que una instancia tenga ciertos permisos, puede otorgarle permisos para asumir un rol específico. Esto se llama rol de instancia. Puede aplicar solo un rol a una instancia, pero puede tener varias instancias con el mismo rol. Las credenciales temporales asociadas con este rol se guardan en lo que se denomina metadatos de instancia. Puede acceder a estos metadatos desde el interior de la instancia haciendo una solicitud HTTP a la siguiente ruta:

curl http://169.254.169.254/latest/meta-data/iam-credentials/role-name

Obteniendo credenciales del rol de la instancia

Esta solicitud puede realizarla cualquier usuario dentro de la instancia. Si la función de la instancia tiene altos privilegios asociados, cualquier usuario con acceso a la instancia puede secuestrarla.

Esto también abre un nuevo vector de explotación para redireccionamientos abiertos/vulnerabilidades SSRF. Si encuentra uno en la instancia, puede solicitar sus metadatos y apropiarse de ese rol.

La mayoría de las explotaciones que involucran metadatos se pueden prevenir usando Metadata Service V2, pero rara vez vemos esta característica implementada.

Suponiendo que puede obtener una AccesKey, una SecretAccessKey y un ExpirationToken, querrá enumerar sus permisos disponibles y encontrar una manera de mantener el acceso porque estas credenciales tienen una fecha de vencimiento (como puede ver en la imagen) y existe la posibilidad de que no se renovarán. Por defecto, este tiempo es de una hora, ¡así que lo mejor es que te des prisa! La mejor herramienta actualmente para hacer esto es enumerate-iam.py ( https://github.com/andresriancho/enumerate-iam ), desarrollada por Andres Riancho. Puede usarlo así (el token de sesión es opcional).

enumerate-iam.py --access-key ACCESSKEY --secret-key SECRETKEY --session-token AWS_SESSION_TOKEN

Resultado de enumerate-iam.py

Herramientas de enumeración de IAM

Ahora que entendemos cómo funciona la mayor parte de IAM, podemos empezar a aprender a enumerarlo.

Enumeración CLI

Obteniendo las políticas administradas a disposición de un usuario especifico.
Para poder obtener los detalles de cada política, se necesita la versión de la política y el arn de la política. Una forma para obtener el arn de las políticas disponibles para su perfil es utilizando el siguiente comando:

aws --profile PERFIL_DE_USUARIO iam list-policies | jq -r ".Policies[].Arn"

Obteniendo los ARN de las politicas disponibles de un perfil

Para obtener la versión de una política específica se puede ejecutar el siguiente comando.

aws --profile PERFIL_DE_USUARIO iam get-policy --policy-arn NOMBRE_DE_POLITICA --query "Policy.DefaultVersionId" --output text

Obteniendo la version de una politica por medio del ARN

Existe la posibilidad de agrupar estos dos comandos para obtener toda la configuración relevante con:

profile="test"; for i in $(aws --profile PERFIL_DE_USUARIO iam list-policies | jq -r '.Policies[].Arn'); do echo "Describiendo la politica NOMBRE_DE_POLITICA" && aws --profile PERFIL_DE_USUARIO iam get-policy-version --policy-arn NOMBRE_DE_POLITICA --version-id $(aws --profile PERFIL_DE_USUARIO iam get-policy --policy-arn NOMBRE_DE_POLITICA --query 'Policy.DefaultVersionId' --output text); done | tee /tmp/policies.log

Enumeracion de politicas

Como se puede apreciar, cada política se compone de:

• Efecto (los cuales pueden ser: permitir/denegar)
• Accion (lo cual indica la operación que se puede realizar)
• Recurso (el cual corresponde al ARN del recurso afectado por la operación).

Por ejemplo, la politica con altos privilegios se puede apreciar de la siguiente manera:

// Describing policy arn:aws:iam::aws:policy/AdministratorAccess

{
    "PolicyVersion": {
        "Document": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Action": "*",
                    "Resource": "*"
                }
            ]
        },
        "VersionId": "v1",
        "IsDefaultVersion": true,
        "CreateDate": "2015-02-06T18:39:46Z"
    }
}

Identificando las entidades que tienen adjuntada alguna política especifica

#Listando politicas de usuario

aws --profile "test" iam list-user-policies --user-name "test-user"

#Listando politicas de grupo

aws --profile "test" iam list-group-policies --group-name "test-group"

#Listando politicas de roles

aws --profile "test" iam list-role-policies --role-name "test-role"

Enumeracion de politicas de usuarios especificos

Si deseamos tener una informacion mas detallada acerca dichas polticias podemos usar los siguientes comandos:

#Politicas con su Informacion detallada para un usuario especifico 

aws --profile "test" iam get-user-policy --user-name "test-user" --policy-name "test-policy"

#Politicas con su Informacion detallada para un grupo especifico

aws --profile "test" iam get-group-policy --group-name "test-group" --policy-name "test-policy"

#Politicas con su Informacion detallada para un rol especifico

aws --profile "test" iam get-role-policy --role-name "test-role" --policy-name "test-policy"

Analizando una politica especifica de un usuarios

Relaciones de confianza

Cuando se crean roles, tienen una característica llamada relaciones de confianza.
En otras palabras, existe la posibilidad de que hallan politicas que asuman roles.
Una política de asumir roles se vería así.

{"AssumeRolePolicyDocument": { 
            "Versión": "2012-10-17", 
            "Statement": [ 
                { 
                    "Effect": "Allow", 
                    "Principal": { 
                        "Service": "ec2.amazonaws.com" 
                    }, 
                    " Acción ":" sts: AssumeRole " 
                } 
            ] 
        }
}        

Es posible consultar la “politica de asumir roles” asociada con un rol especifico con el siguiente comando:

aws --profile "test" iam get-role --role-name "test-role"

Identificando la accion AssumeRole para un rol de IAM

Por ejemplo:
la política de asumir roles permite que cualquier recurso ec2 asuma el rol.
Cabe resaltar, que esto no significa que pueda asumir el rol desde cualquier instancia de ec2.
Es necesario, un administrador para que:

1. Cree un perfil de instancia.
2. Asocie el rol a ese perfil de instancia
3. Asocie el perfil de instancia con la instancia específica que desea utilizar.

Suponiendo que el rol ya ha sido creado y que ya tiene adjuntada la política interesante, los comandos que necesitaría ejecutar para realizar estos 3 pasos serían:

aws iam create-instance-profile --instance-profile-name NuevoRol-ParaPerfil-DeInstancia

aws iam add-role-to-instance-profile --role-name Rol-A-Asignar --instance-profile-name NuevoRol-ParaPerfil-DeInstancia

aws ec2 associate-iam-instance-profile --instance-id Id-Instancia --iam-instance-profile Name=NuevoRol-ParaPerfil-DeInstancia

Para mas informacion leer el siguiente articulo!

Algo que recomiendo para las auditorias de seguridad de caja blanca es ejecutar el siguiente comando dentro de las instancias.

aws --profile test sts get-caller-identity

El WHOAMI para AWS

También es posible ver el rol de una instancia con un servicio web de metadatos, que solo esta disponible desde la misma instancia:

curl http://169.254.169.254/latest/meta-data/iam-credentials/

Para finalizar, me gustaria relacionar los siguientes links:
Como hacer una auditoria de seguridad para entornos cloud con Prowler
Blog oficial de RhinoSecurity

Previous Post

Como realizar una auditoria a una base de datos de Oracle

Next Post

Utilizando Cloud Container Attack Tool (CCAT)