Expertos en ciberseguridad han descubierto una vulnerabilidad en el Cloud Development Kit (CDK) de Amazon Web Services (AWS), la cual podría haber permitido la apropiación de cuentas bajo ciertas circunstancias.

“El efecto de esta vulnerabilidad podría, en determinadas situaciones, permitir que un atacante obtenga acceso administrativo a una cuenta de AWS específica, resultando en un control total de la misma”, indicó Aqua en un informe enviado a The Hacker News.

Después de un aviso responsable el 27 de junio de 2024, los responsables del proyecto corrigieron el problema en la versión 2.149.0 del CDK, que fue publicada en julio.

El AWS CDK es un marco de desarrollo de código abierto que permite definir y aprovisionar recursos en la nube usando lenguajes como Python, TypeScript o JavaScript a través de CloudFormation.

La vulnerabilidad identificada por Aqua se basa en hallazgos previos de la empresa sobre recursos en la sombra en AWS, así como en cómo las convenciones de nombres para los buckets de AWS Simple Storage Service (S3) pueden ser utilizadas para llevar a cabo ataques de “Bucket Monopoly” y acceder a datos sensibles.

La preparación de un entorno de AWS con el AWS CDK se realiza mediante un proceso llamado “arranque”, que implica aprovisionar ciertos recursos de AWS al entorno, incluyendo un bucket de AWS S3, un repositorio de Amazon Elastic Container Registry (Amazon ECR) y funciones de AWS Identity and Access Management (IAM).

“Los recursos y su configuración que usa el CDK se definen en una plantilla de AWS CloudFormation”, según la documentación de AWS.

“Para iniciar un entorno, se utiliza el comando cdk bootstrap de la interfaz de línea de comandos del AWS CDK (AWS CDK CLI). La CLI de CDK recupera la plantilla y la implementa en AWS CloudFormation como una pila, conocida como ‘CDKToolkit'”.

Algunas de las funciones de IAM creadas durante el arranque permiten la carga y eliminación de activos en el bucket S3 asociado, así como la implementación de pilas con acceso administrativo.

Aqua explicó que el patrón de nombres para los roles de IAM generados por el AWS CDK sigue la estructura “cdk-{Qualifier}-{Description}-{Account-ID}-{Region}”, donde cada campo se explica a continuación:

• Qualifier: un valor de cadena único de nueve caracteres que, por defecto, es “hnb659fds”, aunque puede ser personalizado durante el arranque.
• Description: descripción del recurso (por ejemplo, cfn-exec-role).
• Account-ID: ID de cuenta de AWS del entorno.
• Region: región de AWS del entorno.

De manera similar, el bucket S3 creado durante el arranque sigue el patrón “cdk-{Qualifier}-assets-{Account-ID}-{Region}”.

“Dado que muchos usuarios ejecutan el comando cdk bootstrap sin personalizar el calificador, el patrón de nombres de los buckets S3 se vuelve predecible”, dijo Aqua. “Esto ocurre porque el valor predeterminado del calificador se establece en ‘hnb659fds’, facilitando la anticipación del nombre del bucket”.

Con miles de instancias encontradas en GitHub utilizando el calificador predeterminado, adivinar el nombre del bucket se vuelve tan simple como conocer el ID de la cuenta de AWS y la región donde se implementó el CDK.

Al combinar esto con el hecho de que los nombres de los buckets S3 son únicos a nivel global en todas las cuentas de AWS, la vulnerabilidad permite lo que se conoce como “squatting” o “Bucket Sniping”, lo que posibilita a un atacante reclamar el bucket CDK de otro usuario si este aún no existe.

Esto podría conducir a una denegación de servicio parcial (DoS) cuando un usuario intenta iniciar el CDK con la misma ID de cuenta y región, un escenario que podría evitarse al especificar un calificador personalizado durante el arranque.

Un problema más grave podría surgir si el CDK de la víctima tiene permisos para leer y escribir datos desde y hacia el bucket S3 controlado por el atacante, lo que permitiría manipular las plantillas de CloudFormation y ejecutar acciones maliciosas en la cuenta de AWS de la víctima.

“El rol de implementación del servicio CloudFormation, conocido como ‘CloudFormationExecutionRole’ en CDK, tiene privilegios administrativos de forma predeterminada”, comentó Aqua.

“Esto significa que cualquier plantilla de CloudFormation escrita en el bucket S3 del atacante por el CDK de la víctima se implementaría con privilegios administrativos en la cuenta de la víctima, permitiendo al atacante crear recursos privilegiados”.

En un ataque hipotético, si un usuario había iniciado el proceso de arranque del CDK anteriormente y luego eliminó el bucket S3 debido a límites de cuota, un adversario podría aprovechar esta situación para crear un bucket con el mismo nombre.

Esto podría resultar en que el CDK confíe implícitamente en el bucket no autorizado y lea/escriba plantillas de CloudFormation en él, haciéndolo vulnerable a la explotación. Sin embargo, para que esto funcione, se espera que el atacante cumpla con ciertos requisitos previos:

• Reclamar el bucket con el nombre predecible y permitir el acceso público.
• Crear una función Lambda que inyecte un rol de administrador malicioso o una puerta trasera en un archivo de plantilla de CloudFormation cada vez que se cargue en el bucket.

Finalmente, cuando el usuario implementa el CDK usando “cdk deployment”, no solo se envía la plantilla al bucket de réplicas, sino que también se inyecta un rol de administrador que el atacante puede asumir para obtener el control de la cuenta de la víctima.

En otras palabras, esta cadena de ataque facilita la creación de un rol de administrador en una cuenta de AWS de destino cuando se elimina un bucket S3 de CDK configurado durante el proceso de arranque y se reutiliza el CDK. AWS ha confirmado que aproximadamente el 1 % de los usuarios de CDK eran vulnerables a este vector de ataque.

La solución implementada por AWS asegura que los activos solo se carguen en los buckets dentro de la cuenta del usuario, evitando que el CDK envíe datos a buckets que no son de la cuenta que inició el arranque. Además, se ha instado a los clientes a usar un calificador personalizado en lugar del predeterminado “hnb659fds”.

Sin embargo, se requiere acción por parte del usuario si el arranque se realizó con la versión v2.148.1 del CDK o anterior, lo que obliga a actualizar el CDK a la última versión y volver a ejecutar el comando de arranque. Alternativamente, los usuarios pueden aplicar una condición de política de IAM al rol FilePublishingRole del CDK.

Los hallazgos subrayan la importancia de mantener en secreto los IDs de cuentas de AWS, definir políticas de IAM de alcance y evitar nombres predecibles para los buckets S3.

“En su lugar, se recomienda generar hashes únicos o identificadores aleatorios por región y cuenta, e incorporarlos a los nombres de los buckets S3”, concluyó Aqua. “Esta estrategia ayuda a protegerse contra los atacantes que intentan reclamar su bucket”.

La revelación coincide con un hallazgo de Symantec, propiedad de Broadcom, que encontró varias aplicaciones de Android e iOS que codificaban en lugar de cifrar las credenciales de servicios en la nube para AWS y Microsoft Azure Blob Storage, poniendo en riesgo los datos de los usuarios.

Algunas de las aplicaciones infractoras incluyen Pic Stitch: Collage Maker, Crumbl, Eureka: Earn Money for Surveys, Videoshop – Video Editor, Meru Cabs, Sulekha Business y ReSound Tinnitus Relief.

“Esta peligrosa práctica significa que cualquiera con acceso al código binario o fuente de la aplicación podría potencialmente extraer estas credenciales y utilizarlas indebidamente para manipular o exfiltrar datos, provocando graves violaciones de seguridad”, indicaron los investigadores de seguridad Yuanjing Guo y Tommy Dong.

Fuente: thehackernews.com