Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Jerarquía de la Organización

Cuentas

En AWS existe una cuenta raíz, que es el contenedor principal para todas las cuentas de tu organización. Sin embargo, no es necesario utilizar esa cuenta para implementar recursos, puedes crear otras cuentas para separar diferentes infraestructuras de AWS entre ellas.

Esto es muy interesante desde un punto de vista de seguridad, ya que una cuenta no podrá acceder a recursos de otra cuenta (a menos que se creen puentes específicamente), de esta manera puedes crear límites entre despliegues.

Por lo tanto, existen dos tipos de cuentas en una organización (estamos hablando de cuentas de AWS y no de cuentas de usuario): una cuenta única designada como la cuenta de gestión, y una o más cuentas de miembro.

  • La cuenta de gestión (la cuenta raíz) es la cuenta que utilizas para crear la organización. Desde la cuenta de gestión de la organización, puedes hacer lo siguiente:

  • Crear cuentas en la organización

  • Invitar a otras cuentas existentes a la organización

  • Eliminar cuentas de la organización

  • Gestionar invitaciones

  • Aplicar políticas a entidades (raíces, OUs o cuentas) dentro de la organización

  • Habilitar la integración con servicios de AWS compatibles para proporcionar funcionalidad de servicio en todas las cuentas de la organización.

  • Es posible iniciar sesión como usuario raíz utilizando el correo electrónico y la contraseña utilizados para crear esta cuenta raíz/organización.

La cuenta de gestión tiene las responsabilidades de una cuenta pagadora y es responsable de pagar todos los cargos acumulados por las cuentas de miembro. No se puede cambiar la cuenta de gestión de una organización.

  • Las cuentas de miembro conforman todas las demás cuentas en una organización. Una cuenta puede ser miembro de solo una organización a la vez. Puedes adjuntar una política a una cuenta para aplicar controles solo a esa cuenta.

  • Las cuentas de miembro deben utilizar una dirección de correo electrónico válida y pueden tener un nombre, en general no podrán gestionar la facturación (pero podrían tener acceso a ella).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Unidades de Organización

Las cuentas pueden agruparse en Unidades de Organización (OU). De esta manera, puedes crear políticas para la Unidad de Organización que se van a aplicar a todas las cuentas hijas. Ten en cuenta que una OU puede tener otras OUs como hijos.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Política de Control de Servicios (SCP)

Una política de control de servicios (SCP) es una política que especifica los servicios y acciones que los usuarios y roles pueden utilizar en las cuentas que la SCP afecta. Las SCP son similares a las políticas de permisos IAM excepto que no otorgan ningún permiso. En cambio, las SCP especifican los permisos máximos para una organización, unidad organizativa (OU) o cuenta. Cuando adjuntas una SCP a la raíz de tu organización o a una OU, la SCP limita los permisos para las entidades en las cuentas miembro.

Esta es la ÚNICA forma en que incluso el usuario raíz puede ser detenido de hacer algo. Por ejemplo, podría usarse para evitar que los usuarios deshabiliten CloudTrail o eliminen copias de seguridad. La única forma de evitar esto es comprometiendo también la cuenta maestra que configura las SCP (la cuenta maestra no puede ser bloqueada).

Ten en cuenta que las SCPs solo restringen a los principales en la cuenta, por lo que otras cuentas no se ven afectadas. Esto significa que si una SCP niega s3:GetObject, no impedirá que las personas accedan a un bucket S3 público en tu cuenta.

Ejemplos de SCP:

  • Denegar por completo la cuenta raíz

  • Solo permitir regiones específicas

  • Solo permitir servicios en lista blanca

  • Denegar que se deshabiliten GuardDuty, CloudTrail y el acceso público a S3

  • Denegar que se eliminen o modifiquen roles de seguridad/incidencias

  • Denegar que se eliminen copias de seguridad

  • Denegar la creación de usuarios IAM y claves de acceso

Encuentra ejemplos en formato JSON en https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

ARN

Amazon Resource Name es el nombre único que tiene cada recurso dentro de AWS, se compone de la siguiente manera:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Hay 4 particiones en AWS pero solo 3 formas de llamarlas:

  • AWS Standard: aws

  • AWS China: aws-cn

  • AWS US public Internet (GovCloud): aws-us-gov

  • AWS Secret (US Classified): aws

IAM - Identidad y Gestión de Acceso

IAM es el servicio que te permitirá gestionar Autenticación, Autorización y Control de Acceso dentro de tu cuenta de AWS.

  • Autenticación - Proceso de definir una identidad y la verificación de esa identidad. Este proceso se puede subdividir en: Identificación y verificación.

  • Autorización - Determina a qué puede acceder una identidad dentro de un sistema una vez que ha sido autenticada en él.

  • Control de Acceso - El método y proceso de cómo se otorga acceso a un recurso seguro.

IAM se puede definir por su capacidad para gestionar, controlar y gobernar los mecanismos de autenticación, autorización y control de acceso de identidades a tus recursos dentro de tu cuenta de AWS.

Usuario raíz de la cuenta de AWS

Cuando creas por primera vez una cuenta de Amazon Web Services (AWS), comienzas con una identidad de inicio de sesión única que tiene acceso completo a todos los servicios y recursos de AWS en la cuenta. Este es el usuario raíz de la cuenta de AWS y se accede iniciando sesión con la dirección de correo electrónico y la contraseña que utilizaste para crear la cuenta.

Ten en cuenta que un nuevo usuario administrador tendrá menos permisos que el usuario raíz.

Desde un punto de vista de seguridad, se recomienda crear otros usuarios y evitar usar este.

Usuarios IAM

Un usuario IAM es una entidad que creas en AWS para representar a la persona o aplicación que lo utiliza para interactuar con AWS. Un usuario en AWS consta de un nombre y credenciales (contraseña y hasta dos claves de acceso).

Cuando creas un usuario IAM, le otorgas permisos haciéndolo miembro de un grupo de usuarios que tiene políticas de permisos apropiadas adjuntas (recomendado), o adjuntando directamente políticas al usuario.

Los usuarios pueden tener MFA habilitado para iniciar sesión a través de la consola. Los tokens de API de usuarios con MFA habilitado no están protegidos por MFA. Si deseas restringir el acceso de las claves API de un usuario utilizando MFA debes indicar en la política que para realizar ciertas acciones se necesita MFA (ejemplo aquí).

CLI

  • ID de Clave de Acceso: 20 caracteres alfanuméricos en mayúsculas aleatorios como AKHDNAPO86BSHKDIRYT

  • ID de Clave de Acceso Secreta: 40 caracteres aleatorios en mayúsculas y minúsculas: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (No es posible recuperar claves de acceso secretas perdidas).

Si necesitas cambiar la Clave de Acceso este es el proceso que debes seguir: Crear una nueva clave de acceso -> Aplicar la nueva clave al sistema/aplicación -> marcar la original como inactiva -> Probar y verificar que la nueva clave de acceso funciona -> Eliminar la antigua clave de acceso

MFA - Autenticación Multifactor

Se utiliza para crear un factor adicional para la autenticación además de tus métodos existentes, como la contraseña, creando así un nivel de autenticación multifactorial. Puedes usar una aplicación virtual gratuita o un dispositivo físico. Puedes usar aplicaciones como la autenticación de Google de forma gratuita para activar un MFA en AWS.

Las políticas con condiciones de MFA se pueden adjuntar a lo siguiente:

  • Un usuario o grupo IAM

  • Un recurso como un bucket de Amazon S3, una cola de Amazon SQS o un tema de Amazon SNS

  • La política de confianza de un rol IAM que puede ser asumido por un usuario

Si deseas acceder a través de CLI a un recurso que verifica MFA debes llamar a GetSessionToken. Eso te dará un token con información sobre MFA. Ten en cuenta que las credenciales de AssumeRole no contienen esta información.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Como se indica aquí, hay muchos casos diferentes donde no se puede usar MFA.

Grupos de usuarios IAM

Un grupo de usuarios IAM es una forma de adjuntar políticas a múltiples usuarios al mismo tiempo, lo que puede facilitar la gestión de los permisos para esos usuarios. Los roles y grupos no pueden formar parte de un grupo.

Puede adjuntar una política basada en identidad a un grupo de usuarios para que todos los usuarios en el grupo de usuarios reciban los permisos de la política. No puede identificar un grupo de usuarios como un Principal en una política (como una política basada en recursos) porque los grupos se relacionan con permisos, no con autenticación, y los principales son entidades IAM autenticadas.

Aquí hay algunas características importantes de los grupos de usuarios:

  • Un grupo de usuarios puede contener muchos usuarios, y un usuario puede pertenecer a varios grupos.

  • Los grupos de usuarios no pueden estar anidados; solo pueden contener usuarios, no otros grupos de usuarios.

  • No hay un grupo de usuarios predeterminado que incluya automáticamente a todos los usuarios en la cuenta de AWS. Si desea tener un grupo de usuarios así, debe crearlo y asignar a cada nuevo usuario a él.

  • El número y tamaño de los recursos IAM en una cuenta de AWS, como el número de grupos y el número de grupos de los que un usuario puede ser miembro, están limitados. Para obtener más información, consulte Cuotas de IAM y AWS STS.

Roles IAM

Un rol IAM es muy similar a un usuario, en el sentido de que es una identidad con políticas de permisos que determinan lo que puede y no puede hacer en AWS. Sin embargo, un rol no tiene credenciales (contraseña o claves de acceso) asociadas. En lugar de estar asociado de forma única con una persona, se pretende que un rol sea asumible por cualquier persona que lo necesite (y tenga suficientes permisos). Un usuario IAM puede asumir un rol temporalmente para asumir diferentes permisos para una tarea específica. Un rol puede ser asignado a un usuario federado que inicia sesión utilizando un proveedor de identidades externo en lugar de IAM.

Un rol IAM consta de dos tipos de políticas: Una política de confianza, que no puede estar vacía, define quién puede asumir el rol, y una política de permisos, que no puede estar vacía, define a qué puede acceder.

Servicio de tokens de seguridad de AWS (STS)

El Servicio de tokens de seguridad de AWS (STS) es un servicio web que facilita la emisión de credenciales temporales y con privilegios limitados. Está específicamente diseñado para:

Credenciales temporales en IAM

Las credenciales temporales se utilizan principalmente con roles IAM, pero también tienen otros usos. Puede solicitar credenciales temporales que tengan un conjunto de permisos más restringido que su usuario IAM estándar. Esto evita que realice accidentalmente tareas no permitidas por las credenciales más restringidas. Una ventaja de las credenciales temporales es que caducan automáticamente después de un período de tiempo establecido. Usted tiene control sobre la duración en que las credenciales son válidas.

Políticas

Permisos de política

Se utilizan para asignar permisos. Hay 2 tipos:

  • Políticas administradas por AWS (preconfiguradas por AWS)

  • Políticas administradas por el cliente: Configuradas por usted. Puede crear políticas basadas en políticas administradas por AWS (modificando una de ellas y creando la suya), utilizando el generador de políticas (una vista GUI que le ayuda a otorgar y denegar permisos) o escribiendo la suya propia.

Por defecto, el acceso está denegado, el acceso se concederá si se ha especificado un rol explícito. Si existe un único "Denegar", anulará el "Permitir", excepto para las solicitudes que utilizan las credenciales de seguridad raíz de la cuenta de AWS (que están permitidas de forma predeterminada).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Los campos globales que se pueden usar para condiciones en cualquier servicio están documentados aquí. Los campos específicos que se pueden usar para condiciones por servicio están documentados aquí.

Políticas en línea

Este tipo de políticas se asignan directamente a un usuario, grupo o rol. Entonces, no aparecen en la lista de Políticas como cualquier otro que se pueda usar. Las políticas en línea son útiles si deseas mantener una estricta relación uno a uno entre una política y la identidad a la que se aplica. Por ejemplo, deseas asegurarte de que los permisos en una política no se asignen inadvertidamente a una identidad distinta a la prevista. Cuando usas una política en línea, los permisos de la política no pueden adjuntarse inadvertidamente a la identidad incorrecta. Además, cuando utilizas la Consola de administración de AWS para eliminar esa identidad, las políticas incrustadas en la identidad también se eliminan. Esto se debe a que son parte de la entidad principal.

Políticas de cubo de recursos

Estas son políticas que se pueden definir en recursos. No todos los recursos de AWS las admiten.

Si un principal no tiene una denegación explícita sobre ellas, y una política de recursos les otorga acceso, entonces se les permite.

Límites de IAM

Los límites de IAM se pueden usar para limitar los permisos a los que un usuario o rol debería tener acceso. De esta manera, incluso si se otorga un conjunto diferente de permisos al usuario mediante una política diferente, la operación fallará si intenta usarlos.

Un límite es simplemente una política adjunta a un usuario que indica el nivel máximo de permisos que el usuario o rol puede tener. Entonces, incluso si el usuario tiene acceso de administrador, si el límite indica que solo puede leer los buckets de S3, ese es el máximo que puede hacer.

Esto, SCPs y seguir el principio de privilegio mínimo son las formas de controlar que los usuarios no tengan más permisos de los que necesitan.

Políticas de sesión

Una política de sesión es una política establecida cuando se asume un rol de alguna manera. Esto será como un límite de IAM para esa sesión: Esto significa que la política de sesión no otorga permisos, sino que los restringe a los indicados en la política (siendo los máximos permisos los que tiene el rol).

Esto es útil para medidas de seguridad: Cuando un administrador va a asumir un rol muy privilegiado, podría restringir los permisos solo a los indicados en la política de sesión en caso de que la sesión se vea comprometida.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Tenga en cuenta que por defecto AWS podría agregar políticas de sesión a las sesiones que se van a generar debido a terceras razones. Por ejemplo, en roles asumidos de cognito no autenticados por defecto (usando autenticación mejorada), AWS generará credenciales de sesión con una política de sesión que limita los servicios a los que la sesión puede acceder a la siguiente lista.

Por lo tanto, si en algún momento se encuentra con el error "... porque ninguna política de sesión permite el...", y el rol tiene acceso para realizar la acción, es porque hay una política de sesión que lo está impidiendo.

Federación de Identidad

La federación de identidad permite a los usuarios de proveedores de identidad externos a AWS acceder de forma segura a los recursos de AWS sin tener que proporcionar credenciales de usuario de AWS desde una cuenta de IAM válida. Un ejemplo de un proveedor de identidad puede ser su propio Active Directory de Microsoft (a través de SAML) o servicios de OpenID (como Google). El acceso federado permitirá entonces a los usuarios dentro de él acceder a AWS.

Para configurar esta confianza, se genera un Proveedor de Identidad de IAM (SAML u OAuth) que confiará en la otra plataforma. Luego, al menos un rol de IAM se asigna (confiando) al Proveedor de Identidad. Si un usuario de la plataforma de confianza accede a AWS, lo hará como el rol mencionado.

Sin embargo, generalmente se querrá asignar un rol diferente dependiendo del grupo del usuario en la plataforma de terceros. Entonces, varios roles de IAM pueden confiar en el Proveedor de Identidad de terceros y la plataforma de terceros será la que permita a los usuarios asumir uno u otro rol.

Centro de Identidad IAM

El Centro de Identidad IAM de AWS (sucesor de AWS Single Sign-On) amplía las capacidades de Gestión de Identidad y Acceso de AWS (IAM) para proporcionar un lugar central que reúne la administración de usuarios y su acceso a las cuentas de AWS y aplicaciones en la nube.

El dominio de inicio de sesión será algo como <user_input>.awsapps.com.

Para iniciar sesión, hay 3 fuentes de identidad que se pueden utilizar:

  • Directorio del Centro de Identidad: Usuarios regulares de AWS

  • Active Directory: Admite diferentes conectores

  • Proveedor de Identidad Externo: Todos los usuarios y grupos provienen de un Proveedor de Identidad externo (IdP)

En el caso más simple del directorio del Centro de Identidad, el Centro de Identidad tendrá una lista de usuarios y grupos y podrá asignar políticas a ellos para cualquiera de las cuentas de la organización.

Para dar acceso a un usuario/grupo del Centro de Identidad a una cuenta, se creará un Proveedor de Identidad SAML que confíe en el Centro de Identidad, y se creará un rol que confíe en el Proveedor de Identidad con las políticas indicadas en la cuenta de destino.

AwsSSOInlinePolicy

Es posible dar permisos a roles creados a través del Centro de Identidad IAM mediante políticas en línea. Los roles creados en las cuentas que reciben políticas en línea en el Centro de Identidad IAM de AWS tendrán estos permisos en una política en línea llamada AwsSSOInlinePolicy.

Por lo tanto, incluso si ve 2 roles con una política en línea llamada AwsSSOInlinePolicy, no significa que tengan los mismos permisos.

Confianzas y Roles entre Cuentas Cruzadas

Un usuario (confiante) puede crear un Rol entre Cuentas Cruzadas con algunas políticas y luego, permitir que otro usuario (de confianza) acceda a su cuenta pero solo teniendo el acceso indicado en las nuevas políticas de rol. Para crear esto, simplemente cree un nuevo Rol y seleccione Rol entre Cuentas Cruzadas. Los Roles para Acceso entre Cuentas Cruzadas ofrecen dos opciones. Proporcionar acceso entre cuentas de AWS que posee y proporcionar acceso entre una cuenta que posee y una cuenta de AWS de un tercero. Se recomienda especificar el usuario que se confía y no poner algo genérico porque de lo contrario, otros usuarios autenticados como usuarios federados también podrán abusar de esta confianza.

AWS Simple AD

No es compatible con:

  • Relaciones de Confianza

  • Centro de Administración de AD

  • Soporte completo de API de PS

  • Papel de Servicio Administrado de Grupo

  • Extensiones de Esquema

  • Sin acceso directo al SO o a las Instancias

Federación Web o Autenticación OpenID

La aplicación utiliza el AssumeRoleWithWebIdentity para crear credenciales temporales. Sin embargo, esto no otorga acceso a la consola de AWS, solo acceso a recursos dentro de AWS.

Otras opciones de IAM

  • Puede establecer una política de contraseña con opciones como longitud mínima y requisitos de contraseña.

  • Puede descargar un "Informe de Credenciales" con información sobre las credenciales actuales (como la hora de creación del usuario, si la contraseña está habilitada...). Puede generar un informe de credenciales tan a menudo como una vez cada cuatro horas.

La Gestión de Identidad y Acceso de AWS (IAM) proporciona un control de acceso detallado en toda AWS. Con IAM, puede especificar quién puede acceder a qué servicios y recursos, y bajo qué condiciones. Con las políticas de IAM, administra los permisos de su personal y sistemas para garantizar permisos de privilegio mínimo.

Prefijos de ID de IAM

En esta página puede encontrar los prefijos de ID de IAM de las claves según su naturaleza:

Permisos recomendados para auditar cuentas

Los siguientes privilegios otorgan varios accesos de lectura de metadatos:

  • arn:aws:iam::aws:policy/SecurityAudit

  • arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

  • codebuild:ListProjects

  • config:Describe*

  • cloudformation:ListStacks

  • logs:DescribeMetricFilters

  • directconnect:DescribeConnections

  • dynamodb:ListTables

Misceláneo

Autenticación de CLI

Para que un usuario regular se autentique en AWS a través de la CLI, necesita tener credenciales locales. Por defecto, puede configurarlas manualmente en ~/.aws/credentials o ejecutando aws configure. En ese archivo puede tener más de un perfil, si no se especifica un perfil utilizando la CLI de AWS, se usará el llamado [default] en ese archivo. Ejemplo de archivo de credenciales con más de 1 perfil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Si necesitas acceder a diferentes cuentas de AWS y tu perfil tiene acceso para asumir un rol dentro de esas cuentas, no necesitas llamar manualmente a STS cada vez (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) y configurar las credenciales.

Puedes usar el archivo ~/.aws/config para indicar qué roles asumir, y luego usar el parámetro --profile como de costumbre (la asunción de rol se realizará de forma transparente para el usuario). Un ejemplo de archivo de configuración:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Con este archivo de configuración, puedes usar aws cli de la siguiente manera:

aws --profile acc2 ...

Si estás buscando algo similar a esto pero para el navegador, puedes revisar la extensión AWS Extend Switch Roles.

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

AnteriorAWS PentestingSiguienteAWS - Federation Abuse

Última actualización