¿Roles aquí? ¿Roles allí? ¡Roles en todas partes! Explorando la seguridad de AWS IAM Roles Anywhere

Resumen ejecutivo

A medida que las organizaciones dependen cada vez más de aplicaciones, dispositivos y servicios para interactuar en entornos híbridos, las identidades no humanas se están volviendo cada vez más comunes. A fin de permitir el acceso seguro de estas identidades dentro de la organización, Amazon Web Services (AWS) ha presentado el servicio AWS Identity and Access Management (IAM) Roles Anywhere, que permite a las cargas de trabajo fuera de AWS autenticarse con certificados digitales, en lugar de las tradicionales claves de acceso.

El servicio IAM Roles Anywhere de AWS ofrece a las organizaciones varias ventajas de seguridad y es relativamente sencillo de configurar, sobre todo para una organización que ya disponga de una infraestructura de clave pública (PKI). Por lo general, la implementación de este servicio requiere que las organizaciones tengan en cuenta los privilegios mínimos y los permisos de acceso a la hora de diseñar la infraestructura. Si no se aplican los controles de seguridad adecuados y las arquitecturas prácticas de defensa en profundidad, una organización podría exponer inadvertidamente su entorno de nube a riesgos no deseados.

En este artículo, exploramos los principales riesgos asociados a una configuración o un diseño de arquitectura inadecuados al utilizar el servicio de Roles Anywhere. Estos riesgos tienen una causa común. La configuración predeterminada del servicio es relativamente permisiva dentro del contexto de la cuenta de AWS y de la región, donde el servicio está configurado para su uso.

Analizamos estos riesgos desde la perspectiva de un actor de amenazas y desde la perspectiva de una organización. Esta exploración debería ayudar a los lectores a comprender mejor los riesgos potenciales que entraña el diseño del uso de este servicio y cómo las organizaciones pueden mitigarlos.

Cortex Cloud proporciona protecciones contra los errores de configuración de la PKI detallados en este artículo. Mediante el uso de reglas basadas en el agente Cloud XDR y de reglas analíticas de comportamiento para detectar cuándo las políticas de IAM se están utilizando incorrectamente, Cortex Cloud es capaz de detectar y prevenir operaciones maliciosas con las capacidades de automatización de la plataforma XSOAR.

Las organizaciones pueden obtener ayuda para evaluar la postura de seguridad en la nube a través de la Evaluación de seguridad en la nube de Unit 42.

Si cree que su seguridad podría haber sido comprometida o si tiene un asunto urgente, póngase en contacto con el equipo de respuesta a incidentes de Unit 42.

Introducción

Roles Anywhere es un servicio de gestión de accesos que se presentó en el año 2022. Permite a las cargas de trabajo externas autenticarse en AWS mediante certificados digitales X.509. Esta capacidad elimina la necesidad de crear y administrar credenciales a largo plazo en dichas cargas de trabajo y, en última instancia, hace que las operaciones de API en la nube sean más seguras y fáciles de administrar en los entornos de AWS.

En pocas palabras, Roles Anywhere puede utilizarse para definir qué certificados de autoridad de certificación (CA) pueden validar los certificados de clientes. El certificado de cliente firmado por una CA de este tipo puede utilizarse para lo siguiente:

• Autenticarse en AWS
• Intercambiar la identidad basada en certificado por una identidad nativa de la nube correspondiente (expresada como un conjunto de credenciales temporales)
• Llamar a las API de la nube de AWS con normalidad al firmar las solicitudes con esas credenciales temporales de AWS

Componentes y conceptos clave

El proceso de autenticación consta de los siguientes componentes básicos:

• Anclas de confianza: un ancla de confianza es el recurso que representa el certificado de CA en Roles Anywhere. Cuando se crea un ancla de confianza, se le debe adjuntar un certificado de CA. Existen dos tipos de anclas de confianza:
  • Certificado Certificate Manager-Private Certificate Authority de AWS (ACM-PCA): es un recurso administrado de AWS.
  • Certificado Bundle: un certificado X.509 codificado en formato ASCII de correo de privacidad mejorada (PEM) que se adjunta directamente al ancla de confianza.
• Perfiles: son recursos que determinan el nivel de acceso de una entidad autenticada con Roles Anywhere. Los perfiles se asignan con roles de gestión de identidades y accesos (IAM) que definen los permisos y con mecanismos adicionales para ajustar los permisos.
• Roles de IAM: los roles de IAM se asignan con las políticas de IAM reales que conceden (o eliminan) permisos.

En la práctica, la autenticación mediante Roles Anywhere se realiza al enviar una solicitud al endpoint /sessions. La solicitud se firma con la clave privada del certificado y se toman como parámetros el nombre de recurso de Amazon (ARN) del ancla de confianza y los ARN del perfil y el rol.

Una forma sencilla de componer la solicitud es con la herramienta aws_signing_helper. Esta herramienta automatiza el proceso de autenticación y también puede hacer que las credenciales estén disponibles localmente al emular el endpoint del servicio de metadatos de instancias de forma muy similar a cómo funcionan las instancias de Amazon Elastic Compute Cloud (EC2).

En la Figura 2, se muestran ejemplos de solicitudes y respuestas utilizando Roles Anywhere.

Uso regular de Roles Anywhere

A fin de comprender mejor el flujo de configuración de Roles Anywhere, considere el siguiente escenario:

• Un pod de Kubernetes externo a AWS necesita acceso para leer objetos en un bucket de Simple Storage Service (S3).
• El ingeniero de la nube emite un certificado y lo firma con el certificado del ancla de confianza. A continuación, el certificado firmado se almacena en el pod, junto con su clave privada.
• El ingeniero crea un rol de IAM que incluye los permisos S3 relevantes y lo adjunta a un perfil de Roles Anywhere.
• El pod de Kubernetes ahora puede utilizar el certificado, así como sus credenciales de rol asociadas, junto con la clave para firmar, autenticar y leer objetos dentro del bucket de S3 configurado.

Asegurar el proceso de autenticación por defecto

Un aspecto interesante de este proceso de autenticación es que, por defecto, no existe una correlación entre el ancla de confianza y un perfil específico. Es crucial que las organizaciones comprendan los riesgos que implica esta configuración y configuren los recursos de Roles Anywhere y las políticas de confianza de roles de IAM en consecuencia.

En otras palabras, las organizaciones deben configurar un certificado de cliente para que esté firmado por un ancla de confianza específico y destinado a un perfil específico. Esto impedirá el acceso desde cualquier otro perfil y ancla de confianza en la misma cuenta y región de AWS.

Para demostrar las posibles consecuencias de este proceso, consideremos el escenario del pod descrito anteriormente. Hasta aquí, los pasos del flujo son legítimos. En esencia, el pod tiene los permisos exactos que necesita.

Pero, ¿y si un atacante consigue acceder al pod? Si se crearon otros perfiles en la misma cuenta y región de AWS, el atacante podría utilizar el certificado para obtener acceso a los roles de estos perfiles:

• El atacante deduce los ARN de otro rol de IAM que está adjunto al mismo perfil o los ARN y los roles adjuntos de otro perfil. Deducir estos ARN es una tarea compleja que requiere permisos adicionales en el entorno de AWS. Analizamos estas técnicas másadelante en este artículo.
• Una vez obtenida toda la información necesaria, el atacante puede formular peticiones para obtener credenciales de diferentes roles y utilizar sus permisos para realizar operaciones maliciosas.

AWS ofrece varias formas para limitar el acceso desde Roles Anywhere con condiciones en la política de confianza del rol. Sin embargo, la política de confianza predeterminada de Roles Anywhere no tiene ninguna condición en su declaración, lo que significa que cualquier entorno que utilice la política predeterminada no impone limitaciones de acceso. Es responsabilidad de la organización asegurarse de que no está utilizando configuraciones predeterminadas para las configuraciones de Roles Anywhere.

Cuando se crea un rol por defecto que se utiliza para Roles Anywhere, se establece la siguiente política de confianza:

Esta política establece que este rol puede ser asumido por el servicio de Roles Anywhere. Sin embargo, no existen otras restricciones para las fuentes que pueden asumirlo. Esto significa que, si se asigna un rol a un perfil, cualquier certificado firmado por un ancla de confianza en la misma región puede asumir este rol.

Para solucionarlo, AWS creó la sección Condición en la política. Las condiciones permiten imponer restricciones adicionales a los recursos, especificando los requisitos que estos deben cumplir para llevar a cabo una acción.

La siguiente política añade la sección Condición sobre la política por defecto para limitar el acceso de la autenticación Roles Anywhere al rol, solo desde un ancla de confianza específica.

Para limitar aún más el acceso de los certificados firmados, recomendamos aprovechar la asignación de atributos de certificado. AWS también lo recomienda en la documentación de Roles Anywhere:

Básicamente, es posible asignar los atributos de un certificado a valores que se evaluarán en la política de confianza. Se puede utilizar para especificar el acceso a roles en función del nombre común del certificado, la unidad organizativa o cualquier otro atributo del certificado.

Se recomienda porque, si un recurso que utiliza Roles Anywhere para la autenticación se ve comprometido, se garantiza que no podrá acceder a roles adicionales.

La siguiente condición utiliza la condición de ancla de confianza de la última sección y también limita el acceso en función de los atributos del certificado:

Al igual que con cualquier otro servicio, debe tenerse en cuenta el principio de mínimo privilegio al implementar la infraestructura de Roles Anywhere. Para ello, debe utilizarse la asignación de atributos de certificado.

Perspectiva del actor de amenazas

Escenario n.º 1: uso de certificados y claves privadas válidos por parte del atacante

Como se ha indicado anteriormente, los siguientes datos son necesarios para autenticarse utilizando Roles Anywhere:

• El certificado de cliente
• La clave privada del certificado de cliente
• El ARN del ancla de confianza que firmó el certificado
• El ARN de un perfil en la misma región
• El ARN de un rol de IAM que se adjunta al perfil

En el siguiente escenario, un atacante compromete una configuración predeterminada de Roles Anywhere para un certificado de cliente que se utiliza para la autenticación con su clave privada. A fin de aprovechar maliciosamente la configuración predeterminada para acceder a roles adicionales en la cuenta, el atacante aún necesita descubrir los ARN de los recursos relevantes para autenticarse en AWS. La obtención de los ARN no es una tarea sencilla y requiere privilegios independientes adicionales dentro de la cuenta.

Se pueden utilizar las siguientes técnicas para obtener esta información:

• Uso de las acciones de Roles Anywhere: Un atacante que haya obtenido suficientes permisos para el servicio de Roles Anywhere puede simplemente ejecutar acciones para obtener los ARN relevantes. Puede hacerlo utilizando las acciones list-trust-anchors y list-profiles, que requieren los permisos rolesanywhere:ListTrustAnchors y rolesanywhere:ListProfiles, respectivamente. El resultado de estas acciones contiene todos los ARN necesarios para la solicitud de autenticación, ya que el comando list-profiles devolverá todos los roles que están adjuntos al perfil.
• Recuperar datos de los registros: CloudTrail es el principal mecanismo de registro de AWS. Entre los registros de CloudTrail, un atacante con acceso independiente a los registros de CloudTrail (o a los servicios de almacenamiento que los contienen) podría localizar elementos creados por el servicio de Roles Anywhere. Algunos registros de CloudTrail contienen todos los ARN necesarios para el proceso de autenticación. Los registros del servicio de Roles Anywhere revelan estos ARN en los eventos de varias acciones.

El registro más relevante es CreateSession. Este registro se crea cuando se utiliza Roles Anywhere para la autenticación, es decir, para crear credenciales temporales y enviarlas al usuario. En la Figura 3, se muestra un ejemplo de una entrada del registro CreateSession y se anota el ARN asociado.

Los ARN de un ancla de confianza, un perfil y uno de sus roles adjuntos aparecen en este registro de eventos. Si el certificado del atacante fue firmado por el ancla de confianza que aparece en el registro, puede utilizarlo para realizar la autenticación.

En la Figura 5, se muestra una ilustración general de los pasos de los atacantes.

Escenario n.º 2: explotación de los permisos directos a Roles Anywhere

Otro escenario en el que se podría explotar una configuración predeterminada del servicio de Roles Anywhere es cuando un atacante obtiene acceso a una identidad que tiene permisos de Roles Anywhere. Estos permisos pueden concederse mediante una declaración Allow directa en el servicio o a través del elemento NotAction.

Los siguientes pasos pueden utilizarse para aprovechar estos permisos:

• El atacante obtiene acceso a una identidad que tiene configuraciones y permisos predeterminados de Roles Anywhere.
• El atacante crea dos certificados: un certificado de CA y un certificado de cliente; y luego utiliza el certificado de CA para firmar el certificado de cliente. Al haber creado los certificados, el atacante también posee sus claves privadas.
• El atacante utiliza la identidad comprometida para crear un ancla de confianza y adjunta el certificado de CA al ancla.
• Utilizando permisos de list de Roles Anywhere, el atacante recopila perfiles y ARN de roles de IAM.
• Utilizando los ARN, el certificado de cliente y su clave privada, el atacante se autentica utilizando Roles Anywhere.
• Si la política de confianza del rol de IAM deniega el acceso, el atacante puede comprobar los temas de Roles Anywhere para encontrar detalles sobre un certificado que se utilizó anteriormente para la autenticación y copiar los campos en un nuevo certificado de cliente.

En más detalle, un atacante con suficientes permisos de Roles Anywhere puede crear un certificado, firmarlo con el propio certificado de CA del atacante y subirlo a un ancla de confianza nuevo o existente. Esto requiere los permisos rolesanywhere:CreateTrustAnchor o rolesanywhere:UpdateTrustAnchor.

Dado que el atacante controla tanto el certificado de cliente como el certificado de CA, el certificado será válido. El siguiente paso es saber qué perfiles y roles están disponibles utilizando el comando list-profiles de Roles Anywhere o cualquier otra técnica mencionada anteriormente.

Con esta información, el atacante puede crear credenciales a través de Roles Anywhere y realizar operaciones en el contexto del rol que se utilizó.

Si las medidas de seguridad de la organización objetivo no detectan la actividad maliciosa, este proceso también actúa como un vector de persistencia para el atacante, ya que se puede utilizar un ancla de confianza para generar credenciales válidas hasta que se resuelva el problema.

Mitigaciones y recomendaciones

• Recomendamos encarecidamente añadir condiciones a la política de confianza predeterminada de los roles que se utilizan con Roles Anywhere. Como se mencionó anteriormente, la política predeterminada permite que cualquier ancla de confianza asuma el rol. Es esencial limitar el acceso al rol solo desde un ancla de confianza específico: el que se utiliza para autenticar la carga de trabajo relevante.

También deben aplicarse condiciones adicionales para limitar el acceso solo a los certificados con determinados atributos, como el nombre común o la organización. Sin embargo, estas condiciones no son una solución mágica y pueden obviarse en determinadas circunstancias. Por ejemplo, sería posible un desvío si un atacante fuera capaz de extraer información de atributos del certificado.

• Recomendamos utilizar anclas de confianza del tipo ACM-PCA. Cuando se utiliza ACM-PCA, ni siquiera un atacante que obtenga acceso completo al servicio de Roles Anywhere podrá cargar su propio certificado de CA generado en el ancla de confianza. El tipo de ancla de confianza no se puede cambiar, lo que significa que se necesitan permisos ACM-PCA (que no son comunes) para autenticarse.
  • Este es un punto fundamental. Si los roles que deben asumir las anclas de confianza utilizan la condición de la solución anterior, no se podrá acceder a ellos. Debemos tener en cuenta que las CA privadas en AWS tienen sus propias consideraciones de seguridad y también pueden suponer un riesgo si no se configuran correctamente
• Los permisos deben asignarse siempre según el principio del menor privilegio. La capacidad de autenticarse con Roles Anywhere suele otorgarse a identidades no humanas, y los dispositivos que utilizan este servicio suelen tener tareas específicas y predeterminadas que deben realizar. Por lo tanto, el nivel de acceso de estas identidades no debe exceder los requisitos de las tareas que se les asignen. Aparte de los propios roles de IAM, es posible asociar una política de sesión a un perfil. Esta política define los permisos máximos que puede tener el rol cuando se asume a través de Roles Anywhere.
• Supervise y realice un seguimiento periódico de los recursos de IAM Roles Anywhere de AWS: es crucial mantener una supervisión continua de las anclas de confianza, los perfiles y los recursos asociados. Las anclas y los perfiles de confianza no se crean con frecuencia, lo que hace que su creación o modificación sean eventos sospechosos. Cualquier cambio inesperado en estos recursos debe investigarse inmediatamente para asegurarse de que no se esté realizando ninguna actividad no autorizada. Las auditorías periódicas y las alertas automatizadas pueden ayudar a detectar y responder a tiempo a posibles amenazas para la seguridad.
• Ejecute la siguiente consulta XQL en Cortex Query Builder para identificar los roles que confían en el servicio de Roles Anywhere, pero que no aplican ninguna condición.

Conclusión

En este artículo, se han explorado los riesgos clave asociados con el uso de configuraciones predeterminadas para el servicio de Roles Anywhere de AWS, tanto desde la perspectiva de un posible atacante como desde la perspectiva de un defensor. Hemos proporcionado varias estrategias de mitigación que las organizaciones deberían implementar para gestionar mejor los riesgos asociados. Esperamos que este análisis ayude a los lectores a comprender mejor las vulnerabilidades potenciales que implica el uso de la funcionalidad por defecto de este servicio, y la mejor manera de mitigarlas.

Una de las principales conclusiones de este artículo es que, cuando se utilizan servicios de proveedores en la nube, es fundamental comprender a fondo las configuraciones y la arquitectura, en lugar de confiar en ellos sin sentido crítico.

• Siga las prácticas recomendadas de seguridad, los privilegios mínimos y las estrategias de defensa en profundidad.
• Esto ayuda a garantizar que los servicios estén correctamente diseñados y supervisados para detectar modificaciones en la configuración.
• Mantener la supervisión en tiempo de ejecución ayudará a garantizar que las plataformas en la nube personalizadas funcionen de forma segura.

Cortex Cloud proporciona protecciones contra los errores de configuración de la infraestructura de clave pública (PKI) detallados en este artículo. Mediante el uso de reglas basadas en el agente de Cloud XDR y reglas analíticas de comportamiento para detectar cuando se están usando mal las políticas de IAM, Cortex Cloud es capaz de detectar y prevenir operaciones maliciosas que usan sus capacidades de automatización de la plataforma XSOAR.

Las organizaciones pueden obtener ayuda para evaluar la postura de seguridad en la nube a través de la Evaluación de seguridad en la nube de Unit 42.

Si cree que su seguridad puede haber sido comprometida o si tiene un asunto urgente, póngase en contacto con el equipo de respuesta a incidentes de Unit 42 o llame a los siguientes números:

• América del Norte: Llamada gratuita: +1 (866) 486-4842 (866.4.UNIT42)
• REINO UNIDO: +44.20.3743.3660
• Europa y Oriente Medio: +31.20.299.3130
• Asia: +65.6983.8730
• Japón: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks compartió estos resultados con nuestros compañeros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar rápidamente protecciones para sus clientes y desbaratar sistemáticamente a los ciberactores malintencionados. Obtenga más información sobre Cyber Threat Alliance.

Recursos adicionales

• What Is the Principle of Least Privilege (Qué es el principio de mínimo privilegio), Palo Alto Networks
• The IAM Roles Anywhere trust model (El modelo de confianza de IAM Roles Anywhere): documentación oficial de Amazon Web Services